8. String and Character Issues (文字列と文字の問題)

8.1. Character Encoding (文字エンコーディング)

JSONテキストは, UTF-8, UTF-16, またはUTF-32でエンコードされなければなりません (SHALL)。デフォルトのエンコーディングはUTF-8であり, UTF-8でエンコードされたJSONテキストは相互運用可能です。最も多くの実装によって正常に読み取られるためです。他のエンコーディング (UTF-16やUTF-32など) のテキストを正常に読み取れない実装が多数あります。

実装は, JSONテキストの先頭にバイトオーダーマーク (BOM) を追加してはなりません (MUST NOT)。相互運用性のため, JSONテキストを解析する実装は, バイトオーダーマークの存在をエラーとして扱うのではなく無視してもかまいません (MAY)。

8.2. Unicode Characters (Unicode文字)

JSONテキストで表現されるすべての文字列が完全にUnicode文字 [UNICODE] で構成されている場合 (どのようにエスケープされているかに関係なく), そのJSONテキストは相互運用可能です。それを解析するすべてのソフトウェア実装が, オブジェクトと配列内の名前と文字列値の内容について一致するためです。

ただし, この仕様のABNFでは, メンバー名と文字列値にUnicode文字をエンコードできないビットシーケンスを含めることができます。たとえば, "\uDEAD" (単一の対になっていないUTF-16サロゲート)。この状況のインスタンスが観察されています。たとえば, ライブラリがUTF-16文字列を切り捨てるときに, 切り捨てがサロゲートペアを分割するかどうかをチェックしない場合などです。このような値を含むJSONテキストを受信するソフトウェアの動作は予測不可能です。たとえば, 実装は文字列値の長さに対して異なる値を返したり, 致命的なランタイム例外を起こしたりする可能性があります。

8.3. String Comparison (文字列比較)

ソフトウェア実装は, オブジェクトメンバー名の等価性をテストする必要があることがよくあります。テキスト表現をUnicodeコードユニットのシーケンスに変換し, コードユニットごとに数値比較を実行する実装は相互運用可能です。すべてのケースで2つの文字列の等価または非等価について実装が一致するためです。たとえば, エスケープされた文字列を無条件に比較する実装は, "a\\b" と "a\u005Cb" が等しくないと誤って発見する可能性があります。