JSONでコメントを使用できますか?


7610

JSONファイル内でコメントを使用できますか?もしそうなら、どうですか?


153
@StingyJack:明白ではないことや、コメントで他に何ができるかを説明するため。私はデータファイルにコメントを付けることがよくあります。XML、iniファイル、およびその他の多くの形式には、コメントの規定が含まれています。
マイケルバー

24
私のよう//commentsに、Sublime Text構成ファイルの特定のユースケースに問題がないかどうか疑問に思っている場合、答えはイエスです(バージョン2以降)。Sublime Textはそれについて不平を言うことはありません{"__comment": ...}が、コンソールでは不平を言うでしょう。これは予期しないフィールドだからです。
ドリフトキャッチャー2013

8
そしておそらくこれがTOMLが作成された理由の1つです。–
Alex Nolasco

10
JSONのコメントに//を使用してみました。今、私はそれが交換/交換に厳密に使用されていることに気づきました。はぁ!これ以上コメントできません:(。Life is doomed !.
Sid

12
JSON5はコメントをサポートします:stackoverflow.com/a/7901053/108238
schoetbi

回答:


5594

番号。

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 text goes here...",
ロブ・フォンセカ・アンソールは

19
ところで、Java google-gsonのjsonライブラリはコメントをサポートしています。
12

11
AccronymおよびAbbrevプロパティについて個別のコメントが必要な場合はどうなりますか?私は以前このパターンを使用したことがありますが、それができないのでやめました。ハックです。__comment__代わりにプロパティ名を追加するとします。それは「__comment__Abbrev」であり、まだハックですが、すべての義務についてコメントさせてください
Juan Mendes

41
"//"を使用することもできます。これはよりネイティブに見え、同じ親で繰り返し可能です
smnbbrv

4
人間が意図した構成ファイルにJSONを使用する場合、人間がより理解できるように注釈を付ける必要があります。注釈付き、そのようなファイルはもはや有効なJSONではありませんが、解決策があります。たとえば、GoogleのGYPは#スタイルのコメントをサポートしています。JSON.Minifyは、入力ファイルからC / C ++スタイルのコメントを破棄するのに役立ちます。
ПетърПетров

1842

いいえ、フォームのコメント、//…または/*…*/JSONでは許可されていません。この回答は以下に基づいています:

  • http://www.json.org
  • RFC 4627application/jsonJavaScript Object Notation(JSON)のメディアタイプ
  • RFC 8259 JavaScript Object Notation(JSON)データ交換フォーマット(RFC 4627、7158、7159に優先)

67
JSONにコメントで注釈を付ける(つまり、JSONを無効にする)場合は、解析または送信する前に縮小してください。Crockford自身は、2012年に構成ファイルのコンテキストでこれを認めました。
toolbear 2014

25
@alkuzad:正式な文法に関しては、それら許可されていることを明示的に述べているものでなければならず、その逆ではありません。たとえば、選択するプログラミング言語を考えてみます。必要な(ただし欠落している)機能が明示的に許可されていないからといって、コンパイラーが魔法のようにそれを認識するという意味ではありません。
stakx

5
はい。JSON形式は要素間に多くのデッドスペースがあり、それらの領域ではスペースに依存しません。そのため、そこに単一行または複数行のコメントを付けることができない理由はありません。多くのパーサーとミニファイアはJSONコメントもサポートしているので、パーサーがそれらをサポートしていることを確認してください。JSONはアプリケーションデータと構成設定に多く使用されるため、コメントが必要です。「公式仕様」はいい考えですが、不十分で時代遅れなので、残念です。ペイロードのサイズやパフォーマンスが気になる場合は、JSONを縮小してください。
Triynko 2017年

58
あなたの答えは完全に正しいですが、これはBSであると言う必要があります。非常に多くのエンドユーザーがjson設定の必要性に遭遇しているため、コメントは非常に役立ちます。いくつかの缶詰の帽子がJSON 機械可読であり、常に機械可読である必要があると決定したからといって、人間がそれを読む必要があるという事実を無視すると、小さな心の茶番ではないでしょう。
cmroanirgo

18
@cmroanirgo:JSONの制限について不満を言うのは、あなたが最初ではないことは明らかです...そのため、コメント、およびYAMLやJSON5などの他の形式を黙って許可するパーサーがあります。ただし、これによってJSONが実際にあるという事実は変わりません。むしろ、問題の制限を考えると、そもそもそもそもそもそもJSONが明らかに十分ではなかった目的でJSONを使い始めたことは興味深いと思います。JSON形式のせいにしないでください。特に適さない場所での使用を主張したことを非難してください。
stakx-2018年

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 '25

56
JSON.minify()の推奨代替アルゴリズムをgithubリポジトリに送信して、サポートされているすべての言語に移植できるようにすると便利
Kyle Simpson

16
@MiniGod私はすでにこのトピックに関するDougの考えを何度も聞いています。私はずっと前に私のブログ記事でそれらに対処しました:blog.getify.com/json-comments
カイル・シンプソン

18
@ MarnenLaibow-Koserデータストリーム(またはパケット)の使用についても、コメントの有効な使用法はまだあります。作成時間やソースなどの診断メタデータを含めることは、XMLで一般的に使用され、JSONデータにも完全に適しています。コメントに対する引数は浅く、テキストデータ形式では、暗黙の使用目的にかかわらず、コメントを許可する必要があります(JSONが他の場所で使用できないことを示す仕様はありません、fwiw)
StaxMan

18
JSONが普遍的に受け入れられる場合(基本的にそうです)、普遍的なアプリケーションが必要です。例:JSONはアプリケーション構成ファイルとして機能できます。このアプリケーションはコメントを望みます。
eggmatters

441

コメントはJSONから意図的に削除されました。

JSONからコメントを削除したのは、人々がそれらを使用して解析ディレクティブを保持しているのを見たからです。コメントの欠如は一部の人々を悲しくさせることを知っていますが、それはそうではありません。

JSONを使用して、注釈を付けたい構成ファイルを保持しているとします。先に行き、あなたが好きなすべてのコメントを挿入してください。次に、それをJSONパーサーに渡す前に、JSMinを介してパイプします。

出典:G +に関するDouglas Crockfordによる公式声明


198
JSONは、たとえばXMLよりも人間が読みやすいものだと思いましたか?コメントは読みやすくするためのものです。
intrepidis 2012年

25
とにかく、いたずらでJSONに解析ディレクティブを追加できます:{"__directives":{"#n#": "DateTime.Now"}、 "validdate": "#n#"} ... YAMLのように見えます次に進む方法です...
intrepidis

73
個人的な意見:コメントを許可しないことは不十分です。私は、構成ファイルをデコードするために、コメントを無視する非標準のJSONパーサーを作成する以外に選択肢はありませんでした。
caiosm1005 2013

17
@ArturCzajka JSONがコメントをサポートしていないという事実はまだ嫌いですが、INIを試してみたので、JSONを介してそれらを構成ファイルに使用する方がはるかに理にかなっていることを認めなければなりません。返事をありがとう。うまくいけば、この会話を読んでもっと多くの人が考えを変えてくれるでしょう。(とにかく、パーサーを作成することは、より練習問題でした:)
caiosm1005 2013年

77
これは、自転車に乗れない人がいるので、すべての自転車に補助輪を付けることを要求するようなものです。愚かな人々が悪用するので重要な機能を削除することは悪いデザインです。データ形式は、ばかであるよりも使いやすさを優先する必要があります。
Phil Goetz、2015年

205

免責事項:あなたの保証は無効です

指摘されているように、このハックは仕様の実装を利用しています。すべてのJSONパーサーがこの種のJSONを理解するわけではありません。特にストリーミングパーサーは窒息します。

興味深い好奇心ですが、実際には何にも使用しないでください。以下は元の答えです。


解析に影響を与えたり、表現されているデータを変更したりしないコメントをJSONファイルに配置できる小さなハックを見つけました。

オブジェクトリテラルを宣言するときに、同じキーで2つの値を指定でき、最後の値が優先されるようです。信じられないかもしれませんが、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
仕様から:オブジェクト内の名前は一意である必要があります。
クエンティン

113
「すべての実装で同じように処理されます」—これは証明するのが難しいことです。
Quentin

91
JSONの要素の順序は保証されません。つまり、「最後の」アイテムは変更される可能性があります。
sep332 2013

66
これは明らかに仕様に違反しています(上記のコメントを参照)。これを行わないでください。ietf.org/rfc/rfc4627.txt?number=4627
voidlogic

334
いいえ -パーサーがストリーミングしている場合はどうなりますか?パーサーがそれを、キーの順序が定義されていない辞書に読み込んだ場合はどうなりますか?火でこれを殺します。
deanWombourne 2013

183

JSONはコメントをサポートしていません。また、コメントが必要な構成ファイルに使用することも想定されていませんでした。

Hjsonは人間用の構成ファイル形式です。緩和された構文、少ない間違い、より多くのコメント。

Hjsonイントロ

JavaScript、Java、Python、PHP、Rust、Go、Ruby、C#ライブラリについては、hjson.orgをご覧ください。


13
賛成。それは明らかに非公開の保守的な人々がた​​だ憎むことを好む良いバリエーションです。私はあなたの実装がさらに知られることを願っています-おそらく元の実装よりも人気があります;)私も誰かがRubyでそれを実装することを望んでいます。@adelphus明確に定義されている言語は、あなた自身の見方や意見です。自分が保守的な「開発者」であることは、自分が優れていることを証明するものではなく、限られたスペースに閉じ込められたままにしておくとさらに悪化する可能性があります。人をひどい開発者と簡単に判断してはいけません。
konsolebox 2014年

7
申し訳ありませんが、@ konsolebox。おそらく、ecma-international.org / publications / files / ECMA-ST / ECMA-404.pdfを読んだ後、「明確に定義されたJSONはあなたの意見」ビューを再考するかもしれません。これは、実際の標準であり、開発者は独自の「特別な」バージョンを実装しています断片化、混乱、そして多くの時間の無駄につながります。各ブラウザーがわずかに異なるバージョンの標準を実装しているという理由だけでコードを書くとき、混乱したWeb開発者に残されたものを見てください。JSON言語は完全ではないかもしれませんが、断片化はさらに悪いものです。そして、はい、それはただの意見であり、あなたは自由に反対することができます。
adelphus 2014

22
私はあなたの欲望に感心しますが、あなたはちょっとYAMLを再発明しています。多くの柔軟性と人間の可読性が必要な場合は、YAMLを使用するか(実際には使用しないでください:stackoverflow.com/questions/450399/…)、あいまいでなく明確なJSONを使用してください。
toolbear 2014

4
最も使いやすい設定形式はまだINIです。これは単純で、構文にそれほど負荷がかかりません。これは、設定池につま先を浸すだけのユーザーにとっては、あまり威圧されません。
マット、

14
configとしてjsonが必要なときはいつでも(コメント必要な場合)-ファイルに「.json」ではなく「.js」という名前を付けます。jsはもちろん有効なjsonオブジェクトを処理でき、さらにコメント処理できます。それが理由です。 「webpack.config.json」ではなく「webpack.config.js」(webpack:Pにも、これには多くの理由があります)
jebbie

122

YAMLの使用を検討してください。これはJSONのほぼスーパーセットであり(事実上すべての有効なJSONは有効なYAMLです)、コメントを許可します。


12
@ g33kz0r正しいので、JSONのほぼスーパーセットとしてのYAMLの説明。
Marnen Laibow-Koser

12
@NateS多くの人が答えはノーだとすでに指摘していた。OPの目標を達成するためのより良い方法を提案しました。それが答えです。
Marnen Laibow-Koser 2014

5
欠点:yamlライブラリはPythonに同梱されていません。
出血の指

6
@ marnen-laibow-koser:ああ、JavaとPerlで利用可能なYAMLライブラリを使用して、それぞれが生成したYAMLがエラーなしに他のYAMLで消費されることを期待するのは無能だったに違いありません。YAMLの相互運用性は問題でしたが、JSONの相互運用性は問題ではありませんでしたが、私の知識の欠如によって完全に説明されています。
toolbear 2014

3
@ marnen-laibow-koser、同じことをより単純な仕様で実現する形式の方が優れています。完璧な実装の実用的な形式は、不完全な実装の理想的な形式よりも優れています。不完全なライブラリのすべての責任が実装者の肩にあるわけではありません。YAML仕様は長く、密度が高く、鈍いです。そのウィキペディアのエントリは、あい​​まいさの2つの例を挙げています。あいまいさからそれらを保護するために人間とフォーマットの間にエミッターを置かなければならない場合、フォーマットは人間に優しい主張を失います。JSONはより少なく主張し、YAMLがより多くを主張し、不足しているところでほとんど成功します。
toolbear 2014

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、2015年

Newtonsoft Json.NETも問題なくCスタイルのコメントをサポート
最大

66

代わりにJSONスキーマを記述する必要があります。JSONスキーマは、現在提案されているインターネットドラフト仕様です。ドキュメントの他に、スキーマはJSONデータの検証にも使用できます。

例:

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

説明スキーマ属性を使用して、ドキュメントを提供できます。


5
JSONスキーマは有効ですか?存在しますが、既知のライブラリでサポートされていますか?
Munhitsu、2012年

1
はい、json-schema googleグループはかなりアクティブであり、JSONスキーマバリデーターの適切なJavaScript実装にはJSVをお勧めします。
ラッフル

5
これは、アドホックなドキュメントではなく、構造化されたドキュメントでのみ役立ちます
Juan Mendes 2013

clojureを使用している場合(使用しないと確信しています)、適度に機能するオープンソースのJSONスキーマパーサーがあります:github.com/bigmlcom/closchema
charleslparker

@Munhitsu Manatee.Json(.Net)は、JSONスキーマを幅広くサポートしています。
gregsdennis 2015年

64

JSONパーサーとしてジャクソンを使用している場合、次のようにしてコメントを許可できます。

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

次に、次のようなコメントを付けることができます。

{
  key: "value" // Comment
}

また、次のように#設定してコメントを開始することもできます。

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

しかし、一般に(以前に回答したように)仕様ではコメントを許可していません。


50

JSONでコメントを付けることができるGoogle Firebaseのドキュメントで私が見つけたものは次のとおりです。

{
  "//": "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 Realtime Databaseでは、キーに「/」を使用できません。したがって、これはあなた自身の使用に適した慣例ですが、Firebaseでそれを行うことはできません
gutte

5
このメソッドは、キーが一意である必要があるいくつかのライブラリを壊します。私はコメントに番号を付けることでその問題を回避しています。
MovGP0

良いコメント、私はSOにこの質問を見つけました...この部分はスペックによって覆われていないようだstackoverflow.com/questions/21832701/...
マナ

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)です。

この唯一の必要な注釈は、「//これらはDAGタグです」である可能性があります。キー名は、必要に応じて情報を提供できるため、任意のセマンティックアリティが許可されます。

どのプラットフォームでも、ほんの数行のコードでJSONを解析できます。XMLには、多くのプラットフォームで実行できない複雑なOOライブラリが必要です。

注釈は、JSONの相互運用性を低下させるだけです。本当に必要なものがマークアップ言語(XML)でない限り、他に追加することは何もありません。永続化されたデータが簡単に解析されるかどうかは気にしないでください。

しかし、JSONの作成者も観察したように、コメントに対するJSパイプラインのサポートは常にあります。

先に行き、あなたが好きなすべてのコメントを挿入してください。それをJSONパーサーに渡す前に、JSMinを介してパイプします。- ダグラス・クロックフォード、2012


37

JSON文字列であるテキストファイルがいくつかのプログラムによって読み取られる場合、使用する前にCまたはC ++スタイルのコメントを取り除くのはどれほど難しいでしょうか。

回答:ワンライナーになります。これを行うと、JSONファイルを構成ファイルとして使用できます。


1
おそらく使用前に前処理が必要なため、ファイルを交換形式として保持することには依然として問題がありますが、おそらくこれまでのところ最良の提案です。
2010

私は同意し、www.SoftwareMonkey.orgで入手可能なJavaでJSONパーサーを作成しました。
ローレンスドル

2
(別の交換形式と呼ばずに)JSONを拡張することは良い考えではないと思います。文字列内の「コメント」を無視するようにしてください。{"foo": "/ *これはコメントではありません。* /"}
stofl

27
「...ワンライナーになる」うーん、いや、実際には、JSONは正規表現ではないため、正規表現は/ *の一致するペアを簡単に見つけることができます。/ *が文字列内にあるかどうか(そして無視するか)、またはエスケープされているか(そして無視するか)などを見つけるためにファイルを解析する必要があります。任意のソリューション。
Kyle Simpson、

1
@ kyle-simpsonが言ったこと。また、彼はあまりにも控えめすぎて、アドホック正規表現の代わりにJSON.minifyを使用することについての彼自身の答えに読者を向けることができません。これではなく、そうしてください。
toolbear 2014

36

ASP.NETでNewtonsoft.Jsonライブラリを使用して読み取り/逆シリアル化する場合は、JSONコンテンツでコメントを使用できます。

// "名前": "文字列"

// "id":int

または

/* これは

コメント例* /

PS:単一行コメントは、6 +バージョンのNewtonsoft Jsonでのみサポートされています。

すぐに考えることができない人のための追加の注意:私が作成したASP.NET Webアプリケーションの基本設定にはJSON形式を使用します。ファイルを読み取り、Newtonsoftライブラリを使用して設定オブジェクトに変換し、必要に応じて使用します。

私は、JSONファイル自体の個々の設定についてコメントを書くことを好みます。私が使用するライブラリーで問題がなければ、JSON形式の完全性については気にしません。

これは、個別の「settings.README」ファイルを作成し、その設定を説明するよりも「使いやすく、理解しやすい」方法だと思います。

この種の使用法に問題がある場合; 申し訳ありませんが、魔神はランプの外にあります。人々はJSONフォーマットの他の使用法を見つけるでしょう、そしてそれについてあなたができることは何もありません。


なぜ誰かが事実を述べることに問題があるのか​​理解するのは難しい。
dvdmn 14

上記はもはやJSONではないか、JSONが無効であるため、誰かが例外をとったと思います。おそらく、短い免責事項を追加することで和らげるでしょう。
toolbear

5
私はあなたに完全に同意しますが、明白なことを述べているだけの非回答に対する883の賛成投票があります。有用な情報よりも高く評価されたイデオロギーの純粋さ、それはあなたにとってSOです。
John

重要なのは、コメントが含まれているファイルがJSONではなく、多くのJSONライブラリによる解析に失敗することです。自分のプログラムで好きなようにしてかまいませんが、コメント付きのファイルはJSONではありません。そうだと主張すると、人々は選択した言語/ライブラリでそれを解析しようとし、失敗します。これは、XMLで山括弧の代わりに角括弧を使用できるかどうかを尋ねるようなものです。やりたいことは何でもできますが、XMLにはなりません。
gman

32

JSONの背後にある考え方は、アプリケーション間の単純なデータ交換を提供することです。これらは通常Webベースであり、言語はJavaScriptです。

コメント自体は実際には許可されていませんが、データ内の名前と値のペアの1つとしてコメントを渡すことは確実に機能しますが、そのデータは明らかに無視するか、解析コードで特に処理する必要があります。

そうは言っても、JSONファイルに従来の意味でのコメントを含める必要はありません。それは単なるデータであるべきです。

詳細については、JSON Webサイトを参照してください。


17
JSON形式にはコメントがないことは事実です。個人的には、これは重大な誤りだと思います。コメントをメタデータ(データではなく)として持つ機能は、xmlで非常に便利です。JSON仕様の以前のドラフトバージョンにはコメントが含まれていましたが、何らかの理由でコメントが削除されました。:-/
StaxMan 2009

4
@StaxManそれらは、人々がそれらをメタデータとして使用し始めたため、正確に削除されました。Crockford氏は、このフォーマットが設計されたものとの互換性を損なうと述べ、同意する。メタデータが必要な場合は、実際のデータとして含めないのはなぜか。この方法で解析する方が簡単です。
Camilo Martin

6
メタデータは、コメントではなく、メタデータ構造(HTML <meta>タグなど)に属します。メタデータのコメントを悪用することは、真のメタデータ構造が存在しない場合に使用されるハックにすぎません。
Marnen Laibow-Koser、2011

それこそが削除された理由です。メタデータとして使用されたコメントは相互運用性を損なうことになります。メタデータもJSONとして保存する必要があります。
2013年

1
この答えは冗長ですが、これは以前に書かれている可能性がありますが、よりよく書かれ、より高い賛成投票の回答、つまり本質的に同じことを言います。Cest la vie。
toolbear 2014

29

設定ファイルでこれに遭遇しました。XMLを使いたくない(冗長、グラフィカル、醜い、読みにくい)、または「ini」形式(階層なし、実際の標準なしなど)またはJavaの「プロパティ」形式(.iniなど)。

JSONは、できることはすべて実行できますが、冗長性が低く、人間が読める形式になっています。また、パーサーは、多くの言語で簡単かつ広く普及しています。これは単なるデータのツリーです。しかし、アウトオブバンドのコメントは、「デフォルト」構成などを文書化するためにしばしば必要になります。構成は決して「完全なドキュメント」であってはなりませんが、必要なときに人間が読めるように保存されたデータのツリーです。

"#": "comment"「有効な」JSONの場合は、を使用できると思います。


4
構成ファイルについては、JSONではなくYAMLをお勧めします。これは(ほぼ)より強力なJSONのスーパーセットですが、コメントなど、より読みやすい構文もサポートしています。
Marnen Laibow-Koser、2011

1
jsonと比較して、すぐにYAMLをサポートする言語はいくつあると思いますか
mmm 2012年

@Hamidam 1ダースを超える言語がyaml:yaml.orgをサポートしていますが、サードパーティのライブラリに依存する必要なく、組み込みのサポートがいくつあるか尋ねるのは当然です。Ruby 1.9.2のように見えます。誰か他の人を知っていますか?そして、どの言語がデフォルトでjsonのサポートを出荷しますか?
nealmcb

5
YAML相互運用は嘘です:stackoverflow.com/questions/450399/…。設定ファイルにJSONを使用するのが本能の場合は、それに従ってください。
toolbear 2014

これは古いですが、#を使用するのは良い考えではないと思います。Jsonは、Javascriptリテラルの構文に近いものです。Javascriptは2種類のコメントをサポートしています://と/ * ... * /もし私があなたなら、これらのタイプのコメントの一方または両方にこだわるでしょう。
Pascal Ganaye

28

JSONはコメントをネイティブでサポートしていませんが、独自のデコーダーまたは少なくともプリプロセッサーを作成してコメントを取り除くことができます。これは完全に問題ありません(コメントを無視して、アプリケーションがJSONデータを処理する方法のガイドとして使用しない限り)。 )。

JSONにはコメントがありません。JSONエンコーダーはコメントを出力してはいけません。JSONデコーダーはコメントを受け入れても無視してもかまいません。

コメントは、意味のあるものを送信するために使用しないでください。それがJSONの目的です。

Cf:Douglas Crockford、JSON仕様の作成者


4
Crockfordは、「JSONを使用して構成ファイルを保持していると仮定します。注釈を付けます。先に進んで、必要なすべてのコメントを挿入してください。次に、JSMパーサーに渡す前に、JSMinにパイプしてください。」詳細については、JSON.minifyに関する@ kyle-simpsonの回答をご覧ください。
toolbear 2014

28

それはあなたのJSONライブラリに依存します。Json.NETはJavaScriptスタイルのコメントをサポートしています/* commment */

別のスタックオーバーフローの質問を参照してください。


そして私は、私は(package.json下)このASP.NET vNextプレビューページのスクリーンショットのコメントを参照してください理由があると信じて:blogs.msdn.com/b/webdev/archive/2014/06/03/...が、私の避難所スペックにはまだ何も見つかりません。
webXL 2014

27

JSONはユビキタスであり、XMLよりもはるかに単純であるため、構成ファイルやその他のローカルでの使用には意味があります。

データを通信するときにJSONにコメントを付けることに対して強い理由がある場合(有効かどうかにかかわらず)、JSONは2つに分割される可能性があります。

  • JSON-COM:通信中のJSON、またはJSONデータの通信時に適用されるルール。
  • JSON-DOC:JSONドキュメント、またはファイル内またはローカルのJSON。有効なJSONドキュメントを定義するルール。

JSON-DOCはコメントを許可しますが、空白の処理など、その他の小さな違いが存在する場合があります。パーサーは、ある仕様から別の仕様に簡単に変換できます。

この問題に関してダグラス・クロックフォードが行った発言について(@Artur Czajkaが参照)

JSONを使用して、注釈を付けたい構成ファイルを保持しているとします。先に行き、あなたが好きなすべてのコメントを挿入してください。次に、それをJSONパーサーに渡す前に、JSMinを介してパイプします。

私たちは一般的な設定ファイルの問題(クロスランゲージ/プラットフォーム)について話していて、彼はJS固有のユーティリティで答えています!

確かに、JSON固有のminifyはどの言語でも実装できますが、これを標準化すると、すべての言語とプラットフォームのパーサー全体でユビキタスになり、機能のユースケースがあり、問題を調べて、機能がないために時間を無駄にすることがなくなります。オンラインフォーラム、そして人々に彼らにそれを悪い考えだと言わせたり、テキストファイルからコメントを取り除くことを実装するのが簡単であることを示唆したりします。

もう1つの問題は相互運用性です。ライブラリ、API、またはいくつかの設定ファイルやデータファイルが関連付けられているサブシステムがあるとします。そして、このサブシステムは異なる言語からアクセスされます。次に、人に伝えますか?ところで、パーサーに渡す前に、JSONファイルからコメントを取り除くことを忘れないでください!


JSONをフラグメント化する必要はありません。コメント付きのJSONはJSONではなくなりました。ただし、JSONにコメントを付けて注釈を付けることは完全に許容されます。ただし、解析または送信する前に削除するようにしてください。これを行うのは受信者の責任であってはなりません。
toolbear 2014

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 Toolkitは、JSONをdojo.xhrGet()呼び出します。

他のJavaScriptツールキットも同様に機能します。

これは、最終的なオプションを選択する前に、代替データ構造(またはデータリスト)を試すときに役立ちます。


4
いいえ、これではありません。JSONにはコメントがありません。JSONにコメントで注釈を付ける場合は、解析または送信する前にそれを縮小してください。これは受信者の責任ではありません。
toolbear 2014

2
JSONにコメントがあるとは言いませんでした。特にプロダクションシステムでは、JSONにそれらを含めることが適切であることを暗示するつもりもありませんでした。私が言ったことをDojoツールキットが事実上真である(あるいは少なくとも、だった)これ、それらを追加することを許可します。テスト段階でそうするための非常に役立つユースケースがあります。
デビッド

1
コメントを提供することは悪いブードゥーであり、したがって無効なJSON dojo.xhrGet()です。
toolbear 2014

コメントを許可するために、JSON仕様のアップグレードにまだ投票しています。私はすべて、JSONを送信する前にコメントを縮小して削除することに賛成ですが、JSONを解析する前に別のユーティリティに渡さなくても、標準的な方法でJSONにコメントする機能はありません。また、ファイルが有効なJSONではないため、JSON構成ファイルでJSONエディターを使用できなくなります。
クレイグ

20

JSONはフレーム化されたプロトコルではありません。これは、ある言語フリーフォーマット。したがって、コメントの形式はJSONでは定義されていません。

多くの人が示唆しているように、たとえば、重複するキーや_comment使用できる特定のキーなど、いくつかのトリックがあります。それはあなた次第です。


18

JSONPではコメントを使用できます、純粋なJSON では使用できません。Highchartsの次の例でプログラムを動作させるために1時間費やしました。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]
]);

ローカルフォルダーに同様のファイルがあったため、Same-originポリシーには問題がなかったので、純粋なJSONを使用することにしました...そしてもちろん、$.getJSONコメントのために静かに失敗していました。

結局、私は手動で上記のアドレスにHTTPリクエストを送信し、コンテンツタイプがtext/javascriptJSONPが純粋なJavaScriptを返すようになったことに気づきました。この場合、コメントは許可されます。しかし、私のアプリケーションはcontent-typeを返しapplication/jsonたため、コメントを削除する必要がありました。


17

これは「できますか」という質問です。そして、ここに「はい」の答えがあります。

いいえ、サイドチャネルデータをJSONエンコーディングに詰め込むために重複オブジェクトメンバーを使用しないでください。(RFCの「オブジェクト内の名前は一意である必要があります」を参照してください)。

そして、はい、JSONの周りコメントを挿入し解析することができます。

しかし、任意のサイドチャネルデータを有効なJSONに挿入および抽出する方法が必要な場合は、ここに答えがあります。JSONエンコーディングでのデータの一意でない表現を利用します。これは許可されている*「の前または6つの構造のいずれかの文字の後に許可されているホワイトスペース」の下のRFCのセクション2で。

* RFCは、「6つの構造文字の前後に空白が許可される」とのみ述べており、文字列、数字、「false」、「true」、および「null」については明示的に言及していません。この省略は、すべての実装で無視されます。


まず、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は「6つの構造文字の前後に空白が許可される」とのみ述べており、文字列、数字、「false」、「true」、「null」については明示的に言及していません。この省略は、すべての実装で無視されます。
William Entriken 2014

1
コメント密度を高めるために、コメントを3値にエンコードし、スペース、タブ、改行を使用してコメント化できませんか?
クレアNielsen

必須ではありません。明示的に含まれているRFC 2119を参照してください:必須:この単語、または「必須」または「SHALL」という用語は、定義が仕様の絶対要件であることを意味します。...する必要があります:この単語または「推奨」という形容詞は、特定の状況で特定の項目を無視する正当な理由が存在する可能性があることを意味しますが、別のコースを選択する前に、すべての影響を理解し、慎重に検討する必要があります。
Jeff K

良い参照。重複したキーを使用しないことのより良い理由は、「オブジェクト内の名前が一意でない場合、そのようなオブジェクトを受け取るソフトウェアの動作は予測不可能です。」という標準の引用です。また、標準が「一意である必要がある」理由を理解しました。これにより、バリデーターがシンプルになり、[と{を追跡するだけで済みます。どのキーが既に使用されているかを知る必要はありません。
William Entriken

16

免責事項:これは愚かです

実際にコメントを追加し、仕様の範囲内にとどまる方法があります(追加のパーサーは必要ありません)。ただし、なんらかの解析を行わなければ、人間が読めるコメントにはなりません。

以下を悪用する可能性があります。

トークンの前後には、意味のない空白を入れることができます。空白は、次のコードポイントの1つ以上のシーケンスです。文字の集計(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 2013年

4
RFCは「オブジェクト内の名前は一意である必要があります」と述べています。:エラーをしているこの人は上記のようなJSONを解析する。またを参照してくださいstackoverflow.com/questions/4912386/...
ウィリアム・エントリケン

スキーマを使用してJSONを検証している場合、余分なフィールドが原因で失敗する可能性があります。
gregsdennis 2015年

1
JSONにコメントを追加することが本当に決まっている場合は、次のようなことを行う方が理にかなっています。{ "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } これにより、名前が一意に保たれ、好きな文字列値を追加できます。コメントはあなたのJSONの一部であってはならないので、それはまだ厄介です。別の方法として、JSONの前または後にコメントを追加して、JSON内に追加しないのはなぜですか?
Jazimov、2015
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.