문제

JSON 파일 내에서 주석을 사용할 수 있습니까? 그렇다면 어떻게?

도움이 되었습니까?

해결책

아니.

JSON은 모두 데이터 여야하며 의견을 포함하면 데이터도 포함됩니다.

지정된 데이터 요소를 호출 할 수 있습니다 "_comment" JSON 데이터를 사용하는 앱에 의해 무시되는 (또는 무언가).

JSON 데이터가 사전에 무엇이 될지 또는 적어도 그 구조를 알아야하기 때문에 JSON을 생성/수신하는 프로세스에서 주석을 두는 것이 좋습니다.

그러나 당신이 결정했다면 :

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}

다른 팁

아니, 양식의 의견 //… 또는 /*…*/ JSON에서는 허용되지 않습니다. 이 답변은 다음을 기반으로합니다.

  • http://www.json.org
  • RFC 4627: application/json JavaScript 객체 표기법 (JSON) 용 미디어 유형
  • RFC 7159 JavaScript 객체 표기법 (JSON) 데이터 인터체인지 형식 - 쓸데없는 경우 : 4627, 7158

선택한 경우 의견을 포함시킵니다. 구문 분석하거나 전송하기 전에 미니 파이어로 제거하십시오.

방금 릴리스되었습니다 json.minify () JSON 블록에서 댓글과 공백을 제거하고 구문 분석 할 수있는 유효한 JSON을 만듭니다. 따라서 다음과 같이 사용할 수 있습니다.

JSON.parse(JSON.minify(my_str));

내가 그것을 발표했을 때, 나는 그것에 대한 아이디어조차도 동의하지 않는 사람들의 큰 반발을 얻었으므로 왜 그런지에 대한 포괄적 인 블로그 게시물을 작성하기로 결정했습니다. 댓글은 JSON에서 의미가 있습니다. JSON 제작자 의이 주목할만한 의견이 포함됩니다.

JSON을 사용하여 구성 파일을 보관한다고 가정 해 봅시다. 계속해서 원하는 모든 의견을 삽입하십시오. 그런 다음 JSMIN을 통해 파이프를 가리기 전에 JSON 파서에게 건네주십시오. - Douglas Crockford, 2012

바라건대 그 이유에 동의하지 않는 사람들에게 도움이되기를 바랍니다. json.minify () 유용 할 수 있습니다.

댓글은 디자인에 의해 JSON에서 제거되었습니다.

나는 사람들이 상호 운용성을 파괴 한 관행 인 Parsing Directives를 개최하기 위해 그들을 사용하는 것을 보았 기 때문에 JSON의 의견을 제거했습니다. 나는 의견이 부족하다는 것이 어떤 사람들을 슬프게한다는 것을 알고 있지만, 그렇지 않아야합니다.

JSON을 사용하여 구성 파일을 보관한다고 가정 해 봅시다. 계속해서 원하는 모든 의견을 삽입하십시오. 그런 다음 JSMIN을 통해 파이프를 가리기 전에 JSON 파서에게 건네주십시오.

원천: G+의 Douglas Crockford의 공개 성명

면책 조항 : 보증은 무효입니다

지적한 바와 같이,이 해킹은 사양의 구현을 활용합니다. 모든 JSON 파서가 이런 종류의 JSON을 이해하는 것은 아닙니다. 특히 파서 스트리밍은 질식 할 것입니다.

흥미로운 호기심이지만 당신 실제로 아무것도 사용해서는 안됩니다.. 아래는 원래 답변입니다.


구문 분석에 영향을 미치지 않는 JSON 파일에 주석을 놓거나 어떤 식 으로든 표현되는 데이터를 변경할 수있는 작은 해킹을 찾았습니다.

객체 문자 문자를 선언 할 때 동일한 키로 두 값을 지정할 수 있으며 마지막 값이 우선합니다. 믿거 나 말거나, JSON 파서는 같은 방식으로 작동한다는 것이 밝혀졌습니다. 따라서 우리는 이것을 사용하여 소스 JSON에서 구문 분석 된 객체 표현에 존재하지 않는 주석을 만들 수 있습니다.

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

이 기술을 적용하면 주석은 JSON 파일처럼 보일 수 있습니다.

{
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

  "retry_interval" : "The interval in seconds between retrying failed API calls",
  "retry_interval" : 10,

  "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
  "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",

  "favorite_numbers": "An array containing my all-time favorite numbers",
  "favorite_numbers": [19, 13, 53]
}

위의 코드는입니다 유효한 JSON. 구문 분석하면 다음과 같은 객체를 얻을 수 있습니다.

{
    "api_host": "hodorhodor.com",
    "retry_interval": 10,
    "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
    "favorite_numbers": [19,13,53]
}

이는 주석의 흔적이 없으며 이상한 부작용이 없다는 것을 의미합니다.

행복한 해킹!

JSON은 의견을지지하지 않습니다. 또한 주석이 필요한 구성 파일에 사용되지 않았습니다.

HJSON은 인간을위한 구성 파일 형식입니다. 편안한 구문, 더 적은 실수, 더 많은 의견.

Hjson intro

보다 hjson.org JavaScript, Java, Python, Php, Rust, Go, Ruby 및 C# 라이브러리의 경우.

Yaml 사용을 고려하십시오. 거의 JSON의 슈퍼 세트입니다 (사실상 모든 유효한 JSON은 유효한 YAML). 주석을 허용합니다.

당신은 할 수 없습니다. 적어도 그것은 빠른 눈에 나온 나의 경험입니다 json.org.

JSON은 해당 페이지에서 구문을 시각화했습니다. 의견에 대한 메모는 없습니다.

당신은 a JSON 스키마 대신에. JSON 스키마는 현재 제안 된 인터넷 초안 사양입니다. 문서 외에도 스키마는 JSON 데이터를 검증하는 데 사용될 수도 있습니다.

예시:

{
    "description":"A person",
    "type":"object",
    "properties":
        {
            "name":
                {
                    "type":"string"
                },
            "age":
                {
                    "type":"integer",
                    "maximum":125
                }
        }
}

사용하여 문서를 제공 할 수 있습니다 설명 스키마 속성.

사용중인 경우 잭슨 JSON 파서로서 이것은 의견을 허용하는 방법입니다.

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

그런 다음 다음과 같은 주석을 가질 수 있습니다.

{
  key: "value" // Comment
}

그리고 당신은 또한 시작을 시작할 수 있습니다 # 설정으로 :

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

그러나 일반적으로 (이전에 응답했듯이) 사양은 주석을 허용하지 않습니다.

의견은 공식 표준이 아닙니다. 일부 파서는 C 스타일의 의견을 지원하지만. 내가 사용하는 것은입니다 JSONCPP. 예제에는 이것이 있습니다.

// Configuration options
{
    // Default encoding for text
    "encoding" : "UTF-8",

    // Plug-ins loaded at start-up
    "plug-ins" : [
        "python",
        "c++",
        "ruby"
        ],

    // Tab indent size
    "indent" : { "length" : 3, "use_space": true }
}

jsonlint 이것을 검증하지 않습니다. 따라서 주석은 구문 분석 특정 확장이며 표준이 아닙니다.

또 다른 파서입니다 JSON5.

JSON의 대안 .

더 대안은 JSONC.

여기에 내가 찾은 것입니다 Google Firebase 문서 이를 통해 JSON에 의견을 올릴 수 있습니다.

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project's sender ID",
  "gcm_sender_id": "1234567890"
}

JSON 문자열 인 텍스트 파일이 일부 프로그램에 의해 읽히는 경우 사용하기 전에 C 또는 C ++ 스타일의 주석을 제거하는 것이 얼마나 어려울까요?

대답: 하나의 라이너 일 것입니다. 그렇게하면 JSON 파일을 구성 파일로 사용할 수 있습니다.

ASP.NET과 함께 NewTonSoft.json 라이브러리를 사용하여 읽기/사제를 사용하는 경우 JSON 컨텐츠에서 주석을 사용할 수 있습니다.

// "이름": "String"

// "ID": int

또는

/* 이것은

주석 예 */

추신: 단일 라인 댓글은 6 개 이상의 Newtonsoft JSON에서만 지원됩니다.

상자 밖에서 생각할 수없는 사람들을위한 추가 메모 : 내가 만든 ASP.NET 웹 응용 프로그램에서 기본 설정에 JSON 형식을 사용합니다. 파일을 읽고 NewTonsoft 라이브러리를 사용하여 설정 객체로 변환하고 필요할 때 사용합니다.

나는 JSON 파일 자체의 각 개별 설정에 대한 의견을 작성하는 것을 선호하며, 내가 사용하는 라이브러리가 괜찮은 한 JSON 형식의 무결성에 대해서는 신경 쓰지 않습니다.

나는 이것이 별도의 'settings.readme'파일을 작성하고 설정을 설명하는 것보다 '사용하기 쉬운/이해'방법이라고 생각합니다.

이런 종류의 사용에 문제가있는 경우; 죄송합니다. 지니가 램프에서 벗어났습니다. 사람들은 JSON 형식에 대한 다른 사용법을 찾을 수 있으며, 그것에 대해 할 수있는 일은 없습니다.

JSON의 아이디어는 응용 프로그램간에 간단한 데이터 교환을 제공하는 것입니다. 이들은 일반적으로 웹 기반이며 언어는 JavaScript입니다.

그러나 데이터의 이름/값 쌍 중 하나로 주석을 전달하는 것은 실제로 작동 할 수는 없지만, 데이터는 분명히 구문 분석 코드에 의해 구체적으로 무시되거나 처리되어야합니다.

즉, JSON 파일에 전통적인 의미로 의견이 포함되어야한다는 것은 아닙니다. 데이터 일뿐입니다.

살펴보십시오 JSON 웹 사이트 자세한 내용은.

단지 구성 파일에 대해 이것을 만납니다. 사용하고 싶지 않습니다 XML (Verbose, 그래픽, 못생긴, 읽기 어려운) 또는 "INI"형식 (계층 없음, 실제 표준 없음 등) 또는 Java "Properties"형식 (예 : .ini).

JSON은 그들이 할 수있는 모든 것을 할 수 있지만, 덜 장황하고 인간이 읽기 쉬운 것입니다. 구문자는 많은 언어에서 쉽고 유비쿼터스입니다. 그것은 단지 데이터의 트리 일뿐입니다. 그러나 대역 밖의 의견은 종종 "기본"구성 등을 문서화해야합니다. 구성은 "전체 문서"가되어서는 안되지만 필요할 때 인간을 읽을 수있는 저장된 데이터의 나무.

나는 하나가 사용할 수 있다고 생각한다 "#": "comment", "유효한"JSON 용.

JSON은 기본적으로 의견을지지하지 않지만, 자신만의 디코더 또는 최소한 전처리자를 댓글을 벗기기 위해 만들 수 있습니다. 댓글을 무시하고 응용 프로그램이 JSON 데이터를 처리하는 방법을 안내하는 데 사용하지 않는 한 완벽합니다. ).

JSON에는 의견이 없습니다. JSON 인코더는 주석을 출력해서는 안됩니다. JSON 디코더는 의견을 받아들이고 무시할 수 있습니다.

주석은 의미있는 것을 전송하는 데 사용해서는 안됩니다. 그것이 JSON의 것입니다.

CF : Douglas Crockford, JSON SPEC의 저자.

JSON 라이브러리에 따라 다릅니다. json.net JavaScript 스타일의 주석을 지원하고 /* commment */.

보다 또 다른 스택 오버플로 질문.

JSON은 유비쿼터스이기 때문에 구성 파일 및 기타 로컬 사용에 대해 많은 의미가 있습니다. XML보다 훨씬 간단하기 때문입니다.

사람들이 데이터를 전달할 때 (유효 여부) JSON에서 의견을 제시하는 것에 대해 강한 이유가 있다면 JSON은 두 가지로 나눌 수 있습니다.

  • JSON-COM : 와이어의 JSON 또는 JSON 데이터를 통신 할 때 적용되는 규칙.
  • JSON-DOC : JSON 문서 또는 파일 또는 로컬로 JSON. 유효한 JSON 문서를 정의하는 규칙.

JSON-DOC는 의견을 허용하며, whitespace 처리와 같은 다른 사소한 차이가있을 수 있습니다. 파서는 한 사양에서 다른 사양으로 쉽게 변환 할 수 있습니다.

와 관련하여 주목 이 문제에 대해 Douglas Crockford가 만든 (@artur czajka에 의해 참조)

JSON을 사용하여 구성 파일을 보관한다고 가정 해 봅시다. 계속해서 원하는 모든 의견을 삽입하십시오. 그런 다음 JSMIN을 통해 파이프를 가리기 전에 JSON 파서에게 건네주십시오.

우리는 일반적인 구성 파일 문제 (크로스 언어/플랫폼)에 대해 이야기하고 있으며 JS 특정 유틸리티로 응답하고 있습니다!

확실히 JSON 특이 적 조정은 모든 언어로 구현 될 수 있지만,이를 표준화하여 모든 언어와 플랫폼의 파서에 걸쳐 유비쿼터스가되어 사람들이 기능이 부족하기 때문에 기능이 부족하여 시간을 낭비하지 않아 문제를 해결합니다. 온라인 포럼, 사람들이 그들에게 나쁜 생각이라고 말하거나 텍스트 파일에서 댓글을 벗기는 것이 쉽다고 제안합니다.

다른 문제는 상호 운용성입니다. 라이브러리 또는 API 또는 이와 관련된 구성 또는 데이터 파일이있는 모든 종류의 서브 시스템이 있다고 가정합니다. 그리고이 하위 시스템은 다른 언어에서 액세스해야합니다. 그런 다음 사람들에게 말하기를 원하십니까?

DOJO 툴킷 JavaScript 툴킷 (적어도 버전 1.4)을 사용하면 JSON에 댓글을 포함시킬 수 있습니다. 의견은 다음과 같습니다 /* */ 체재. Dojo Toolkit은 JSON을 통해 JSON을 소비합니다 dojo.xhrGet() 전화.

다른 JavaScript 툴킷도 비슷하게 작동 할 수 있습니다.

최종 옵션을 선택하기 전에 대체 데이터 구조 (또는 데이터 목록)를 실험 할 때 도움이 될 수 있습니다.

사용하는 경우 JSON5 의견을 포함시킬 수 있습니다.


JSON5는 JSON에 대한 제안 된 확장입니다 그것은 인간이 손으로 쓰고 유지하기가 더 쉽게 만드는 것을 목표로합니다. ECMAScript 5에서 직접 최소 구문 기능을 추가하여이를 수행합니다.

JSON은 프레임 프로토콜이 아닙니다. 이것은 언어 무료 형식. 따라서 주석 형식은 JSON에 대해 정의되지 않습니다.

많은 사람들이 제안한 것처럼, 예를 들어 중복 키나 특정 키와 같은 몇 가지 트릭이 있습니다. _comment 사용할 수 있습니다. 그것은 당신에게 달려 있습니다.

~할 수 있다 의견이 있습니다 JSONP, 그러나 순수한 JSON은 아닙니다. 나는 HighCharts 의이 예제로 프로그램을 작동 시키려고 한 시간을 보냈습니다. http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

링크를 따르면 볼 수 있습니다

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

로컬 폴더에 비슷한 파일이 있었기 때문에 동일한 원래 정책, 그래서 나는 순수한 JSON을 사용하기로 결정했습니다 ... 물론 $.getJSON 의견 때문에 조용히 실패했습니다.

결국 방금 수동 HTTP 요청을 위의 주소로 보냈고 콘텐츠 유형이 text/javascript 글쎄, JSONP는 순수한 JavaScript를 반환합니다. 이 경우 주석 허용됩니다. 그러나 내 응용 프로그램은 콘텐츠 유형을 반환했습니다 application/json, 그래서 나는 주석을 제거해야했다.

JSON은 의견을지지하는 데 사용했지만 표준에서 남용되어 제거되었습니다.

JSON의 제작자로부터 :

나는 사람들이 상호 운용성을 파괴 한 관행 인 Parsing Directives를 개최하기 위해 그들을 사용하는 것을 보았 기 때문에 JSON의 의견을 제거했습니다. 나는 의견이 부족하다는 것이 어떤 사람들을 슬프게한다는 것을 알고 있지만, 그렇지 않아야합니다. - Douglas Crockford, 2012

공식 JSON 사이트가 있습니다 json.org. JSON은 a로 정의됩니다 기준 ECMA International. 표준을 개정하는 청원 절차가 항상 있습니다. 몇 가지 이유로 주석이 JSON 표준에 추가 될 것 같지 않습니다.

JSON By Design은 XML에 대한 쉽게 리버스 엔지니어링 (인간 구문 분석) 대안입니다. 주석이 불필요하다는 점에서도 단순화됩니다. 마크 업 언어도 아닙니다. 목표는 안정성과 상호 작용입니다.

객체 방향의 "HAS -A"관계를 이해하는 사람은 JSON 구조를 이해할 수 있습니다. 즉, 요점입니다. 그것은 거의 보편적 인 데이터 구조 인 노드 태그 (키/값 쌍)가있는 DAG (Directed Acyclic Graph) 일뿐입니다.

이 주석만이 "// DAG 태그"일 수 있습니다. 주요 이름은 필요한만큼 유익 할 수 있으므로 임의의 의미 론적 아티브를 허용합니다.

모든 플랫폼은 몇 줄의 코드만으로 JSON을 구문 분석 할 수 있습니다. XML에는 많은 플랫폼에서 실용적이지 않은 복잡한 OO 라이브러리가 필요합니다.

주석은 JSON이 상호 운용성을 덜 만들게됩니다. 실제로 필요한 것이 마크 업 언어 (XML)가 아니라면 추가 할 것이 없으며 지속 된 데이터가 쉽게 구문 분석되는지 신경 쓰지 않습니다.

이것은 "할 수 있나요" 의문. 그리고 여기에 있습니다 "예" 대답.

아니요, 복제 객체 멤버를 사용하여 측면 채널 데이터를 JSON 인코딩에 넣지 않아야합니다. ( "객체의 이름은 고유해야합니다"를 참조하십시오. RFC에서).

그리고 네, 당신은 할 수 있습니다 주석을 삽입하십시오 주위에 JSON, 당신이 구문 분석 할 수 있습니다.

그러나 유효한 JSON에 임의의 측면 채널 데이터를 삽입하고 추출하는 방법을 원한다면 여기에 답이 있습니다. 우리는 JSON 인코딩에서 데이터의 비 유적 표현을 활용합니다. 이것은 허용됩니다* "6 개의 구조 문자 중 전후에 공백이 허용된다"에 따른 RFC의 2 장에서.

*RFC는 문자열, 숫자, "false", "true"및 "null"을 명시 적으로 언급하지 않고 "6 개의 구조적 문자 중 어느 것 전후에 허용된다"고 말합니다. 이 누락은 모든 구현에서 무시됩니다.


먼저, JSON을 조정하여 정식화하십시오.

$jsonMin = json_encode(json_decode($json));

그런 다음 이진에서 의견을 인코딩합니다.

$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);

그런 다음 이진을 steg하십시오.

$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);

다음은 출력입니다.

$jsonWithComment = $steg . $jsonMin;

우리는 사용 중입니다 strip-json-comments 우리 프로젝트를 위해. 그것은 다음과 같은 것을 지원합니다.

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

간단히 npm install --save strip-json-comments 설치하고 사용하려면 다음과 같이 사용합니다.

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

JSON 항목을 부품으로 자르려면 "더미 댓글"라인을 추가합니다.

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}

유효한 JSON 인 좋은 솔루션 (해킹)이 있습니다. 동일한 키를 두 번 (또는 그 이상) 만 만드십시오. 예를 들어:

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

따라서 JSON은 이것을 다음과 같이 이해합니다.

{
  "param" : "This is value place",
}

JSON의 저자는 우리가 JSON에 의견을 포함시키기를 원하지만 구문 분석하기 전에 제거합니다 ( 링크 Michael Burr에 의해 제공). JSON이 댓글을 달아야한다면 표준화하지 말고 JSON 파서가 작업을 수행하게합니까? 나는 거기에 논리에 동의하지 않지만 아아, 그것이 표준입니다. 다른 사람들이 제안한대로 Yaml 솔루션을 사용하는 것은 좋지만 라이브러리 의존성이 필요합니다.

의견을 제거하고 싶지만 라이브러리 의존성을 원하지 않는 경우 C ++ 스타일의 주석에 맞지 만 다른 사람에게 적용 할 수있는 2 라인 솔루션이 있습니다.

var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

이 솔루션은 JSON 데이터에 주석 개시기 ( '//')가 포함되어 있지 않은 경우에만 사용할 수 있습니다.

JSON 파싱, 의견 제거 및 추가 라이브러리가없는 또 다른 방법은 JavaScript 통역사에서 JSON을 평가하는 것입니다. 물론 이러한 접근 방식의 경고는 무모한 데이터 만 평가하고 싶다는 것입니다 (신뢰할 수없는 사용자 입력 없음). 다음은 node.js 의이 접근법의 예입니다. 또 다른 경고, 다음 예제는 데이터를 한 번만 읽은 다음 캐시됩니다.

data = require(fs.realpathSync(doctree_fp));

한숨을 쉬다. 필드를 추가하지 않는 이유는 무엇입니까?

{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

"NotEx"이름이 실제 필드와 충돌하지 않도록하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top