いいえ
JSONはすべてデータである必要があります。コメントを含めると、それもデータになります。
JSONデータを使用するアプリでは無視される"_comment"（または何か）という指定されたデータ要素があります。
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 ： JavaScript Object Notation（JSON）の
application/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から削除されました。
私はJSONからコメントを削除しました。なぜなら、人々がそれらを解析ディレクティブを保持するために使用しているのを見たからです。私は、コメントの欠如が何人かの人々を悲しくさせることを知っていますが、そうではないはずです。
アノテーションを付けたい設定ファイルを保持するためにJSONを使用しているとします。先に進み、あなたが好きなコメントをすべて挿入してください。それをJSMinに渡してから、JSONパーサーに渡します。
出典： G +に関するダグラス・クロックフォードの声明 /
免責事項：あなたの保証IS無効
すでに指摘したように、このハックは仕様の実装を利用しています。すべての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 を参照してください。
できません。少なくともそれは json.org で一目見ただけの私の経験です。
JSONの構文はそのページに視覚化されています。コメントについてのメモはありません。
YAMLの使用を検討してください。これはほぼJSONのスーパーセット（事実上すべての有効なJSONは有効なYAMLです）であり、コメントを許可します。
代わりに JSONスキーマ を書く必要があります。 JSONスキーマは現在提案されているインターネットドラフト仕様です。ドキュメント以外にも、スキーマはJSONデータの検証にも使用できます。
例：
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
description schema属性を使用してドキュメントを提供できます。
JSONパーサーとして Jackson を使用している場合は、コメントを許可するためにこれを有効にする方法です。
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 _ toml _ に代わるものです。
これは私が 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.org にあるJSONの構文図を参照してください。
Douglas Crockfordは、「 なぜJSONのコメントを削除し、それに代わる方法を提供したのか 」：
私はJSONからコメントを削除しました。なぜなら、人々がそれらを解析指示を保持するために使用していたのを見たからです。私は、コメントの欠如が何人かの人々を悲しくすることを知っています、そうではないはずです。
あなたが設定ファイルを保存するためにJSONを使っているとしましょう。先に進んで、あなたが好きなコメントをすべて挿入してください。それをJSMinにパイプしてからJSONパーサーに渡します。
JSON文字列であるあなたのテキストファイルがあるプログラムによって読まれることになるならば、それを使用する前にCまたはC++スタイルのコメントを取り除くことはどれほど難しいでしょうか？
答え： /それはワンライナーでしょう。そうすればJSONファイルを設定ファイルとして使うことができます。
Newtonsoft.JsonライブラリをASP.NETと共に使用して読み取り/逆シリアル化する場合は、JSONコンテンツ内のコメントを使用できます。
// "name"： "string"
// "id"：int
または
/* これは
コメントの例* /
PS： /単一行コメントは、Newtonsoft Jsonの6+バージョンでのみサポートされています。
箱から出して考えることができない人々のための追加のメモ： 私は私が作ったASP.NET Webアプリケーションの基本設定にJSONフォーマットを使用します。私はファイルを読み、Newtonsoftライブラリを使ってそれを設定オブジェクトに変換し、必要に応じてそれを使用します。
私はJSONファイル自体に個々の設定についてのコメントを書くことを好みます、そして私が使用するライブラリがそれで問題ないのであれば、私は本当にJSONフォーマットの完全性を気にしません。
これは、個別の 'settings.README'ファイルを作成してその中の設定を説明するよりも、 '使いやすく理解しやすい'方法だと思います。
この種の使い方に問題があるならば。申し訳ありませんが、魔神はランプの外です。人々はJSONフォーマットの他の用法を見つけるでしょう、そしてあなたがそれについてできることは何もありません。
JSONの背後にある考え方は、アプリケーション間で簡単なデータ交換を提供することです。これらは通常Webベースであり、言語はJavaScriptです。
それ自体はコメントを許可していませんが、データ内の名前/値のペアの1つとしてコメントを渡すことは確かにうまくいきますが、そのデータは明らかに無視するか、解析コードによって特に処理する必要があります。
それだけではなく、JSONファイルに伝統的な意味でコメントを含めることを意図したものではありません。それはただのデータであるべきです。
詳細については JSONのWebサイト をご覧ください。
私は設定ファイルでこれに遭遇したところです。 _ xml _ （冗長、グラフィカル、見にくい、読みにくい）、 "ini"形式（階層なし、実際の標準などなし）、またはJava "Properties"形式（のような）は使いたくありません。 .ini）。
JSONはできることすべてを実行できますが、冗長さが少なく、人間が読みやすいものになっています。そして、パーサーは多くの言語で簡単で遍在しています。それは単なるデータの木です。しかし、「デフォルトの」設定などを文書化するには、アウトオブバンドのコメントが必要です。構成は決して「完全な文書」になることはありませんが、必要に応じて人間が判読できる保存済みデータのツリーです。
「有効な」JSONには"#": "comment"を使用できると思います。
JSONはコメントをネイティブにはサポートしていませんが、コメントを除外するために独自のデコーダまたは少なくともプリプロセッサを作成することはできます。 ）.
JSONに関するコメントはありません。 JSONエンコーダはコメントを出力してはいけません。 JSONデコーダはコメントを受け入れて無視してもよいです。
意味のあることを伝えるためにコメントを使うべきではありません。それがJSONの目的です。
それはあなたのJSONライブラリに依存します。 Json.NET はJavaScriptスタイルのコメント、/* commment */をサポートします。
別のスタックオーバーフローの質問 を参照してください。
JSONは、至る所に存在し、XMLよりもはるかに単純であるため、設定ファイルやその他のローカルな使用法にとって非常に意味があります。
データを通信するときにJSONにコメントを書くことに対して強い妥当な理由がある場合（有効かどうかにかかわらず）、JSONは2つに分割される可能性があります。
- JSON-COM：通信中のJSON、またはJSONデータを通信するときに適用される規則。
- JSON-DOC：JSONドキュメント、またはファイル内またはローカルのJSON。有効なJSON文書を定義する規則.
JSON-DOCはコメントを許すでしょう、そして空白の取り扱いのような他の小さな違いが存在するかもしれません。パーサーはあるスペックから別のスペックに簡単に変換できます。
この問題に関してDouglas Crockfordが行った 発言 について（@Artur Czajkaが参照）
アノテーションを付けたい設定ファイルを保持するためにJSONを使用しているとします。先に進み、あなたが好きなコメントをすべて挿入してください。それをJSMinに渡してから、JSONパーサーに渡します。
私たちは一般的な設定ファイルの問題（クロス言語/プラットフォーム）について話しています、そして彼はJS特有のユーティリティで答えています！
JSON固有の縮小化はどの言語でも実装できることを確認してください。これを標準化して、すべての言語およびプラットフォームのパーサーで偏在するようにしますオンラインフォーラムで問題を調べ、それを悪い考えだと言ったり、テキストファイルからコメントを削除するのは簡単だと言ったりするように人々に言わせる。
他の問題は相互運用性です。ライブラリやAPI、あるいは設定ファイルやデータファイルが関連付けられたサブシステムがあるとします。そしてこのサブシステムはさまざまな言語からアクセスされるべきです。それでは、人に話すことについて話しますか？ところで、 JSONファイルからコメントをパーサーに渡す前にそれらを削除することを忘れないでください。
JSON5 を使用する場合は、コメントを含めることができます。
JSON5はJSON に対して提案された拡張で、人間が手で書いたり保守したりするのを簡単にすることを目的としています。 ECMAScript 5から直接いくつかの最小限の構文機能を追加することによってこれを行います。
Dojo Toolkit JavaScriptツールキット（少なくともバージョン1.4以降）を使用すると、JSONにコメントを含めることができます。コメントは/* */フォーマットにすることができます。 Dojo Toolkitはdojo.xhrGet()呼び出しを介してJSONを消費します。
他のJavaScriptツールキットも同様に機能する可能性があります。
これは、最終的なオプションを選択する前に別のデータ構造（あるいはデータリスト）を試すときに役立ちます。
canは 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 policy には問題がなかったため、純粋なJSONを使用することにしました...そしてもちろん、$.getJSONはコメントのために黙って失敗する。
最終的に、上記のアドレスに手動のHTTPリクエストを送信したところ、JSONPが純粋なJavaScriptを返すため、コンテンツタイプがtext/javascriptであることがわかりました。この場合、コメントは許可されます。しかし、私のアプリケーションはcontent-type application/jsonを返したため、コメントを削除する必要がありました。
JSONはフレームプロトコルではありません 。 言語フリーフォーマット です。そのため、コメントのフォーマットはJSONでは定義されていません。
多くの人が示唆しているように、いくつかのトリックがあります。例えば、重複キーやあなたが使用できる特定のキー_commentです。それはあなた次第です。
これは "can you"の質問です。そして、ここに "yes"の答えがあります。
いいえ、重複したオブジェクトメンバーを使用して、サイドチャネルデータをJSONエンコーディングに詰め込むべきではありません。 （「オブジェクト内の名前は一意である必要があります」を参照してください RFCで ）。
はい、できます コメントを挿入around 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します。
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
出力は次のとおりです。
$jsonWithComment = $steg . $jsonMin;
免責事項：このIS SILLY
実際には、コメントを追加し、仕様内にとどまる方法があります（追加のパーサーは不要です）。ただし、なんらかの解析なしでは、人間が読み取れるコメントにはなりません。
以下を悪用する可能性があります。
トークンの前後には、意味のない空白が許可されます。空白は、文字タブ（U + 0009）、改行（U + 000A）、復帰（U + 000D）、およびスペース（U + 0020）の1つ以上のコードポイントのシーケンスです。
ハックな方法で、これを悪用してコメントを追加できます。たとえば、タブでコメントを開始および終了します。 base3でコメントをエンコードし、他の空白文字を使用してそれらを表します。例えば。
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
（ASCIIのhello base three）しかし、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である良い解決策（ハック）があります。 同じキーを2回（またはそれ以上）押してください。例えば：
{
"param" : "This is the comment place",
"param" : "This is value place",
}
JSONはこれを次のように理解します。
{
"param" : "This is value place",
}
JSON項目をいくつかの部分に切り取るために、「ダミーコメント」の行を追加します。
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
JSONは以前はコメントをサポートしていましたが、悪用されて標準から削除されました。
JSONの作成者から：
JSONからコメントを削除したのは、人々がそれらを解析ディレクティブを保持するために使用していたため、相互運用性が損なわれたためです。私は、コメントの欠如が何人かの人々を悲しくさせることを知っていますが、そうではないはずです。 - Douglas Crockford、2012
公式のJSONサイトは JSON.org です。 JSONはECMA Internationalによって standard として定義されています。規格を改訂するための申請プロセスは常にあります。アノテーションがいくつかの理由でJSON標準に追加されることはまずありません。
設計上のJSONは、XMLのリバースエンジニアリング（人間が解析できる）代替手段です。注釈が不要であるという点でさえ単純化されています。マークアップ言語でさえありません。目標は安定性と相互運用性です。
オブジェクト指向の「has-a」関係を理解している人なら誰でもJSON構造を理解できます - それがポイントです。これは、ノードタグ（キーと値のペア）を持つ単なる有向非巡回グラフ（DAG）です。これは、ほぼ普遍的なデータ構造です。
この唯一必要なアノテーションは「//これらはDAGタグです」かもしれません。キー名は必要に応じてわかりやすくすることができます。
どのプラットフォームでも数行のコードでJSONを解析できます。 XMLは、多くのプラットフォームで実行可能ではない複雑なOOライブラリを必要とします。
注釈はJSONを相互運用性を低下させるだけです。本当に必要なものがマークアップ言語（XML）でない限り、追加するものは他に何もありません。そして、永続化されたデータが容易に解析されるかどうかを気にしないでください。
JSONの作者はJSONにコメントを含めることを望みますが、それらを解析する前にそれらを取り除きます（Michael Burrによって提供される link を見てください）。 JSONにコメントがある場合は、それらを標準化して、JSONパーサーに任せてください。その論理には同意しませんが、残念ながらそれが標準です。他の人が示唆しているようにYAMLソリューションを使うのは良いことですが、それはライブラリの依存関係を必要とします。
コメントを削除したいが、ライブラリに依存したくない場合は、2行のソリューションがあります。これは、C++スタイルのコメントには有効ですが、他のコメントにも適用できます。
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
このソリューションは、JSONデータにコメント開始者が含まれていないことが確実な場合にのみ使用できます。 （ '//'）.
JSONの構文解析、コメントの削除、および追加のライブラリを使用しないもう1つの方法は、JavaScriptインタープリターでJSONを評価することです。そのアプローチの注意点は、もちろん、汚染されていないデータのみを評価したいということです（信頼されていないユーザー入力はありません）。これはNode.jsでのこのアプローチの例です - もう1つ注意、次の例ではデータを一度だけ読み込んでからキャッシュします。
data = require(fs.realpathSync(doctree_fp));
JSONはそれ自体コメントを許可していません。 JSONitselfを使用してコメントを作成できるため、推論はまったくばかげています。これにより、推論が完全に不要になり、andパーサーがロードされますまったく同じ同じ結果と潜在的な問題に対する正当な理由のないデータスペース。
（たとえば
//または/* */または#を使用して）コメントを入力しようとすると、一部のパーサーは厳密に内部にないため失敗しますJSON仕様。したがって、neverそれを行うべきではありません。
たとえば、私の 画像操作システム には、画像表記とそれらに関連するいくつかの基本的なフォーマット（コメント）情報（下部）が保存されています。
{
"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."
}
}
ため息なぜフィールドを追加しないのですか。
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
あなたの "notex"名が実際のフィールドと衝突しないようにしてください。
テキストファイルとしてロードしてからコメントを削除する場合は、コメント付きのJSONを使用できます。
そのために decomment libraryを使うことができます。以下は完全な例です。
入力JSON（ファイルinput.js）：
/*
* multi-line comments
**/
{
"value": 123 // one-line comment
}
テストアプリケーション：
var decomment = require('decomment');
var fs = require('fs');
fs.readFile('input.js', 'utf8', function (err, data) {
if (err) {
console.log(err);
} else {
var text = decomment(data); // removing comments
var json = JSON.parse(text); // parsing JSON
console.log(json);
}
});
出力：
{ value: 123 }
gulp-decomment 、 /grunt-decomment も参照してください。
" grunt-strip-json-comments "が見つかりました。
「JSONからコメントを削除します。 JSONファイルでコメントを使用できます。」
{
// Rainbows
"Unicorn": /* ❤ */ "cake"
}
コンテキストがNode.js設定の場合は、JSONの代わりにmodule.exportsを介したJavaScriptを検討することができます。
module.exports = {
"key": "value",
// And with comments!
"key2": "value2"
};
requireの構文は同じです。 JavaScriptの場合、ファイル拡張子は.jsになります。
私の場合は、JSON構造の出力の前に、デバッグ目的でコメントを使用する必要があります。そのため、クライアントを壊さないようにするために、HTTPヘッダーにデバッグ情報を使用することにしました。
header("My-Json-Comment: Yes, I know it's a workaround ;-) ");
あなたは正規表現による簡単な前処理を使うことができます。たとえば、次の関数はPHPでコメント付きのJSONをデコードします。
function json_decode_commented ($data, $objectsAsArrays = false, $maxDepth = 512, $opts) {
$data = preg_replace('~
(" (?:[^"\\\\] | \\\\\\\\ | \\\\")*+ ") | \# [^\v]*+ | // [^\v]*+ | /\* .*? \*/
~xs', '$1', $data);
return json_decode($data, $objectsAsArrays, $maxDepth, $opts);
}
それはすべてのPHPスタイルのコメントをサポートします：/ *、＃、//。文字列リテラルはそのまま保持されます。
PHPを使用している場合は、この関数を使用してJSON文字列から///*型のコメントを検索して削除し、それをオブジェクト/配列に変換できます。
function json_clean_decode($json, $assoc = true, $depth = 512, $options = 0) {
// search and remove comments like /* */ and //
$json = preg_replace("#(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|([\s\t]//.*)|(^//.*)#", '', $json);
if(version_compare(phpversion(), '5.4.0', '>=')) {
$json = json_decode($json, $assoc, $depth, $options);
}
elseif(version_compare(phpversion(), '5.3.0', '>=')) {
$json = json_decode($json, $assoc, $depth);
}
else {
$json = json_decode($json, $assoc);
}
return $json;
}
お役に立てれば！
いいえ、jsonに直接コメントを付けることはできません。ただし、 this で示唆されているように、次のようなことを行うことで同様の効果を達成できます。
{
"//name": "Name comment here",
"name": "Jack",
"//age": "Age comment here",
"age": "25"
}
ほとんどのJSONパーサーは、マッピングされていないプロパティを無視します。
もちろんJSONにコメントできます。 JavaScriptからコメント付きのJSONファイルを読むためには、それを解析する前にコメントを取り除くことができます（下記のコードを参照）。私はこのコードを改良することができると確信しています、しかしそれはregexpを使う人にとって理解しやすいです。
合成反射神経系のニューロン形状を指定するには、コメント付きのJSONファイルを使用します。実行中のニューロンシステムの中間状態を格納するためにコメント付きJSONも使用します。コメントがあるととても便利です。悪い考えだと言っていることを聞いてはいけません。
fetch(filename).then(function(response) {
return response.text();
}).then(function(commented) {
return commented.
replace(/\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm, '$1').
replace(/\r/,"\n").
replace(/\n[\n]+/,"\n");
}).then(function(clean) {
return JSON.parse(clean);
}).then(function(json) {
// Do what you want with the JSON object.
});
すでに多くの回答が指摘しているように、JSONには本来コメントがありません。もちろん、時々あなたはとにかくそれらが欲しいです。 Python の場合、これを行う2つの方法は commentjson （Python 2の場合のみ#および//）またはPython 2およびPython 3の場合は json_tricks （#または//） ）、他のいくつかの機能があります。免責事項：私はjson_tricksを作りました。
2019年のVSCodeユーザーのための実用的な答えは 'jsonc'拡張子を使うことです。
それは「コメント付きJSON」を示すためにVSCodeによって認識される拡張子であるため実用的です。以下のコメントで他のエディタ/ IDEについて教えてください。
VSCodeや他のエディタが 'json5'のネイティブサポートも追加するのはいいことですが、今のところVSCodeには 'jsonc'のサポートのみが含まれています。
（私はこれを投稿する前にすべての答えを調べましたが、 'jsonc'については何も言及しませんでした。）
はい、あなたはコメントをすることができます。しかし、私は上記の理由が何であれ推奨しません。
私はいくつかの調査をしました、そして、私はすべてのJSON requireメソッドがJSON.parseメソッドを使うのを見つけました。そこで私は解決策を見つけました。JSON.parseの周りでモンキーパッチを上書きまたは実行することができます。
注：Node.jsでのみテストされています;-)
var oldParse = JSON.parse;
JSON.parse = parse;
function parse(json){
json = json.replace(/\/\*.+\*\//, function(comment){
console.log("comment:", comment);
return "";
});
return oldParse(json)
}
JSONファイル：
{
"test": 1
/* Hello, babe */
}
覚えやすいようにコメントを必要とするかなりのJSONがあるので、私は現在のプロジェクトでこの問題に遭遇しました。
私はこの単純なpython関数を使ってコメントを置き換え、それをdictに変換するためにjson.loadsを使います。
import json, re
def parse_json(data_string):
result = []
for line in data_string.split("\n"):
line = line.strip()
if len(line) < 1 or line[0:2] == "//":
continue
if line[-1] not in "\,\"\'":
line = re.sub("\/\/.*?$", "", line)
result.append(line)
return json.loads("\n".join(result))
print(parse_json("""
{
// This is a comment
"name": "value" // so is this
// "name": "value"
// the above line gets removed
}
"""))
適切にコメントを書くには、 JSON-LD と schema.orgのcomment タイプを使用できます。
{
"https://schema.org/comment": "this is a comment"
}
* .jsonファイルは一般的に設定ファイルまたは静的データとして使用されるため、コメントが必要です→NetBeansなどの一部のエディタでは* .json内のjcommentを受け入れます。
問題は、コンテンツをオブジェクトに解析することです。解決策は、常にクリーニング機能（サーバーまたはクライアント）を適用することです。
PHP
$rgx_arr = ["/\/\/[^\n]*/sim", "/\/\*.*?\*\//sim", "/[\n\r\t]/sim"];
$valid_json_str = \preg_replace($rgx_arr, '', file_get_contents(path . '*.json'));
JavaScript
valid_json_str = json_str.replace(/\/\/[^\n]*/gim.'').replace(/\/\*.*?\*\//gim,'')
コメントをサポートする、JSON互換の他のライブラリーがあります。
1つの注目に値する例は "Hashcorp Language"（HCL） " です。これはVagrant、packer、consul、vaultを作ったのと同じ人々によって書かれました。
このスレッド全体では、コメントの追加がJSONに対して行われる必要がある唯一の改善点であると想定しています。 JSONでシリアル化に使用されるためにコメントが不要な人がいる場合は、コメントを省略してください。空白も同じです。しかし、なぜそこでやめましょうか。なぜJSONでは引用符は 必須 なのですか？彼らは何も役に立つものを追加しません。
JSONがそれほど厳格であると考えることができる唯一の理由は、構文解析が難しい場合です。しかしそうではありません。どちらの方向でも、ほぼすべてのプログラマーがJSONパーサーを作成できます。
私はJSONが読みやすく効率的（簡潔）で、データ転送、設定ファイル、その他たくさんのことに役立つことを望みます。次の例では、これら両方の要件が満たされています。
{stringA: stringB, stringC: stringD, [stringE, stringF]}
既存のJSON仕様よりも短いですが、読みやすく効率的です。
プロパティまたは値に引用符、アポストロフィ、コンマ、または角かっこを含める必要がありますか。 JavaScriptの場合と同様に、疑問符またはアポストロフィ（バックスラッシュエスケープ）でそれらを囲むだけです。
ただし、引用符はオプションにしてください。どうして？ JSONには（インジェクション攻撃を避けるために）変数名や関数名を含めることができないため、引用符で曖昧さを解消することはできません。すべてのデータが文字列であることはすでにわかっています。それで、本当に必要でない限り、引用符をすでに省いてください。