24197
20067 
JSONファイル内でコメントを使用できますか？もしそうなら、どのように？
2020-12-07 21:47:37 
1
2
次
番号。
JSONはデータのみであり、コメントを含めるとデータにもなります。
JSONデータを使用するアプリでは無視される「_comment」（または何か）と呼ばれる指定されたデータ要素を持つことができます。
JSONを生成/受信するプロセスには、JSONデータが何であるか、または少なくともその構造を事前に知っているはずなので、コメントを付ける方がよいでしょう。
しかし、あなたがすることにした場合：
{{
"_comment"： "コメントテキストはここにあります..."、
「用語集」：{
「タイトル」：「用語集の例」、
"GlossDiv"：{
「タイトル」：「S」、
"GlossList"：{
"GlossEntry"：{
「ID」：「SGML」、
"SortAs"： "SGML"、
"GlossTerm"： "標準の一般化マークアップ言語"、
「頭字語」：「SGML」、
「略語」：「ISO8879：1986」、
"GlossDef"：{
"para"： "DocBookなどのマークアップ言語を作成するために使用されるメタマークアップ言語。"、
"GlossSeeAlso"：["GML"、 "XML"]
}、
"GlossSee"： "マークアップ"
}
}
}
}
}
|
いいえ、//…または/ *…* /の形式のコメントはJSONでは許可されていません。この回答は以下に基づいています。
https://www.json.org
RFC 4627：
JavaScript Object Notation（JSON）のアプリケーション/ 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 +に関するダグラスクロックフォードの公式声明
|
JSONはコメントをサポートしていません。また、コメントが必要な構成ファイルに使用することも意図されていませんでした。
Hjsonは、人間向けの構成ファイル形式です。リラックスした構文、より少ない間違い、より多くのコメント。
JavaScript、Java、Python、PHP、Rust、Go、Ruby、C ++、およびC＃ライブラリについては、hjson.github.ioを参照してください。
|
免責事項：あなたの保証は無効です
指摘されているように、このハックは仕様の実装を利用しています。すべてのJSONパーサーがこの種のJSONを理解するわけではありません。特にストリーミングパーサーはチョークします。
それは興味深い好奇心ですが、実際には何にも使用すべきではありません。以下は元の答えです。
解析に影響を与えないコメントをJSONファイルに配置したり、表示されているデータを変更したりできる小さなハックを見つけました。
オブジェクトリテラルを宣言するときは、同じキーで2つの値を指定でき、最後の値が優先されるようです。信じられないかもしれませんが、JSONパーサーは同じように機能することがわかりました。したがって、これを使用して、解析されたオブジェクト表現には存在しないコメントをソースJSONに作成できます。
（{a：1、a：2}）;
// =>オブジェクト{a：2}
Object.keys（JSON.parse（ '{"a"：1、 "a"：2}'））。length;
// => 1
この手法を適用すると、コメント化されたJSONファイルは次のようになります。
{{
"api_host"： "APIサーバーのホスト名。ポートを指定することもできます。"、
"api_host"： "hodorhodor.com"、
"retry_interval"： "失敗したAPI呼び出しを再試行する間隔（秒単位）"、
"retry_interval"：10、
"auth_token"： "認証トークン。開発者ダッシュボードの[設定]から利用できます"、
"auth_token"： "5ad0eb93697215bc0d48a7b69aa6fb8b"、
"favorite_numbers"： "これまでのお気に入りの番号を含む配列"、
"favorite_numbers"：[19、13、53]
}
上記のコードは有効なJSONです。解析すると、次のようなオブジェクトが得られます。
{{
"api_host"： "hodorhodor.com"、
"retry_interval"：10、
"auth_token"： "5ad0eb93697215bc0d48a7b69aa6fb8b"、
"favorite_numbers"：[19,13,53]
}
つまり、コメントの痕跡はなく、奇妙な副作用はありません。
ハッピーハッキング！
|
YAMLの使用を検討してください。これはほぼJSONのスーパーセットであり（事実上すべての有効なJSONは有効なYAMLです）、コメントを許可します。
|
できません。少なくとも、json.orgを一目見ただけで私の経験になります。
JSONには構文がありますそのページで視覚化。コメントについてのメモはありません。
|
コメントは公式の標準ではありませんが、一部のパーサーはC ++スタイルのコメントをサポートしています。私が使用しているのはJsonCppです。例では、これがあります：
//構成オプション
{{
//テキストのデフォルトのエンコーディング
"エンコーディング"： "UTF-8"、
//起動時にロードされたプラグイン
「プラグイン」：[
「python」、
「c ++」、
「ルビー」
]、
//タブのインデントサイズ
"インデント"：{"長さ"：3、 "use_space"：true}
}
jsonlintはこれを検証しません。したがって、コメントはパーサー固有の拡張であり、標準ではありません。
もう1つのパーサーはJSON5です。
JSONTOMLの代替。
さらなる代替手段はjsoncです。
nlohmann / jsonの最新バージョンには、解析に関するコメントを無視するためのオプションのサポートがあります。
|
代わりにJSONスキーマを作成する必要があります。 JSONスキーマは現在、提案されているインターネットドラフト仕様です。ドキュメントに加えて、スキーマはJSONデータの検証にも使用できます。
例：
{{
「説明」：「人」、
"タイプ"： "オブジェクト"、
"プロパティ"：
{{
"名前"：
{{
"タイプ"： "文字列"
}、
"年齢"：
{{
"type"： "integer"、
「最大」：125
}
}
}
description schema属性を使用して、ドキュメントを提供できます。
|
JSONパーサーとしてJacksonを使用している場合は、次のようにしてコメントを許可します。
ObjectMapper mapper = new ObjectMapper（）。configure（Feature.ALLOW_COMMENTS、true）;
次に、次のようなコメントを付けることができます。
{{
key： "value" //コメント
}
また、次のように設定することで、＃で始まるコメントを付けることもできます。
mapper.configure（Feature.ALLOW_YAML_COMMENTS、true）;
しかし、一般的に（前に答えたように）仕様はコメントを許可していません。
|
これは、JSONにコメントを入れることができるGoogleFirebaseのドキュメントで私が見つけたものです。
{{
"//"： "一部のブラウザはこれを使用してプッシュ通知を有効にします。"、
"//"： "これはすべてのプロジェクトで同じです。これはプロジェクトの送信者IDではありません"、
"gcm_sender_id"： "1234567890"
}
|
番号。 JSONはコメントをサポートするために使用されていましたが、コメントは悪用され、標準から削除されました。
JSONの作成者から：
人々が解析ディレクティブを保持するためにコメントを使用しているのを見たので、JSONからコメントを削除しました。コメントがないために悲しむ人もいることは知っていますが、そうすべきではありません。 -ダグラス・クロックフォード、2012年
公式のJSONサイトはJSON.orgにあります。 JSONは、ECMAInternationalによって標準として定義されています。基準を改訂するための請願プロセスは常にあります。いくつかの理由から、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：1行コメントは、NewtonsoftJsonの6バージョン以上でのみサポートされます。
箱から出して考えることができない人への追加の注意：私が作成したASP.NETWebアプリケーションの基本設定にはJSON形式を使用しています。ファイルを読み取り、Newtonsoftライブラリを使用して設定オブジェクトに変換し、必要に応じて使用します。
私はJSONファイル自体に個々の設定についてコメントを書くことを好みます。使用するライブラリに問題がない限り、JSON形式の整合性については本当に気にしません。
これは、個別の「settings.README」ファイルを作成してその中の設定を説明するよりも「使いやすい/理解しやすい」方法だと思います。
この種の使用法に問題がある場合;申し訳ありませんが、魔神はランプから出ています。人々は他の使用法を見つけるでしょうJSON形式であり、それについてできることは何もありません。
|
JSONの背後にある考え方は、アプリケーション間の単純なデータ交換を提供することです。これらは通常Webベースであり、言語はJavaScriptです。
コメント自体は実際には許可されませんが、データ内の名前と値のペアの1つとしてコメントを渡すことは確かに機能しますが、そのデータは明らかに無視するか、解析コードによって特別に処理する必要があります。
とはいえ、JSONファイルに従来の意味でのコメントを含めることは意図されていません。それはただのデータでなければなりません。
詳細については、JSONWebサイトを参照してください。
|
JSONはコメントをネイティブにサポートしていませんが、独自のデコーダーまたは少なくともプリプロセッサーを作成してコメントを削除できます。これはまったく問題ありません（コメントを無視し、アプリケーションがJSONデータを処理する方法をガイドするためにコメントを使用しない限り）。
JSONにはコメントがありません。 JSONエンコーダーはコメントを出力してはなりません（MUSTNOT）。
JSONデコーダーはコメントを受け入れて無視してもよい[MAY]。
コメントは、意味のあるものを送信するために使用しないでください。あれは
JSONの目的。
Cf：JSON仕様の作成者であるDouglasCrockford。
|
設定ファイルでこれに遭遇しました。 XML（冗長、グラフィカル、醜い、読みにくい）、「ini」形式（階層なし、実際の標準など）、またはJavaの「プロパティ」形式（.iniなど）を使用したくありません。
JSONはできることをすべて実行できますが、冗長性が低く、人間が読める形式になっています。パーサーは多くの言語で簡単でどこにでもあります。それは単なるデータのツリーです。ただし、「デフォルト」構成などを文書化するには、帯域外コメントが必要になることがよくあります。構成は「完全なドキュメント」であってはなりませんが、必要なときに人間が読める形式の保存データのツリーです。
「有効な」JSONには「＃」：「comment」を使用できると思います。
|
JSONライブラリによって異なります。 Json.NETは、JavaScriptスタイルのコメント/ *コメント* /をサポートしています。
別のStackOverflowの質問をご覧ください。
|
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の拡張案であり、人間が手作業で記述および保守しやすくすることを目的としています。これは、ECMAScript5から直接いくつかの最小限の構文機能を追加することによって行われます。
|
Dojo Toolkit JavaScriptツールキット（少なくともバージョン1.4以降）では、JSONにコメントを含めることができます。コメントは/ * * /形式にすることができます。 Dojo Toolkitは、dojo.xhrGet（）呼び出しを介してJSONを使用します。
他のJavaScriptツールキットも同様に機能する可能性があります。
これは、最終的なオプションを選択する前に、代替のデータ構造（またはデータリスト）を試すときに役立ちます。
|
JSONはフレーム化されたプロトコルではありません。言語のない形式です。そのため、コメントの形式はJSON用に定義されていません。
多くの人が示唆しているように、いくつかのトリックがあります。たとえば、重複するキーや、使用できる特定のキー_コメントなどです。それはあなた次第です。
|
JSONPでコメントを付けることはできますが、純粋なJSONではできません。 Highchartsのこの例でプログラムを機能させるために1時間費やしました：http：//www.highcharts.com/samples/data/jsonp.php？filename = aapl-c.json＆callback =？
リンクをたどると、
？（/ * AAPLGoogle FinanceAPIからの過去のOHLCデータ* /
[
/ * 2006年5月* /
[1147651200000,67.79]、
[1147737600000,64.98]、
..。
[1368057600000,456.77]、
[1368144000000,452.97]
]）;
ローカルフォルダーに同様のファイルがあったので、同一生成元ポリシーに問題はなかったので、純粋なJSONを使用することにしました...そしてもちろん、$。getJSONはコメントのために黙って失敗していました。
最終的に、手動のHTTPリクエストを上記のアドレスに送信したところ、JSONPが純粋なJavaScriptを返すため、コンテンツタイプがtext / javascriptであることがわかりました。この場合、コメントは許可されます。しかし、私のアプリケーションはcontent-type application / 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 = 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
（ASCIIのハローベース3）ただし、スペースを0使用する代わりに、改行を1回使用し、キャリッジリターンを2回使用します。
これにより、多くの読み取り不可能な空白が残ります（IDEプラグインを作成してその場でエンコード/デコードしない限り）。
明らかな理由で、私はこれを試したことさえありませんし、あなたもそうすべきではありません。
|
JSON自体はコメントを許可しません。 JSON自体を使用してコメントを作成できるため、推論はまったく愚かです。これにより、推論が完全に不要になり、まったく同じ結果と潜在的な問題（JSONなど）に対してまったく理由もなくパーサーデータスペースが読み込まれます。コメント付きのファイル。
コメントを入れようとすると（たとえば、//または/ * * /または＃を使用）、厳密にはそうではないため、一部のパーサーは失敗します。
JSON仕様内。だからあなたは決してそれをするべきではありません。
ここで、たとえば、私の画像操作システムが画像表記とそれに関連するいくつかの基本的なフォーマットされた（コメント）情報を保存した場合（下部）：
{{
「表記法」：[
{{
「anchorX」：333、
「アンカー」：265、
"areaMode"： "Ellipse"、
"extentX"：356、
「extentY」：294、
「不透明度」：0.5、
"テキスト"： "上部の楕円形の領域"、
"textX"：333、
"textY"：265、
「タイトル」：「表記1」
}、
{{
「anchorX」：87、
「アンカー」：385、
"areaMode"： "Rectangle"、
"extentX"：109、
「extentY」：412、
「不透明度」：0.5、
"text"： "Rect area \ non bottom"、
「textX」：98、
"textY"：385、
"タイトル"： "表記2"
}、
{{
「anchorX」：69、
「アンカー」：104、
"areaMode"： "ポリゴン"、
"extentX"：102、
「extentY」：136、
「不透明度」：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
}
]、
"テキスト"： "単純ポリゴン"、
「textX」：85、
"textY"：104、
「タイトル」：「表記3」
}
]、
「imageXW」：512、
「imageYW」：512、
"imageName"： "lena_std.ato"、
"tinyDocs"：{
"c01"： "JSON画像表記データ："、
"c02"： "-------------------------"、
"c03"： ""、
"c04"： "このデータには画像表記と関連領域が含まれています"、
"c05"： "のための手段を提供する選択情報"、
"c06"： "楕円形の表記を表示する画像ギャラリー"、
"c07"： "長方形、多角形、またはフリーハンドの領域表示"、
"c08"： "ギャラリーの訪問者に表示される画像の上。"、
"c09"： ""、
"c10"： "XとYの位置はすべて画像内にありますスペース。画像"、
"c11"： "解像度はimageXWおよびimageYWとして与えられます。"、
"c12"： "表記領域を適切にスケーリングするために使用します"、
"c13"： "画像を表示する場所とサイズ"、
「c14」：「規模に関係なく」、
"c15"： ""、
"c16"： "楕円の場合、アンカーは楕円の中心です"、
"c17"： "および範囲はそれぞれX半径とY半径です。"、
"c18"： ""、
"c19"： "長方形の場合、アンカーは左上にあり、"、
"c20"： "範囲は右下です。"、
"c21"： ""、
"c22"： "フリーハンドおよびポリゴンエリアモードの場合、pointList"、
"c23"： "一連の番号付きXYポイントが含まれています。領域の場合"、
"c24"： "は閉じています、最後のポイントは"、
"c25"： "最初に、あなたが気にする必要があるのは絵を描くことだけです"、
"c26"： "リスト内のポイント間の線。アンカーと範囲"、
"c27"： "示されたものの左上と右下に設定されます"、
"c28"： "領域、および単純な長方形として使用できます"、
"c29"： "これらのタイプの上にマウスを置いた位置を検出します"、
"c30"： "エリアの"、
"c31"： ""、
"c32"： "textxとtextyの位置は、基本的な配置を提供します"、
"c33"： "テキスト情報を見つけるのに役立つ情報"、
"c34"： "その地域に関連する合理的な場所で"、
「c35」：「表示」、
"c36"： ""、
"c37"： "不透明度は0から1までの値で、.5は"、
"c38"： "背景が50％不透明で、1.0は完全に不透明であることを表します"、
"c39"： "背景。推奨事項は、領域を描画することです"、
"c40"： "ユーザーが画像の上にポインタを置いた場合のみ"、
"c41"： "そして、地域に関連付けられたテキストが描画されること"、
"c42"： "ユーザーが指示されたものの上にポインターを置いた場合のみ"、
「c43」：「地域」
}
}
|
プロジェクトにはstrip-json-commentsを使用しています。次のようなものをサポートします。
/ *
*説明
* /
{{
//虹
「ユニコーン」：/ *❤* /「ケーキ」
}
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））;
// => {ユニコーン： 'ケーキ'}
|
私の場合、JSON構造の出力の直前にデバッグ目的でコメントを使用する必要があります。そこで、クライアントを壊さないように、HTTPヘッダーでデバッグ情報を使用することにしました。
header（ "My-Json-Comment：はい、回避策だと思います;-)"）;
|
JSONアイテムをパーツに分割するために、「ダミーコメント」行を追加します。
{{
"＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃" ： "パート1"、
"data1"： "value1"、
"data2"： "value2"、
"＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃" ： "パート2"、
"data4"： "value3"、
"data3"： "value4"
}
|
1
2
次
非常に活発な質問。この質問に答えるために10の評判を獲得してください。レピュテーション要件は、この質問をスパムや無回答のアクティビティから保護するのに役立ちます。
あなたが探している答えではありませんか？ jsonコメントのタグが付けられた他の質問を参照するか、独自の質問をしてください。