JSON ファイル内でコメントを使用できますか? もしそうなら、どのように?
57 に答える
いいえ。
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.minify()をリリースしました。これは、JSON のブロックからコメントと空白を取り除き、解析可能な有効な JSON にします。したがって、次のように使用できます。
JSON.parse(JSON.minify(my_str));
私がそれをリリースしたとき、その考えにさえ反対する人々の大きな反発を受けたので、JSON でコメントが意味をなす理由について包括的なブログ投稿を書くことにしました。これには、JSON の作成者からの次の注目すべきコメントが含まれています。
JSON を使用して、注釈を付けたい構成ファイルを保持しているとします。好きなコメントをすべて挿入してください。次に、JSON パーサーに渡す前に JSMin にパイプします。-ダグラス・クロックフォード、2012
JSON.minify()が役立つ理由に同意しない人にとって、これが役立つことを願っています。
コメントは設計により JSON から削除されました。
JSON からコメントを削除したのは、人々が構文解析ディレクティブを保持するためにコメントを使用しているのを見たからです。コメントがないことで悲しむ人がいることは知っていますが、そうすべきではありません。
JSON を使用して、注釈を付けたい構成ファイルを保持しているとします。好きなコメントをすべて挿入してください。次に、JSON パーサーに渡す前に JSMin にパイプします。
JSON はコメントをサポートしていません。また、コメントが必要な構成ファイルに使用することも意図していませんでした。
Hjson は、人間用の構成ファイル形式です。構文が緩和され、間違いが減り、コメントが増えました。
JavaScript、Java、Python、PHP、Rust、Go、Ruby、C++、および C# ライブラリについては、 hjson.github.ioを参照してください。
免責事項: お客様の保証は無効です
指摘されているように、このハックは仕様の実装を利用しています。すべての 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.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です。
nlohmann/jsonの最新バージョンには、解析に関するコメントを無視するためのオプションのサポートがあります。
代わりにJSON スキーマを作成する必要があります。JSON スキーマは、現在提案されているインターネット ドラフト仕様です。ドキュメントのほかに、スキーマは JSON データの検証にも使用できます。
例:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
descriptionスキーマ属性を使用してドキュメントを提供できます。
いいえ。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 ファイルを構成ファイルとして使用できます。
JSON の背後にある考え方は、アプリケーション間で単純なデータ交換を提供することです。これらは通常 Web ベースで、言語は JavaScript です。
コメント自体は実際には許可されませんが、データ内の名前/値のペアの 1 つとしてコメントを渡すことは確かに機能しますが、そのデータは明らかに無視するか、解析コードによって特別に処理する必要があります。
とは言っても、JSON ファイルに従来の意味でのコメントを含める必要はありません。それはただのデータであるべきです。
詳細については、JSON の Web サイトを参照してください。
構成ファイルでこれに遭遇しました。XML (冗長、グラフィカル、醜い、読みにくい)、または "ini" 形式 (階層なし、実際の標準なしなど) または Java "プロパティ" 形式 (.ini など) は使用したくありません。
JSON はできることはすべて実行できますが、冗長性がはるかに低く、人間が読みやすいです。また、パーサーは簡単で、多くの言語で遍在しています。それは単なるデータのツリーです。ただし、「デフォルト」構成などを文書化するために、帯域外のコメントが必要になることがよくあります。構成は決して「完全なドキュメント」ではなく、必要なときに人間が判読できる保存データのツリーです。
"#": "comment"
「有効な」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固有のミニファイは任意の言語で実装できますが、これを標準化して、すべての言語とプラットフォームのパーサー間でユビキタスになるようにします。これにより、ユーザーは機能の優れたユースケースを持っているため、機能が不足している時間を無駄にすることがなくなり、問題を調べます。オンラインフォーラムで、それは悪い考えだと人々に言わせたり、テキストファイルからコメントを取り除くのは簡単だと提案したりします。
もう1つの問題は相互運用性です。ライブラリまたはAPI、あるいはいくつかの構成ファイルまたはデータファイルが関連付けられている任意の種類のサブシステムがあるとします。そして、このサブシステムは異なる言語からアクセスされます。次に、人々に伝えますか?ところで、パーサーに渡す前に、JSONファイルからコメントを取り除くことを忘れないでください!
JSON5を使用する場合は、コメントを含めることができます。
JSON5 は、JSON の提案された拡張機能であり、人間が手動で記述および保守しやすくすることを目的としています。これは、ECMAScript 5 から直接いくつかの最小限の構文機能を追加することによって行われます。
Dojo Toolkit JavaScript ツールキット (少なくともバージョン 1.4 以降) を使用すると、JSON にコメントを含めることができます。コメントは/* */
フォーマットにすることができます。Dojo Toolkit は、dojo.xhrGet()
呼び出しを介して JSON を使用します。
他の 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 policyに問題はなかったので、純粋な JSON を使用することにしました...もちろん、$.getJSON
コメントのためにサイレントに失敗していました。
text/javascript
最終的に、手動の HTTP リクエストを上記のアドレスに送信したところ、JSONP が純粋な JavaScript を返すため、content-type であることに気付きました。この場合、コメントは許可されます。しかし、私のアプリケーションは content-typeapplication/json
を返したため、コメントを削除する必要がありました。
これは「できますか」という質問です。そして、ここに「はい」の答えがあります。
いいえ、重複したオブジェクト メンバーを使用して、サイド チャネル データを JSON エンコーディングに詰め込むべきではありません。( RFC の「オブジェクト内の名前は一意である必要があります」を参照してください)。
はい、解析できるJSON の周りにコメントを挿入できます。
しかし、任意のサイドチャネル データを有効な JSON に挿入および抽出する方法が必要な場合は、ここに回答があります。JSON エンコーディングでのデータの一意でない表現を利用します。これは* RFC のセクション 2 で「6 つの構造文字の前後に空白を許可する」の下で許可されています。
* 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;
JSON アイテムをパーツに分割するには、「ダミー コメント」行を追加します。
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
JSON をテキスト ファイルとして読み込んでからコメントを削除すると、コメントを含む JSON を使用できます。
たとえば、decommentライブラリを使用できます。以下は完全な例です。
入力 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 }
JSON の作成者は、JSON にコメントを含めることを望んでいますが、解析する前にそれらを取り除きます ( Michael Burr が提供するリンクを参照してください)。JSON にコメントが必要な場合は、それらを標準化し、JSON パーサーに任せてみませんか? そこの論理には同意しませんが、悲しいかな、それが標準です。他の人が提案した YAML ソリューションを使用するのは良いことですが、ライブラリの依存関係が必要です。
コメントを削除したいが、ライブラリに依存したくない場合は、C++ スタイルのコメントで機能するが、他のコメントにも適用できる 2 行のソリューションを次に示します。
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
この解決策は、JSON データにコメント開始文字 ('//') が含まれていないことが確実な場合にのみ使用できることに注意してください。
JSON の解析、コメントの削除、余分なライブラリーの不要を実現するもう 1 つの方法は、JavaScript インタープリターで JSON を評価することです。もちろん、このアプローチの注意点は、汚染されていないデータのみを評価したいということです (信頼されていないユーザー入力はありません)。Node.js でのこのアプローチの例を次に示します。もう 1 つの注意点として、次の例ではデータが 1 回だけ読み取られ、その後キャッシュされます。
data = require(fs.realpathSync(doctree_fp));
はぁ。フィールドを追加しないのはなぜですか。
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
「notex」名が実際のフィールドと競合しないことを確認してください。
「 grunt-strip-json-comments 」を見つけました。
「JSON からコメントを取り除きます。JSON ファイルでコメントを使用できます!」</p>
{
// Rainbows
"unicorn": /* ❤ */ "cake"
}
有効な JSON である良い解決策 (ハック) がありますが、すべての場合に機能するとは限りません(以下のコメントを参照)。同じキーを 2 回 (またはそれ以上) 作成するだけです。例えば:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
したがって、JSON はこれを次のように理解します。
{
"param" : "This is value place",
}
2019 年のVisual Studio Codeユーザー向けの実用的な答えは、'jsonc' 拡張機能を使用することです。
これは、Visual Studio Code によって認識される拡張子であり、「コメント付きの JSON」を示すため、実用的です。以下のコメントで他のエディタ/IDEについて教えてください。
Visual Studio Code やその他のエディターが JSON5 のネイティブ サポートも追加してくれるとよいのですが、今のところ Visual Studio Code には '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 */
}
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-LDとschema.org コメントタイプを使用して、コメントを適切に書き込むことができます。
{
"https://schema.org/comment": "this is a comment"
}
コメントをサポートする JSON 互換のライブラリは他にもあります。
注目すべき例の 1 つは"Hashcorp Language" (HCL)"です。これは、Vagrant、packer、consul、vault を作成したのと同じ人々によって書かれています。
はい。JSON ファイルにコメントを入れることができます。
{
"": "Location to post to",
"postUrl": "https://example.com/upload/",
"": "Username for basic auth",
"username": "joebloggs",
"": "Password for basic auth (note this is in clear, be sure to use HTTPS!",
"password": "bloejoggs"
}
コメントは、コードまたは構成のブロックの目的を説明する単なるテキストです。また、JSON ではキーを複数回指定できるので、このようにできます。構文的には正しく、唯一のトレードオフは、辞書にガベージ値を持つ空のキーがあることです (これは削除できます...)
何年も前にこの質問を見ましたが、私が取り組んでいるプロジェクトでこのように行われたのを見たばかりで、これは本当にきれいな方法だと思いました。楽しみ!
JSON はコメントをサポートしていませんが、JSONCはコメントをサポートしています。
ファイルに拡張子「.jsonc」を付けて、jsoncパーサーを使用します。
この回答が遅すぎた場合は申し訳ありません。
jsonWithComments.jsonc
例:
{
// This is a comment!
"something": "idk"
}
これが不明な場合は、ボットがおかしいと思います。この質問を役に立たないと投票する前に、試してみてください。