JSON에서 주석을 사용할 수 있습니까?


7605

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


153
@StingyJack : 명확하지 않거나 주석으로 할 수있는 모든 것을 설명합니다. 나는 종종 데이터 파일에 의견이 있습니다. XML, ini 파일 및 기타 여러 형식에는 주석 제공이 포함됩니다.
Michael Burr

24
나와 같이 //commentsSublime Text 구성 파일의 특정 사용 사례에 대해 괜찮은지 궁금한 경우 대답은 예입니다 (버전 2 기준). 숭고한 텍스트는 적어도 그것에 대해 불평하지 않지만 {"__comment": ...}콘솔에서는 예상치 못한 필드이기 때문에 불평 합니다.
driftcatcher

8
아마도 이것이 TOML이 만들어진 이유 중 하나 일 것입니다.
Alex Nolasco

10
약간 멍청하지만, JSON의 주석에 //를 사용해 보았습니다. 이제는 교환 / 교환에 엄격하게 사용된다는 것을 알고 있습니다. 한숨! 더 이상 댓글을 달 수 없습니다 :(. 인생은 운명입니다!.
Sid

12
: JSON5 주석을 지원 stackoverflow.com/a/7901053/108238
schoetbi

답변:


5590

아니.

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"
            }
         }
      }
   }
}

232
comment라는 유효한 필드가있는 경우 실제 주석에 접두어를 붙여야 할 수도 있습니다."__comment":"comment text goes here...",
Rob Fonseca-Ensor

19
Java google-gson 용 json 라이브러리 인 BTW 는 주석을 지원합니다.
centic

11
AccronymAbbrev속성 에 대한 별도의 의견을 원한다면 어떨까요? 나는이 패턴을 전에 사용했지만 그렇게 할 수 없기 때문에 중단되었습니다. 해킹입니다. 어쩌면 내가 __comment__대신 속성 이름을 붙인다면 . 그것은 여전히 ​​해킹이지만 "__comment__Abbrev"입니다. 그러나 모든 제작자에 대해 언급하겠습니다
Juan Mendes

41
당신은 또한 "//"를 사용할 수있다 : 이것은 더 기본적으로 보이고 같은 부모에서 여전히 반복 가능하다
smnbbrv

4
사람이 의도 한 구성 파일에 JSON을 사용하는 경우 사람이 더 잘 이해할 수 있도록 주석을 달아야합니다. 주석이 달린 이러한 파일은 더 이상 유효한 JSON이 아니지만 솔루션이 있습니다. 예를 들어 Google의 GYP는 # 스타일 주석을 지원합니다. JSON.Minify는 입력 파일에서 C / C ++ 스타일 주석을 버리는 데 도움이됩니다.
Петър Петров

1841

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

  • http://www.json.org
  • RFC 4627 : application/jsonJSON (JavaScript Object Notation) 의 미디어 유형
  • RFC 8259 JSON (JavaScript Object Notation) 데이터 교환 형식 (RFC 4627, 7158, 7159)

67
주석으로 JSON에 주석을 달려면 (따라서 JSON을 유효하지 않게 함) 구문 분석 또는 전송하기 전에이를 최소화하십시오. Crockford 자신은 2012 년 구성 파일의 맥락에서이를 인정했습니다.
toolbear

24
@alkuzad : 그것은 형식적인 문법에 올 때, 명시 적으로 말한다 뭔가가 있어야 된다 이 아닌 다른 방법으로 주위 허용했다. 예를 들어, 원하는 프로그래밍 언어를 선택하십시오. 원하는 (그러나 누락 된) 기능이 명시 적으로 허용되지 않는다고해서 컴파일러가 마 법적으로 인식한다는 의미는 아닙니다.
stakx-더 이상

5
예. JSON 형식은 요소 사이에 많은 데드 스페이스가 있으며 해당 영역에서 공백을 구분하지 않으므로 단일 또는 여러 줄 주석을 가질 수 없습니다. 많은 파서 및 축소 기는 JSON 주석도 지원하므로 파서가이를 지원하는지 확인하십시오. JSON은 애플리케이션 데이터 및 구성 설정에 많이 사용되므로 주석이 필요합니다. "공식 사양"은 좋은 생각이지만 불충분하고 쓸모가 없어서 너무 나쁩니다. 페이로드 크기 또는 성능이 염려되면 JSON을 최소화하십시오.
Triynko

58
당신의 대답은 절대적으로 정확하지만 이것은 BS라고합니다. 많은 최종 사용자가 json 구성을 필요로하므로 의견이 매우 도움이됩니다. 그냥 몇 가지 주석 포일 모자 JSON이 결정으로 인해 입니다 그리고 항상해야 인간의 요구는, 작은 마인드의 희화화 이럴입니다을 읽을 수 있다는 사실을 무시하고, 기계가 읽을.
cmroanirgo

18
@ cmroanirgo : 당신은 분명히 JSON의 한계에 대해 불평하는 첫 번째 사람이 아닙니다 ... 그래서 우리는 주석과 YAML 및 JSON5와 같은 다른 형식을 자동으로 허용하는 파서를 가지고 있습니다. 그러나 이것이 JSON이라는 사실을 바꾸지는 않습니다. 오히려 사람들이 문제의 한계를 감안할 때 처음에는 충분하지 않은 목적으로 JSON을 사용하기 시작한 것이 흥미 롭습니다. JSON 형식을 비난하지 마십시오. 특히 적합하지 않은 곳에서 사용한다고 주장하는 것에 대해 스스로를 비난하십시오.
stakx-더 이상

802

원하는 경우 의견을 포함하십시오. 파싱하거나 전송하기 전에 축소기로 스트리핑하십시오.

방금 JSON 블록에서 주석과 공백을 제거하고 구문 분석 할 수있는 유효한 JSON으로 만드는 JSON.minify () 를 릴리스 했습니다. 따라서 다음과 같이 사용할 수 있습니다.

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

내가 그것을 발표했을 때, 나는 사람들이 그것에 대한 아이디어에 동의하지 않는 것에 대한 반발을 일으켰다. 그래서 의견이 JSON에서 의미가있는 이유에 대한 포괄적 인 블로그 게시물을 작성하기로 결정했다 . JSON 작성자의 주목할만한 주석이 포함되어 있습니다.

주석을 추가하려는 구성 파일을 유지하기 위해 JSON을 사용한다고 가정하십시오. 계속해서 당신이 좋아하는 모든 의견을 삽입하십시오. 그런 다음 JSON 파서를 전달하기 전에 JSMin을 통해 파이프하십시오. - 더글러스 크록 포드, 2012

JSON.minify () 가 유용한 이유에 동의하지 않는 사람들에게 도움이 되기를 바랍니다 .


153
JSON.minify ()에 대한 유일한 문제는 실제로 실제로 느리다는 것입니다. 그래서 gist.github.com/1170297 과 같은 일을하는 자체 구현을 만들었습니다 . 일부 큰 테스트 파일에서는 구현에 74 초가 걸리고 0.06 초가 걸립니다.
WizKid

56
제안 된 대체 알고리즘을 JSON.minify ()의 github 저장소에 제출하여 지원되는 모든 언어로 이식 될 수 있다면 좋을 것입니다
Kyle Simpson

16
@MiniGod 이미이 주제에 대한 Doug의 생각을 여러 번 들었습니다. 내 블로그 게시물에서 오래 전에이를 해결 : blog.getify.com/json-comments
카일 심슨

18
@ MarnenLaibow-Koser는 데이터 스트림 (또는 패킷) 사용에도 주석에 유효한 용도가 있습니다. 생성 시간 또는 소스와 같은 진단 메타 데이터를 포함하는 것은 XML에서 일반적으로 사용되며 JSON 데이터에도 완벽하게 적용됩니다. 주석에 대한 논거는 얕고 암시적인 의도 된 사용법에 관계없이 모든 텍스트 데이터 형식에서 주석을 허용해야합니다 (JSON을 다른 곳에서 사용할 수 없다는 내용은 없습니다)
StaxMan

18
JSON이 보편적으로 수용 되려면 (기본적으로) 보편적 인 응용 프로그램이 있어야합니다. 예 : JSON은 애플리케이션 구성 파일로 제공 될 수 있습니다. 이 응용 프로그램은 의견을 원할 것입니다.
eggmatters

441

주석은 의도적으로 JSON에서 제거되었습니다.

사람들이 구문 분석 지시문을 유지하기 위해 주석을 사용하고 상호 운용성을 파괴하는 사례를 보았 기 때문에 JSON에서 주석을 제거했습니다. 나는 의견이 없기 때문에 어떤 사람들은 슬프다는 것을 알고 있지만 그렇게해서는 안됩니다.

주석을 추가하려는 구성 파일을 유지하기 위해 JSON을 사용한다고 가정하십시오. 계속해서 당신이 좋아하는 모든 의견을 삽입하십시오. 그런 다음 JSON 파서를 전달하기 전에 JSMin을 통해 파이프하십시오.

출처 : G +에 대한 Douglas Crockford의 공개 성명


198
JSON이 XML보다 사람이 읽을 수 있어야한다고 생각 했습니까? 주석은 가독성을위한 것입니다.
intrepidis

25
어쨌든, JSON에서 { "__directives": { "# n #": "DateTime.Now"}, "validdate": "# n #"} 파싱 지시문을 추가 할 수 있습니다. YAML처럼 보입니다. 앞으로 나아갈 길입니다 ...
intrepidis

73
개인적인 의견 : 의견을 밝히지 않는 것은 절름발이입니다. 구성 파일을 해독하기 위해 주석을 무시하는 비표준 JSON 파서를 작성하는 것 외에 다른 옵션이 없었습니다.
caiosm1005

17
@ArturCzajka 여전히 JSON이 주석을 지원하지 않는다는 사실을 싫어하지만 INI에 시도해 보았으므로 구성 파일에 JSON보다 주석을 사용하는 것이 훨씬 더 합리적이라는 것을 인정해야합니다. 답변 주셔서 감사합니다. 더 많은 사람들이 대화를 읽을 때 마음이 바뀔 것입니다. (:) 어쨌든 더 운동의 파서이었다 만들기
caiosm1005

77
어떤 사람들은 자전거를 타지 못하기 때문에 모든 자전거에 훈련 용 바퀴가 있어야하는 것과 같습니다. 바보 같은 사람들이 악용하기 때문에 중요한 기능을 제거하는 것은 나쁜 디자인입니다. 데이터 형식은 바보 방지보다 유용성을 우선시해야합니다.
Phil Goetz

205

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

지적 된 바와 같이,이 핵은 사양의 구현을 이용한다. 모든 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]
}

즉, 주석의 흔적이 없으며 이상한 부작용이 없습니다.

행복한 해킹!


150
에서 사양 : 객체 내 이름은 고유해야합니다.
Quentin

113
"모든 구현이 동일하게 처리합니다"-증명하기가 어렵습니다.
Quentin

91
JSON의 요소 순서는 보장되지 않습니다. "마지막"항목이 변경 될 수 있음을 의미합니다!
sep332

66
이것은 분명히 사양을 위반합니다 (위의 주석 참조). ietf.org/rfc/rfc4627.txt?number=4627
voidlogic

333
아니요 -파서가 스트리밍중인 경우 어떻게합니까? 파서가 키 순서가 정의되어 있지 않은 사전으로 파서를 읽는 경우 어떻게됩니까? 불로 이것을 죽여라 .
deanWombourne

183

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

Hjson은 사람을위한 구성 파일 형식입니다. 편안한 구문, 적은 실수, 더 많은 주석.

Hjson 소개

JavaScript, Java, Python, PHP, Rust, Go, Ruby 및 C # 라이브러리는 hjson.org 를 참조하십시오 .


13
공감. 개방적이지 않은 보수적 인 사람들은 증오를 좋아할 것입니다. 나는 당신의 구현이 더 널리 알려지기를 바랍니다. 아마도 원래보다 더 인기가있을 것입니다.) 누군가 Ruby로 구현하기를 바랍니다. @adelphus 잘 정의 된 언어는 자신의 관점이나 의견입니다. 보수적 인 "개발자"라는 것이 자신이 더 낫다는 것을 증명하지 못하고 제한된 공간에 갇혀 있으면 더 나빠질 수 있습니다. 사람들을 끔찍한 개발자로 쉽게 판단하지 마십시오.
konsolebox

7
죄송합니다, @konsolebox. ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf 를 읽은 후 "잘 정의 된 JSON은 당신의 의견"이라는 견해를 다시 생각할 수도 있습니다 . 실제 표준이며 자체 "특별한"버전을 구현하는 개발자 조각화, 혼란 및 많은 시간 낭비로 이어집니다. 각 브라우저는 약간 다른 버전의 표준을 구현하기 때문에 코드를 작성할 때 웹 개발자가 남는 혼란을 살펴보십시오. JSON 언어는 완벽하지는 않지만 조각화가 더 심합니다. 그리고 그렇습니다, 그것은 단지 의견 일 뿐이며 당신은 자유롭게 의견을 달리 할 수 ​​있습니다.
adelphus

22
나는 당신의 혹을 존경하지만 당신은 YAML을 다시 발명하고 있습니다. 유연성과 인간의 가독성을 많이 원한다면 YAML을 사용 하거나 ( 실제로 stackoverflow.com/questions/450399/… ) 사용하지 말고 , 통행 성 있지만 명확한 JSON을 사용하십시오.
toolbear

4
가장 사용하기 쉬운 구성 형식은 여전히 ​​INI입니다. 간단하고 구문이 무겁지 않습니다. 따라서 사용자는 구성 연못에 발가락을 담그면 덜 위협적입니다.
Matt

14
json이 설정으로 필요할 때마다 (주석 필요한 경우)-파일 이름을 ".json"대신 ".js"로 지정하십시오. js는 물론 유효한 json 객체 처리하고 주석 처리 할 수 있습니다. 그 이유는 그 이유입니다. "webpack.config.json"이 아닌 "webpack.config.js"(웹팩에도 그 이유가 더 있습니다 : P)
jebbie

122

YAML 사용을 고려하십시오. 거의 JSON의 수퍼 세트 (거의 모든 유효한 JSON은 유효한 YAML 임)이며 주석을 허용합니다.


12
@ g33kz0r 맞습니다. 따라서 YAML에 대한 설명은 JSON과 거의 같습니다.
Marnen Laibow-Koser 2014 년

12
@NateS 많은 사람들이 이미 그 대답이 '아니오'라고 지적했습니다. OP의 목표를 달성하는 더 좋은 방법을 제안했습니다. 그게 답입니다.
Marnen Laibow-Koser

5
단점 : yaml라이브러리는 Python과 함께 제공되지 않습니다.
출혈 손가락

6
@ marnen-laibow-koser : 예, Java 및 Perl에 사용 가능한 YAML 라이브러리를 사용하는 것은 무능해야하며 각각에 의해 생성 된 YAML이 다른 오류없이 소비 될 것으로 예상합니다. YAML interop은 문제 였지만 JSON interop은 그렇지 않았습니다. 내 지식이 부족하여 완전히 설명되어 있습니다.
toolbear

3
@ marnen-laibow-koser는 더 간단한 사양으로 동일한 것을 수행하는 형식이 좋습니다. 완벽한 구현을 가진 실용적인 형식이 완벽한 구현을 가진 이상적인 형식보다 낫습니다. 잘못된 라이브러리에 대한 모든 책임이 구현 자의 어깨에있는 것은 아닙니다. YAML 사양은 길고 조밀하며 둔합니다. 그 위키 백과 항목은 두 가지 모호성의 예를 인용한다. 모호함을 방지하기 위해 사람과 형식 사이에 이미 터를 배치해야하는 경우 형식은 인간 친화적 인 주장을 잃습니다. JSON은 YAML이 더 많이 주장하고 부족한 곳에서는 거의 주장하지 않고 성공합니다.
toolbear

108

당신은 할 수 없습니다. 적어도 그것은 json.org 에서 한눈에 보는 나의 경험입니다. .

JSON은 해당 페이지에 구문이 시각화되어 있습니다. 댓글에 대한 메모가 없습니다.


67

일부 파서는 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 TOML 의 대안 입니다.

다른 대안은 jsonc 입니다.


Groovy에는 JSON 처리를위한 내장 클래스가 있습니다. JsonSlurper는 주석을 처리 할 수 ​​있습니다. 물론 공식 사양에서는 주석이 허용되지 않으므로 파서에서이 동작은 비표준적이고 이식 가능하지 않습니다.
izrik

Newtonsoft Json.NET은 문제없이 C 스타일 주석을 지원합니다
Max

66

JSON 스키마를 작성해야합니다대신 를 합니다. JSON 스키마는 현재 제안 된 인터넷 초안 사양입니다. 문서 외에도 스키마를 사용하여 JSON 데이터를 검증 할 수도 있습니다.

예:

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

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


5
JSON 스키마가 살아 있습니까? 존재하지만 알려진 라이브러리에서 지원됩니까?
Munhitsu

1
예, json-schema Google 그룹 은 상당히 활성화되어 있으며 JSON 스키마 유효성 검사기의 우수한 JavaScript 구현을 위해 JSV 를 권장 합니다.
raffel

5
이것은 임시 문서가 아닌 구조화 된 문서에만 도움이됩니다
Juan Mendes

clojure를 사용하고 있고 확실하지 않은 경우 여기에 합리적인 오픈 소스 JSON 스키마 파서가 있습니다 : github.com/bigmlcom/closchema
charleslparker

@Munhitsu Manatee.Json (.Net)은 JSON 스키마를 광범위하게 지원합니다.
gregsdennis 2016 년

64

Jackson 을 JSON 파서로 사용하는 경우 다음과 같이 주석을 허용 할 수 있습니다.

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

그러면 다음과 같은 의견을 가질 수 있습니다.

{
  key: "value" // Comment
}

또한 다음과 같이 #설정 하여 주석을 작성할 수 있습니다 .

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

그러나 일반적으로 (앞서 답변 한대로) 사양에서는 주석을 허용하지 않습니다.


50

다음은 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"
}

참고로 Firebase 실시간 데이터베이스는 키에서 '/'를 사용할 수 없습니다. 따라서 이것은 여러분이 사용하기에 좋은 컨벤션이 될 수 있지만 Firebase에서는 할 수 없습니다
gutte

5
이 방법은 키를 고유해야하는 일부 라이브러리를 손상시킵니다. 의견에 번호를 매겨서이 문제를 해결하고 있습니다.
MovGP0

좋은 의견, 나는이 질문을 발견했습니다 ...이 부분은 스펙 stackoverflow.com/questions/21832701/…에 의해
mana

4
요즘에는 다음과 같이 사용하는 경향이 있습니다. { "// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} 여러 주석에 배열을 사용할 수 있습니다. { "// foo": [ "foo comment 1", "foo comment 2"], "foo": ''foo value "}
MovGP0

47

아니요 . JSON은 주석을 지원하는 데 사용되었지만 표준에서 남용되어 제거되었습니다.

JSON 제작자 :

사람들이 구문 분석 지시문을 유지하기 위해 주석을 사용하고 상호 운용성을 파괴하는 사례를 보았 기 때문에 JSON에서 주석을 제거했습니다. 나는 의견이 없기 때문에 어떤 사람들은 슬프다는 것을 알고 있지만 그렇게해서는 안됩니다. - 더글러스 크록 포드, 2012

공식 JSON 사이트는 JSON.org에 있습니다. JSON은 ECMA International 에서 표준 으로 정의 합니다. 표준을 수정하는 탄원 절차는 항상 있습니다. 몇 가지 이유로 주석이 JSON 표준에 추가되지는 않습니다.

JSON 설계는 XML에 대한 리버스 엔지니어링 (휴먼 파싱) 대안입니다. 주석이 불필요 할 정도로 단순화되었습니다. 마크 업 언어도 아닙니다. 목표는 안정성과 상호 운용성입니다.

객체 지향의 "has-a"관계를 이해하는 사람이라면 모든 JSON 구조를 이해할 수 있습니다. 거의 보편적 인 데이터 구조 인 노드 태그 (키 / 값 쌍)가있는 DAG (directed acyclic graph) 일뿐입니다.

필요한 주석은 "// 이것은 DAG 태그"일 수 있습니다. 키 이름은 필요에 따라 정보를 제공 할 수 있으므로 임의의 의미를 정의 할 수 있습니다.

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

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

그러나 JSON 제작자가 관찰 한 것처럼 주석에 대한 JS 파이프 라인 지원은 항상있었습니다.

계속해서 당신이 좋아하는 모든 의견을 삽입하십시오. 그런 다음 JSON 파서를 전달하기 전에 JSMin을 통해 파이프하십시오. - 더글러스 크록 포드, 2012


37

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

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


1
아마도 지금까지 가장 좋은 제안이지만 파일을 사용하기 전에 사전 처리가 필요하기 때문에 파일을 교환 형식으로 유지하는 데 여전히 문제가 될 수 있습니다.
Orbling

www.SoftwareMonkey.org에서 제공하는 Java로 JSON 파서를 작성하여 동의했습니다.
로렌스 돌

2
필자가 생각하기는하지만 다른 교환 형식을 호출하지 않고 JSON을 확장하는 것은 좋지 않습니다. 문자열 내에서 "설명"을 무시해야합니다. { "foo": "/ * 이것은 의견이 아닙니다. * /"}
stofl

27
"... 한 줄짜리가 될 것입니다"음, 사실, JSON은 정규 표현식이 단순히 일치하는 / * 쌍을 찾을 수있는 정규 문법이 아닙니다. / *가 문자열 안에 나타나는지 (그리고 무시하고), 이스케이프 된 (그리고 무시하는 경우) 등을 찾으려면 파일을 구문 분석해야합니다. 또한 제공하지 않고 단순히 추측 (부정확하게)하기 때문에 답이 도움이되지 않습니다. 모든 솔루션.
Kyle Simpson

1
@ kyle-simpson이 말한 것. 또한 그는 임시 정규 표현식의 대안으로 JSON.minify를 사용하는 것에 대한 독자의 답변을 독자에게 지시하기에는 너무 겸손합니다. 그렇게하지 마라.
toolbear

36

ASP.NET과 함께 Newtonsoft.Json 라이브러리를 사용하여 읽고 / 직렬화하는 경우 JSON 컨텐츠에서 주석을 사용할 수 있습니다.

// "이름": "문자열"

// "id": int

또는

/* 이것은

주석 예 * /

PS : 한 줄 주석은 6 개 이상의 Newtonsoft Json 버전에서만 지원됩니다.

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

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

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

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


누군가가 사실을 진술하는 데 왜 문제가 있는지 이해하기는 어렵습니다.
dvdmn

위의 내용이 더 이상 JSON이 아니거나 유효하지 않은 JSON이기 때문에 누군가 예외가 있다고 가정합니다. 아마도 짧은 면책 조항을 추가하면 완화 될 것입니다.
toolbear

5
나는 당신에게 완전히 동의하지만, 지금까지 명백한 답을 제시 한 비 응답에 대한 883 개의 공감대가 있습니다. 유용한 정보보다 가치가 높은 이데올로기 적 순결, 그것은 당신에게도 마찬가지입니다.
John

요점은 주석이있는 파일이며 JSON이 아니며 많은 JSON 라이브러리에서 구문 분석하지 못합니다. 자신의 프로그램에서 원하는 것을 자유롭게 수행하지만 의견이있는 파일은 JSON이 아닙니다. 당신이 그것을 주장한다면 사람들은 선택한 언어 / 라이브러리로 그것을 파싱하려고 시도 할 것이고 실패 할 것입니다. XML에서 꺾쇠 괄호 대신 대괄호를 사용할 수 있는지 묻는 것과 같습니다. 원하는 것은 무엇이든 할 수 있지만 더 이상 XML은 아닙니다.
gman

32

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

실제로 주석을 허용하지는 않지만 데이터에서 이름 / 값 쌍 중 하나 인 주석을 전달하면 분명히 작동하지만 데이터는 구문 분석 코드에서 특별히 무시하거나 처리해야합니다.

그러나 JSON 파일이 전통적인 의미로 주석을 포함해야한다는 의도는 아닙니다. 단지 데이터 여야합니다.

자세한 내용 은 JSON 웹 사이트 를 참조하십시오.


17
JSON 형식에 주석이없는 것은 사실입니다. 개인적으로 나는 그것이 큰 실수라고 생각합니다. 데이터가 아닌 메타 데이터로 주석을 갖는 기능은 XML에서 매우 유용한 것입니다. 이전 버전의 JSON 사양에는 주석이 포함되었지만 어떤 이유로 든 삭제되었습니다. :-/
StaxMan

4
@StaxMan 사람들이 메타 데이터로 사용하기 시작했기 때문에 정확하게 삭제되었습니다. Crockford는 형식이 설계된 것과의 호환성을 깨뜨렸다 고 말했고 동의합니다. 메타 데이터를 원한다면 실제 데이터로 포함하지 않겠습니까? 이 방법으로 파싱하는 것이 훨씬 쉽습니다.
Camilo Martin

6
메타 데이터는 주석이 아닌 메타 데이터 구조 (예 : HTML <meta> 태그)에 속합니다. 메타 데이터에 대한 주석을 남용하는 것은 진정한 메타 데이터 구성이없는 곳에서 사용되는 해킹 일뿐입니다.
Marnen Laibow-Koser

메타 데이터로 사용 된 주석은 상호 운용성을 손상시킬 수 있습니다. 메타 데이터도 JSON으로 저장해야합니다.
gaborous

1
이 답변은 더 잘 작성되고 더 높은 의견을 제시 한 답변으로 중복됩니다. 즉, 비록 이전에 작성되었지만 본질적으로 동일한 내용입니다. Cest la vie.
toolbear

29

구성 파일에 대해이 문제가 발생했습니다. XML (상세, 그래픽, 추악한, 읽기 어려운) 또는 "ini"형식 (계층 구조, 실제 표준 등 없음) 또는 Java "속성"형식 (.ini 등) 을 사용하고 싶지 않습니다.

JSON은 할 수있는 모든 것을 할 수 있지만 덜 장황하고 사람이 읽을 수있는 방식입니다. 파서는 많은 언어로 쉽고 편재합니다. 데이터 트리 일뿐입니다. 그러나 대역 외 주석은 종종 "기본"구성 등을 문서화해야합니다. 구성은 "전체 문서"가 될 필요는 없지만 필요할 때 사람이 읽을 수있는 저장된 데이터 트리입니다.

"#": "comment""유효한"JSON에 대해 사용할 수 있다고 생각 합니다.


4
구성 파일의 경우 JSON이 아닌 YAML을 제안합니다. (거의) 더 강력한 JSON 수퍼 세트이지만 주석을 포함하여 더 읽기 쉬운 구문도 지원합니다.
Marnen Laibow-Koser

1
json과 비교하여 YAML을 지원하는 언어는 몇 개입니까?
mmm

@Hamidam 12 개 이상의 언어가 yaml을 지원합니다 : yaml.org- 타사 라이브러리에 의존하지 않고도 내장 지원을 몇 개나 요청할 수 있습니다. Ruby 1.9.2처럼 보입니다. 다른 사람을 아는 사람이 있습니까? 그리고 어떤 언어가 기본적으로 json을 지원합니까?
nealmcb

5
YAML의 상호 운용성은 거짓말 : stackoverflow.com/questions/450399/... . 본능이 구성 파일에 JSON을 사용하려는 경우이를 따르십시오.
toolbear

이것은 오래되었지만 #을 사용하는 것은 좋은 생각이 아니라고 생각합니다. Json은 Javascript 리터럴의 구문에 가깝습니다. 자바 스크립트는 두 가지 유형의 주석을 지원합니다 : // and / * ... * / 내가 당신이라면 나는이 유형의 주석 중 하나 또는 둘 다를 고수 할 것입니다.
파스칼 가나 예

28

JSON은 기본적으로 주석을 지원하지 않지만 주석을 무시하고 응용 프로그램에서 JSON 데이터를 처리하는 방법을 안내하는 데 사용하지 않는 한 주석을 제거하기 위해 자체 디코더 또는 최소한 전처리기를 만들 수 있습니다. ).

JSON에는 주석이 없습니다. JSON 인코더는 주석을 출력해서는 안됩니다 (MUST NOT). JSON 디코더는 주석을 수락하고 무시할 수 있습니다.

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

Cf : Douglas Crockford, JSON spec의 저자 .


4
Crockford는 나중에 다음과 같이 작성했다. "JSON을 사용하여 구성 파일을 유지하고 주석을 달고 싶다고 가정하십시오. 계속해서 원하는 모든 주석을 삽입하십시오. 그런 다음 JSMin을 통해이를 JSON 파서에 넘기십시오." 자세한 내용은 @ kyle-simpson의 JSON에 대한 답변을 참조하십시오.
toolbear


27

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

사람들이 데이터를 통신 할 때 JSON에 주석을 달지 않는 강력한 이유가 있다면 (유효한지 여부와 상관없이) JSON을 두 가지로 나눌 수 있습니다.

  • JSON-COM : 유선상의 JSON 또는 JSON 데이터 통신시 적용되는 규칙
  • JSON-DOC : JSON 문서 또는 파일의 JSON 또는 로컬 유효한 JSON 문서를 정의하는 규칙

JSON-DOC는 주석을 허용하며 공백 처리와 같은 사소한 차이점이있을 수 있습니다. 파서는 한 스펙에서 다른 스펙으로 쉽게 변환 할 수 있습니다.

이 문제에 대해 Douglas Crockford 의 발언 과 관련하여 (@Artur Czajka가 참조)

주석을 추가하려는 구성 파일을 유지하기 위해 JSON을 사용한다고 가정하십시오. 계속해서 당신이 좋아하는 모든 의견을 삽입하십시오. 그런 다음 JSON 파서를 전달하기 전에 JSMin을 통해 파이프하십시오.

우리는 일반적인 구성 파일 문제 (cross language / platform)에 대해 이야기하고 있으며 JS 특정 유틸리티로 응답하고 있습니다!

JSON 특정 축소는 모든 언어로 구현할 수 있지만 표준화하면 모든 언어와 플랫폼의 파서 전체에서 유비쿼터스가되므로 사람들은 유용한 사용 사례가 있기 때문에 기능이 부족하여 시간을 낭비하지 않고 문제를 찾습니다. 온라인 포럼, 사람들에게 나쁜 생각을 말하거나 텍스트 파일에서 주석 제거를 쉽게 구현할 수 있다고 제안합니다.

다른 문제는 상호 운용성입니다. 라이브러리 또는 API 또는 이와 연관된 구성 또는 데이터 파일이있는 모든 종류의 서브 시스템이 있다고 가정하십시오. 이 하위 시스템은 다른 언어로 액세스해야합니다. 그런 다음 사람들에게 알려주십시오. 그런데 파서로 전달하기 전에 JSON 파일에서 주석을 제거하는 것을 잊지 마십시오!


JSON을 조각화 할 필요가 없습니다. 주석이있는 JSON은 더 이상 JSON이 아닙니다. 그러나 파싱하거나 전송하기 전에 주석을 제거해야 주석을 달아 JSON에 주석을 달 수 있습니다. 이를 수행하는 것은 수신자의 책임이되어서는 안됩니다.
toolbear

json5.org 는 json-doc을위한 솔루션입니다
Michael Freidgeim

24

JSON5 를 사용하는 경우 주석을 포함 할 수 있습니다.


JSON5는 사람이 손으로 직접 작성하고 관리 할 수 ​​있도록하기 위해 제안 된 JSON 확장 입니다. ECMAScript 5에서 직접 최소한의 구문 기능을 추가하여이를 수행합니다.


5
예를 추가해 주시겠습니까? 그런 다음 실제로 추가 문자가 필요할 수 있습니다.
dgilperez

6
SO 지침에 따라 실제 답변을 제공해야합니다. 링크 전용 답변은 바람직하지 않습니다. 지침을 확인할 수 있습니다 stackoverflow.com/help/how-to-answer
dgilperez

2
SO는 사용자에 의해 조정됩니다. 즉, 지침을 따르지 않는 경우 귀하의 의견을 제시 할 수있는 것과 같은 방법으로 답변을 제공 할 수 있습니다. 이것이 SO가 훌륭한 자원이되는 방법입니다.
dgilperez

22

Dojo Toolkit JavaScript 툴킷 (최소 버전 1.4 이상)을 사용하면 JSON에 주석을 포함 할 수 있습니다. 주석은 /* */형식 이 될 수 있습니다 . Dojo 툴킷은 dojo.xhrGet()호출을 통해 JSON을 사용합니다 .

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

최종 옵션을 선택하기 전에 대체 데이터 구조 (또는 데이터 목록)를 실험 할 때 유용합니다.


4
아뇨 JSON에는 주석이 없습니다. 주석으로 JSON에 주석을 달도록 선택한 경우 구문 분석하거나 전송하기 전에이를 최소화하십시오. 이것은 수신자의 책임이 아니어야합니다.
toolbear

2
JSON에 의견이 있다고 말하지 않았습니다. 또한 JSON, 특히 프로덕션 시스템에 포함시키는 것이 적절하다는 것을 의미하지는 않았습니다. 나는 말했다 Dojo 툴킷이 같은 사실은 사실이다 (또는 적어도이었다), 이는 추가 할 수있게한다. 테스트 단계에서 유용한 유스 케이스가 있습니다.
David

1
주석을 달아서 무효 JSON을 제공하는 것은 나쁜 부두 dojo.xhrGet()입니다.
toolbear

의견을 허용하기 위해 JSON 사양을 업그레이드하는 것에 여전히 투표합니다. JSON을 전송하기 전에 주석을 축소하고 제거하지만 모든 것을 파싱하기 전에 별도의 유틸리티를 거치지 않고 표준 방식으로 JSON에 주석을 달 수있는 능력이 없습니다. 또한 파일이 유효한 JSON이 아니기 때문에 JSON 구성 파일에서 JSON 편집기를 사용할 수 없습니다.
Craig

20

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

많은 사람들이 제안했듯이 중복 키 또는 _comment사용할 수 있는 특정 키와 같은 몇 가지 트릭 이 있습니다. 그것은 당신에게 달려 있습니다.


18

당신은 에 의견이 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/javascriptJSONP는 순수한 JavaScript를 반환하므로 콘텐츠 유형이 있다는 것을 깨달았습니다 . 이 경우 의견 이 허용 됩니다. 그러나 내 응용 프로그램은 content-type을 반환 application/json했으므로 주석을 제거해야했습니다.


17

이것은 "당신할 수있는" 질문입니다. 그리고 여기에 "예" 있습니다.

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

그리고 네, JSON 주위주석 삽입 하여 구문 분석 할 수 있습니다.

그러나 임의의 사이드 채널 데이터를 유효한 JSON에 삽입하고 추출하는 방법을 원한다면 여기에 답이 있습니다. JSON 인코딩에서 고유하지 않은 데이터 표현을 활용합니다. 이것은 허용 * "전이나 여섯 개 구조 문자의 후 허용되는 공백"의 RFC 섹션 두.

* RFC는 문자열, 숫자, "false", "true"및 "null"을 명시 적으로 언급하지 않고 "6 개의 구조 문자 앞뒤에 공백이 허용됨"만 표시합니다. 이 구현은 모든 구현에서 무시됩니다.


먼저 JSON을 축소하여 JSON을 정규화하십시오.

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

그런 다음 주석을 바이너리로 인코딩하십시오.

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

그런 다음 바이너리를 훔치십시오.

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

출력은 다음과 같습니다.

$jsonWithComment = $steg . $jsonMin;

1
RFC는 문자열, 숫자, "false", "true", "null"을 명시 적으로 언급하지 않고 "6 개의 구조 문자 앞뒤에 공백이 허용됨"만 표시합니다. 이 구현은 모든 구현에서 무시됩니다.
William Entriken

1
주석 밀도를 높이려면 주석을 3 진으로 인코딩하고 공백, 탭 및 줄 바꿈을 사용하여 주석을 묶을 수 없습니까?
Claire Nielsen

SHOULD는 필수는 아닙니다. 명시 적으로 포함 된 RFC 2119를 참조하십시오. 필수 :이 단어 또는 "필수"또는 "SHALL"이라는 용어는 정의가 스펙의 절대 요구 사항임을 의미합니다. ... SHOULD :이 단어 또는 형용사 "RECOMMENDED"는 특정 상황에서 특정 항목을 무시해야하는 유효한 이유가있을 수 있지만 다른 과정을 선택하기 전에 전체적인 의미를 이해하고 신중하게 고려해야합니다.
Jeff K

좋은 참조. 중복 키를 사용하는 것에 대한 더 나은 추론은 "객체 내의 이름이 고유하지 않을 때 그러한 객체를받는 소프트웨어의 동작은 예측할 수 없다"는 표준 인용문입니다. 또한 이제는 표준이 "고유 한"이유가 아니라는 것을 이해합니다. 이로 인해 유효성 검사기가 더 단순 해지고 추적 만하면됩니다. {와 {, 어떤 키가 이미 사용되었는지 알 필요는 없습니다.
William Entriken

16

면책 조항 : 이건 실로

실제로 의견을 추가하고 사양 내에 머무를 수있는 방법이 있습니다 (추가 파서가 필요 없음). 그래도 구문 분석이 없으면 사람이 읽을 수있는 주석이 생성되지 않습니다.

다음을 남용 할 수 있습니다.

토큰 앞뒤에 중요하지 않은 공백이 허용됩니다. 공백은 문자 코드 (U + 0009), 줄 바꿈 (U + 000A), 캐리지 리턴 (U + 000D) 및 공백 (U + 0020) 중 하나 이상의 코드 포인트 시퀀스입니다.

해킹 된 방식으로이를 악용하여 주석을 추가 할 수 있습니다. 예를 들어 : 탭으로 주석을 시작하고 종료하십시오. base3에 주석을 인코딩하고 다른 공백 문자를 사용하여 주석을 표시하십시오. 예를 들어.

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threeASCII에서) 그러나 0 대신 공간을 사용하고 1은 줄 바꿈을 사용하고 2는 캐리지 리턴을 사용하십시오.

이것은 IDE를 플러그인하여 즉시 인코딩 / 디코딩하지 않는 한 읽을 수없는 많은 공백을 남겨 둡니다.

나는 명백한 이유 때문에 이것을 시도조차하지 않았으며 당신도 마찬가지입니다.


12

우리는 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는 이러한 타당성 주석을 포함하고 더 이상 유효한 JSON이 없습니다.
Roy Prins

12

필자의 경우 JSON 구조의 출력 전에 디버그 목적으로 주석을 사용해야합니다. 따라서 클라이언트를 손상시키지 않기 위해 HTTP 헤더에 디버그 정보를 사용하기로 결정했습니다.

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

여기에 이미지 설명을 입력하십시오


12

JSON은 자체적으로 주석을 허용하지 않습니다. 추론은 JSON을 사용할 수 있기 때문에, 완전히 어리석은 자신을 완전히 추론을 미연에 방지하는 의견을 생성, 부하 전혀 좋은 이유에 대한 파서 데이터 공간 정확히 같은 결과 그들은이 같은 잠재적 인 문제로서, JSON 주석이 포함 된 파일.

주석을 사용 //하거나 ( 예를 들어 /* */또는 사용하여) 주석을 넣으려고 #하면 JSON 구문에 엄격히 포함되지 않기 때문에 일부 파서가 실패합니다. 그러니 절대 그렇게 해서는 안됩니다 .

예를 들어 내 이미지 조작 시스템 이 이미지 표기법과 이미지 형식과 관련된 기본 형식 (코멘트) 정보를 저장했습니다 (아래쪽).

{
    "Notations": [
        {
            "anchorX": 333,
            "anchorY": 265,
            "areaMode": "Ellipse",
            "extentX": 356,
            "extentY": 294,
            "opacity": 0.5,
            "text": "Elliptical area on top",
            "textX": 333,
            "textY": 265,
            "title": "Notation 1"
        },
        {
            "anchorX": 87,
            "anchorY": 385,
            "areaMode": "Rectangle",
            "extentX": 109,
            "extentY": 412,
            "opacity": 0.5,
            "text": "Rect area\non bottom",
            "textX": 98,
            "textY": 385,
            "title": "Notation 2"
        },
        {
            "anchorX": 69,
            "anchorY": 104,
            "areaMode": "Polygon",
            "extentX": 102,
            "extentY": 136,
            "opacity": 0.5,
            "pointList": [
                {
                    "i": 0,
                    "x": 83,
                    "y": 104
                },
                {
                    "i": 1,
                    "x": 69,
                    "y": 136
                },
                {
                    "i": 2,
                    "x": 102,
                    "y": 132
                },
                {
                    "i": 3,
                    "x": 83,
                    "y": 104
                }
            ],
            "text": "Simple polygon",
            "textX": 85,
            "textY": 104,
            "title": "Notation 3"
        }
    ],
    "imageXW": 512,
    "imageYW": 512,
    "imageName": "lena_std.ato",
    "tinyDocs": {
        "c01": "JSON image notation data:",
        "c02": "-------------------------",
        "c03": "",
        "c04": "This data contains image notations and related area",
        "c05": "selection information that provides a means for an",
        "c06": "image gallery to display notations with elliptical,",
        "c07": "rectangular, polygonal or freehand area indications",
        "c08": "over an image displayed to a gallery visitor.",
        "c09": "",
        "c10": "X and Y positions are all in image space. The image",
        "c11": "resolution is given as imageXW and imageYW, which",
        "c12": "you use to scale the notation areas to their proper",
        "c13": "locations and sizes for your display of the image,",
        "c14": "regardless of scale.",
        "c15": "",
        "c16": "For Ellipses, anchor is the  center of the ellipse,",
        "c17": "and the extents are the X and Y radii respectively.",
        "c18": "",
        "c19": "For Rectangles, the anchor is the top left and the",
        "c20": "extents are the bottom right.",
        "c21": "",
        "c22": "For Freehand and Polygon area modes, the pointList",
        "c23": "contains a series of numbered XY points. If the area",
        "c24": "is closed, the last point will be the same as the",
        "c25": "first, so all you have to be concerned with is drawing",
        "c26": "lines between the points in the list. Anchor and extent",
        "c27": "are set to the top left and bottom right of the indicated",
        "c28": "region, and can be used as a simplistic rectangular",
        "c29": "detect for the mouse hover position over these types",
        "c30": "of areas.",
        "c31": "",
        "c32": "The textx and texty positions provide basic positioning",
        "c33": "information to help you locate the text information",
        "c34": "in a reasonable location associated with the area",
        "c35": "indication.",
        "c36": "",
        "c37": "Opacity is a value between 0 and 1, where .5 represents",
        "c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
        "c39": "backdrop. Recommendation is that regions be drawn",
        "c40": "only if the user hovers the pointer over the image,",
        "c41": "and that the text associated with the regions be drawn",
        "c42": "only if the user hovers the pointer over the indicated",
        "c43": "region."
    }
}

"추론"링크가 끊어졌습니다. 현재 링크를 찾을 가능성이 있습니까?
Don Hatch

안타깝게도 Google은 게시물이 포함 된 소셜 미디어 시스템을 중단했습니다. 어딘가에 원래 포스터가 어디에서 왔는지 전혀 모른다. 위의 정보에서 링크를 제거하여 모호성을 제거합니다. 감사.
fyngyrz

추론은 어리석지 않으며 , 당신은 그것을 증명했습니다. 태그로 주석을 구현하면 상호 운용성이 유지 됩니다. 이것이 바로 Crockford가 주석을 태그로 해석하기를 원했던 이유입니다. 이제 모든 것이 태그 일 뿐이며 같은 방식으로 구문 분석 됩니다.
Dominic Cerisano

스펙에서 "#으로 시작하는 행이 주석"이라고 언급 한 경우에는 완전히 상호 운용 가능합니다. 그대로, 주석은 주석으로 이해되지 않고 유효한 구문 분석 된 항목 이므로 구문 분석기 공간을로드하며, 존재하는 모든 .json 파일마다 다를 수 있습니다. 예를 들어 스펙에서 "#으로 시작하는 행이 주석"이라고 말한 경우 구문 분석기는 구문 분석하지 않고 해당 행을 건너 뛰고 (빠른) 구문 분석기 공간을로드하지 않을 수 있습니다 (메모리 사용률 향상). .json의 주석 만 단점입니다.
fyngyrz

11

JSON 항목을 부분으로 자르려면 "더미 주석"줄을 추가합니다.

{

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

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

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

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

}

15
JSON에서 INI 파일 구조를 에뮬레이션했습니다. 황금 망치를 내려 놓으십시오.
Artur Czajka

4
RFC는 "객체 내의 이름은 고유해야한다"고 말합니다. : 또한 위와 같이 JSON을 구문 분석 오류 데이 사람이 볼 stackoverflow.com/questions/4912386/...
윌리엄 Entriken

스키마를 사용하여 JSON의 유효성을 검사하는 경우 추가 필드로 인해 실패 할 수 있습니다.
gregsdennis 2016 년

1
JSON에 주석을 추가하기로 결정했다면 다음과 같이하는 것이 훨씬 더 합리적입니다 { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } . 이름을 고유하게 유지하고 원하는 문자열 값을 추가 할 수 있습니다. 주석은 JSON의 일부가 아니므로 여전히 문제가됩니다. 또 다른 대안으로 JSON 앞뒤에 주석을 추가하지 말고 주석을 추가하지 않는 이유는 무엇입니까?
Jazimov
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.