形式 - json 配列




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

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


ASP.NETでNewtonsoft.Jsonライブラリを使用して読み込み/非直列化を行う場合は、JSONコンテンツのコメントを使用できます。

// "name": "string"

// "id":int

または

/* これは

コメントの例* /

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

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

私は、JSONファイル自体の個々の設定についてのコメントを書いている方が好きです。私が使用するライブラリがOKであれば、JSON形式の完全性は気にしません。

私はこれは、別の 'settings.README'ファイルを作成し、その中の設定を説明するよりも、使いやすく分かりやすい方法だと思います。

この種の使用に問題がある場合は、 申し訳ありませんが、ジニーはランプの外です。 JSON形式の他の使い方を見つける人はいますが、あなたができることは何もありません。


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

ただし、実際にはコメントは許可されませんが、データの名前と値のペアの1つとしてコメントを渡すことは確実ですが、そのデータは解析コードによって無視または処理する必要があります。

JSONファイルには従来の意味でのコメントが含まれるべきではありません。 それはちょうどデータでなければなりません。

JSONのWebサイトで詳細をご覧ください。


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

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

コメントは意味のあるものを送信するために使用されるべきではありません。 それがJSONの目的です。

Cf: JSON仕様の著者、Douglas Crockford


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

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


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


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はフレーム化されたプロトコルではありません。それは言語のない形式です。したがって、JSONのコメントの形式は定義されていません。

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


あなたが選択した場合、コメントを含めます。 構文解析または送信する前に、小型化装置でそれらを取り除く。

JSONブロックからコメントと空白をJSON.minify() JSONを有効なJSONにするJSON.minify()をリリースしJSON.minify() 。 だから、あなたはそれを次のように使うかもしれません:

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

私がそれをリリースしたとき、私はそれにも反対する人々の大きな反発を受けました。そのため、JSONでコメントが理にかなっている理由に関する包括的なブログ記事を書くことにしました。 これには、JSONの作成者からの注目すべきコメントが含まれています。

JSONを使用して、構成ファイルを保持しているとします。このファイルは注釈を付けたいものです。 あなたが好きなコメントをすべて挿入してください。 JSONパーサーに渡す前に、JSMinでパイプ処理してください。 - plus.google.com/118095276221607585885/posts/RK8qyGVaGSr

うまくいけば、 JSON.minify()が有用である理由に同意しない人にとってはうれしいことです。


JSONは設定ファイルやその他のローカルでの使用には非常に意味があります。なぜなら、これはユビキタスなので、XMLよりもはるかに簡単なためです。

データの通信時に(有効かどうかに関わらず)JSONにコメントすることに対する強い理由がある人は、おそらくJSONを2つに分割することができます。

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

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

ダグラス・クロフォード(Douglas Crockford)がこの問題(@Artur Czajkaによって参照されている)に関するplus.google.com/118095276221607585885/posts/RK8qyGVaGSrに関して、

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

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

確かにJSON固有のミニレベル化はどの言語でも実装できますが、これを標準化することで、すべての言語とプラットフォームのパーサー間でユビキタスになります。そのため、ユースケースが適切で、オンラインフォーラム、人々に悪いアイデアを伝えたり、テキストファイルからコメントを取り除くのは簡単です。

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


JSONアイテムを部品にカットするには、「ダミー・コメント」行を追加します。

{

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

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

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

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

}

いいえ。

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

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


一口。 なぜフィールドを追加するだけではないのですか?

{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

あなたの "notex"名が実際のフィールドと矛盾しないようにしてください。


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

例:

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

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


申し訳ありませんが、JSONでコメントを使用することはできません... JSON.org構文図を参照してください。

Douglas Crockford氏は「 plus.google.com/118095276221607585885/posts/RK8qyGVaGSr 」と述べplus.google.com/118095276221607585885/posts/RK8qyGVaGSr

私はJSONからコメントを削除しました。なぜなら、人々は、JSONを使用して構文解析ディレクティブを保持していたため、相互運用性を破壊してしまったでしょう。 私は、コメントの欠如が一部の人々を悲しくさせることを知っていますが、そうではありません。

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


私は設定ファイルのためにこれに遭遇しました。 XML (冗長、グラフィカル、醜い、読みにくい)、または "ini"形式(階層なし、実際の標準など)、Javaの "Properties"形式(.iniなど)を使用したくありません。

JSONはできることはすべて行うことができますが、冗長で人が読めるように簡単です。パーサは、多くの言語で簡単かつ遍在しています。 それは単なるデータツリーです。 しかし、アウト・オブ・バンドのコメントは、「デフォルト」の設定などを文書化する必要があります。 構成は決して「完全な文書」ではなく、必要に応じて人間が読める保存されたデータのツリーです。

私は"#": "comment" 、 "有効な" JSONを使用することができると思います。


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

JSON5は、人間が簡単に手書きして管理することを目的としたJSONの拡張です。これは、ECMAScript 5から最小限の構文機能を直接追加することで行います。


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

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

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


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

いいえ、重複したオブジェクトメンバーを使用してサイドチャネルデータをJSONエンコーディングに使用しないでください。(RFCの "オブジェクト内の名前は一意であるべきである"を参照)。

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

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

* RFCは文字列、数字、 "false"、 "true"、 "null"を明示的に指定しないで、 "6つの構造文字の前後に空白が許されている" この省略はすべての実装では無視されます。

まず、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;

我々は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'}




comments