8. String and Character Issues (文字列と文字の問題)
8.1. Character Encoding (文字エンコーディング)
閉じたエコシステムの一部ではないシステム間で交換される JSON テキストは、UTF-8 [RFC3629] を使用してエンコードしなければなりません (MUST)。
JSON の以前の仕様では、JSON テキストを送信する際に UTF-8 の使用を要求していませんでした。しかし、JSON ベースのソフトウェア実装の大部分は UTF-8 エンコーディングの使用を選択しており、それが相互運用性を実現する唯一のエンコーディングとなっています。
実装は、ネットワーク経由で送信される JSON テキストの先頭にバイトオーダーマーク (Byte Order Mark, BOM, U+FEFF) を追加してはなりません (MUST NOT)。相互運用性のために、JSON テキストを解析する実装は、バイトオーダーマークの存在をエラーとして扱うのではなく、無視してもよい (MAY) です。
8.2. Unicode Characters (Unicode 文字)
制御文字の Unicode 文字値を参照する場合、本仕様では Unicode の慣例である "U+" の後に16進数の文字コードポイント値を付ける表記を使用します。例えば、"U+0022" は引用符文字を表します。
JSON テキストで表現されるすべての文字列が完全に Unicode 文字 [UNICODE]（どのようにエスケープされていても）で構成されている場合、その JSON テキストは相互運用可能です。つまり、それを解析するすべてのソフトウェア実装は、オブジェクトと配列の名前と文字列値の内容について合意します。
ただし、本仕様の ABNF では、メンバー名と文字列値に Unicode 文字をエンコードできないビットシーケンスを含めることができます。例えば、"\uDEAD"（単一の対になっていない UTF-16 サロゲート）。これは、例えばライブラリがサロゲートペアを分割したかどうかを確認せずに UTF-16 文字列を切り捨てた場合に観察されています。このような値を含む JSON テキストを受信するソフトウェアの動作は予測不可能です。例えば、実装は文字列値の長さに対して異なる値を返したり、致命的なランタイム例外を発生させたりする可能性があります。
8.3. String Comparison (文字列比較)
ソフトウェア実装は通常、オブジェクトメンバーの名前の等価性をテストする必要があります。テキスト表現を Unicode コードユニットのシーケンスに変換し、コードユニットごとに数値的に比較を実行する実装は、実装がすべてのケースで2つの文字列の等価性または非等価性について合意するという意味で相互運用可能です。例えば、エスケープされた文字を変換せずに文字列を比較する実装は、"a\\b" と "a\u005Cb" が等しくないと誤って判断する可能性があります。