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

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/jsonJavaScript Object Notation（JSON）のメディアタイプ
• RFC 8259 JavaScript Object Notation（JSON）データ交換フォーマット（RFC 4627、7158、7159に優先）

必要に応じてコメントを含めます。解析または送信する前に、それらをミニファイアで取り除きます。

JSONのブロックからコメントと空白を取り除き、解析できる有効なJSONにするJSON.minify（）をリリースしました。したがって、次のように使用できます。

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

それをリリースしたとき、私はそれについてさえ意見に反対する人々の大きな反発を得たので、コメントがJSONで意味をなす理由について包括的なブログ投稿を書くことにしました。JSONの作成者からの次の注目すべきコメントが含まれています。

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

うまくいけば、JSON.minify（）が有用である理由に反対する人にとって役立つでしょう。

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

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

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

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

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

指摘されているように、このハックは仕様の実装を利用しています。すべての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]
}

つまり、コメントの痕跡はなく、奇妙な副作用もありません。

ハッキングハッピー！

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

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

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

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

できません。少なくとも、これはjson.orgをざっと見た私の経験です。

JSONの構文はそのページで視覚化されています。コメントについてのメモはありません。

コメントは公式の標準ではありませんが、一部のパーサーは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です。

代わりに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);

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

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

いいえ。以前は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

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

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

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

// "名前"： "文字列"

// "id"：int

または

/* これは

コメント例* /

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cf：Douglas Crockford、JSON仕様の作成者。

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

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

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ファイルからコメントを取り除くことを忘れないでください！

JSON5を使用する場合は、コメントを含めることができます。

JSON5はJSONの拡張案として提案されており、人間が手作業で簡単に記述および保守できるようにすることを目的としています。ECMAScript 5から直接いくつかの最小限の構文機能を追加することにより、これを行います。

Dojo Toolkit JavaScriptツールキット（少なくともバージョン1.4以降）では、JSONにコメントを含めることができます。コメントは/* */形式にすることができます。Dojo Toolkitは、JSONをdojo.xhrGet()呼び出します。

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

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

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

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

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たため、コメントを削除する必要がありました。

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

いいえ、サイドチャネルデータを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つ以上のシーケンスです。文字の集計（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プラグインを作成しない限り）。

明らかな理由で私もこれを試したことはなく、あなたもそうすべきではありません。

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構造の出力の前に、デバッグ目的でコメントを使用する必要があります。クライアントを壊さないように、HTTPヘッダーのデバッグ情報を使用することにしました。

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

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

JSONアイテムを分割するために、「ダミーコメント」行を追加します。

{

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

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

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

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

}