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

StackOverflow https://stackoverflow.com/questions/244777

  •  05-07-2019
  •  | 
  •  

質問

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

役に立ちましたか？

解決

いいえ。

JSONはすべてデータである必要があります。コメントを含めると、データもデータになります。

JSONデータを使用するアプリで無視される＆quot; _comment＆quot; （または何か）と呼ばれる指定されたデータ要素を持つことができます。

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

他のヒント

いいえ、 //＆＃8230; または / *＆＃8230; * / の形式のコメントはJSONでは許可されません。この回答は以下に基づいています：

  • http://www.json.org
  • RFC 4627 ： application / json JavaScript Object Notation（JSON）のメディアタイプ
  • RFC 7159 JavaScript Object Notation（JSON）データ交換フォーマット-廃止：4627 、7158

選択した場合はコメントを含めます。解析または送信する前に、ミニファイヤでそれらを取り除きます。

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

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

それをリリースしたとき、私はそれの考えにさえ反対する人々の大きな反発を受けたので、なぜコメントはJSONで意味があります。 JSONの作成者からのこの注目すべきコメントが含まれています。

  

JSONを使用して設定ファイルを保持し、注釈を付けたいとします。先に進み、好きなコメントをすべて挿入してください。次に、JSMパーサーに渡す前にJSMinにパイプします。 - Douglas Crockford、2012

それが JSON.minify（）が有用である理由に同意しない人に役立つことを願っています。

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

  

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

     

JSONを使用して設定ファイルを保持し、注釈を付けたいとします。先に進み、好きなコメントをすべて挿入してください。次に、JSMパーサーに渡す前に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は人間用の構成ファイル形式です。リラックスした構文、ミスの減少、コメントの増加。

Hjson intro

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

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

できません。少なくとも json.org を一目見ただけでは、これが私の経験です。

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

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

例：

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

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

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 。

さらに別の方法は、 jsonc です。

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

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

回答：ライナーは1つです。これを行うと、JSONファイルを構成ファイルとして使用できます。

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

  

//＆quot; name＆quot ;:＆quot; string＆quot;

     

//＆quot; id＆quot ;: 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＆quot; Properties＆quot;形式（.iniなど）。

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

＆quot;＃＆quot ;:＆quot; comment＆quot; を使用して、＆quot; valid＆quot; JSON。

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

  

JSONにはコメントがありません。 JSONエンコーダーはコメントを出力してはなりません。   JSONデコーダーはコメントを受け入れ、無視する場合があります。

     

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

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

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

別のStack＆nbsp; Overflowの質問を参照してください。

JSONは、構成ファイルやその他のローカルでの使用にとって非常に理にかなっています。それは、ユビキタスであり、XMLよりもはるかに単純だからです。

データの通信時にJSONでコメントを使用することに対して強い理由がある場合（有効かどうかに関係なく）、JSONは2つに分割される可能性があります：

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

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

この問題に関してダグラス・クロックフォードが行った備考に関して（@Artur Czajkaが参照）

  

JSONを使用して設定ファイルを保持し、注釈を付けたいとします。先に進み、好きなコメントをすべて挿入してください。次に、JSMパーサーに渡す前にJSMinにパイプします。

一般的な設定ファイルの問題（言語/プラットフォーム間）について話しているのですが、彼はJS固有のユーティリティで答えています！

JSON固有のミニファイはどの言語でも実装できますが、 しかし、これを標準化して、すべての言語とプラットフォームのパーサー間でユビキタスになるように、人々は機能の良いユースケースを持っているため、機能を欠いて時間を無駄にするのを止め、オンラインフォーラムで問題を調べ、悪いアイデアだと人々に伝えますまたは、テキストファイルからコメントを削除するのが簡単に実装できることを提案します。

他の問題は相互運用性です。ライブラリまたはAPI、またはそれに関連付けられたいくつかの構成ファイルまたはデータファイルを持つサブシステムの種類があるとします。そして、このサブシステムは さまざまな言語からアクセスできます。次に、人々に伝えることについて行きますか：ところで パーサーに渡す前に、JSONファイルからコメントを削除することを忘れないでください！

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

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

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

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

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

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 / javascript であることがわかりました。この場合、コメントは許可されます。しかし、私のアプリケーションはcontent-type application / json を返したため、コメントを削除する必要がありました。

JSONは以前はコメントをサポートしていましたが、乱用され、標準から削除されました。

JSONの作成者から：

  

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

公式のJSONサイトは JSON.org にあります。 JSONは、ECMA Internationalによって標準として定義されています。規格の改訂を求める請願プロセスが常にあります。いくつかの理由により、アノテーションがJSON標準に追加されることはほとんどありません。

JSON by designは、XMLの簡単にリバースエンジニアリングされた（人間が解析した）代替手段です。注釈が不要になるまでも単純化されています。マークアップ言語でもありません。目標は安定性と相互運用性です。

"has-a"を理解している人オブジェクト指向の関係は、あらゆるJSON構造を理解できます-それがポイントです。これは、ノードタグ（キー/値ペア）を持つ有向非循環グラフ（DAG）であり、ほぼ普遍的なデータ構造です。

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

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

アノテーションは、JSONの相互運用性を低下させます。本当に必要なのがマークアップ言語（XML）であり、永続化されたデータが簡単に解析されるかどうかは気にしない限り、追加するものは他にありません。

これは＆quot; can you＆quot; の質問です。そして、ここに＆quot; yes＆quot; の答えがあります。

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

そして、はい、 JSONに周りコメントを挿入できます。解析できます。

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

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

最初に、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;

私たちはプロジェクトに 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アイテムをパーツにカットするには、「ダミーコメント」を追加します。行：

{

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

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

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

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

}

有効なJSONである優れたソリューション（ハック）があります。 同じキーを2回（またはそれ以上）作成します。例：

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

JSONはこれを次のように理解します：

{
  "param" : "This is value place",
}

JSONの作成者は、JSONにコメントを含めることを望んでいますが、解析する前にコメントを削除します（リンクマイケルバーによって提供されます） JSONにコメントが必要な場合は、それらを標準化して、JSONパーサーに任せてください。私はそこの論理に同意しませんが、悲しいかな、それは標準です。他の人が提案したYAMLソリューションを使用するのは良いことですが、ライブラリの依存関係が必要です。

コメントを削除したいが、ライブラリの依存関係を持ちたくない場合は、C ++スタイルのコメントで機能するが、他のユーザーに適応できる2行のソリューションを次に示します。

var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

このソリューションは、JSONデータにコメントイニシエーターが含まれていないことが確実な場合にのみ使用できます。 （ '//')。

JSON解析、コメントの除去、および追加のライブラリを実現する別の方法は、JavaScriptインタープリターでJSONを評価することです。もちろん、このアプローチの注意点は、汚染されていないデータのみを評価することです（信頼されていないユーザー入力は評価しません）。 Node.jsでのこのアプローチの例は次のとおりです。別の注意点として、次の例ではデータを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」を確認してください;名前は実際のフィールドと競合しません。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top