問題タブ [rfc4627]

この投稿の議論に従って: json-conversion-in-javascript

PHPではjson_encode、オブジェクトをjson文字列としてエンコードするために使用できます。

ただし、PHPには、オブジェクトとは見なされない標準のデータ型（int、stringsなど）が多数あります。に文字列を渡すと、文字列json_encodeの定義に使用できるjavascriptステートメントを含む文字列が返されます。

あまり厄介な言い回しでは、これは

これを出力します（javascript対応の文字列）

この動作はJSON仕様の一部ですか？つまり、JSONは、実装がネイティブの非オブジェクトデータ型の変換を処理する方法を定義または推奨していますか？それとも、回心について意見がありますか？私がRFCを読んだことで、これはあいまいなままになりましたが、私はこれらのことを解釈するのが苦手です。

この動作が関数の将来のバージョンから消える可能性に興味があるので、私は尋ねます。つまり、仕様のどこかで成文化されている場合、開発中に誰かが追加しようと考えていたものよりも、消える可能性は低くなります。

RFC 4627 (http://www.ietf.org/rfc/rfc4627.txt) を読んでいます。パラ 2.1 では、true、false、null の 3 つのリテラル名について説明しています。

私はここで完全に迷っています。%x66.61.6c.73.65 の意味を知っている人はいますか? ありがとう。

RFC 4627 セクション 2.2 によると: 2.2。オブジェクト

オブジェクト構造は、0 個以上の名前と値のペア (またはメンバー) を囲む中かっこのペアとして表されます。名前は文字列です。各名前の後にコロンを 1 つ付けて、名前と値を区切ります。単一のコンマは、値とそれに続く名前を区切ります。 オブジェクト内の名前は一意である必要があります。

しかし、「ユニークであるべき」は業界のベストプラクティスに準拠しているのでしょうか? ほとんどの JSON エンコーダー/デコーダーは「一意である必要があります」を強制しますか? JSONlint.com は「一意でなければならない」ことを強制します。

たとえば、{ "foo":"value1", "foo":"value2" } は有効な JSON を返します { "foo":"value2" }

2 番目の同じ名前は、同じ名前の最初のエントリを置き換えます。

JSONデータを返すApiメソッドがあります。オンライン json バリデーターhttp://pro.jsonlint.com/を使用して json データを検証しようとすると、compare オプションを使用して、あるセクションに url を指定し、別のセクションに url の出力を指定すると、url セクションにエラーが発生し、データがコピーされて貼り付けられたセクションが検証されます。

ここで何が問題になる可能性がありますか?

更新: 2 つの出力をメモ帳にコピーしてファイルを比較しました。URL からの出力の先頭に印刷できない文字があります。

API レスポンスの content-type は「application/json; charset=utf-8」です。