shift-jis と utf-8 の混在問題に関する記事(リンクリスト)に戻る
昨日のXMLの文字エンコーディングについての解説の続きで、JSON の文字エンコーディングの解説をする。
しかし、JSON はとてもシンプルなデータフォーマットなので、タイトルだけで既に必要な事は説明できてしまっている。
この記事で言いたいことは、
「 JSON を記述する時の文字エンコーディングは、UTF-8 で成ければ為らず、先頭に BOM を付けては為らない」
という事だけだ。
この事を理解して貰えば、この先の記事を読む必要はない。
さすがにこれだけでは記事が寂しいので、もう少し解説する。
JSON は WEB-API の主流インターフェイス
JSONは JavaScript Object Notation の略で、主にWEB-APIによるデータ連携で使用される。
Webサービスのインターフェイスはほとんどが JSON になっている。
以前は主にXMLが使用されていたが、仕様がシンプルでデータサイズがコンパクトになり、且つ人間にも読みやすい JSON がシェアを奪うようになり、XMLはWEB-APIでは使用されなくなっていった。
最後のXMLとも言える .NET Framework の WCF も先日リリースされた .NET 5.0 で未対応になり、廃止される事が決まった。
まだ、XMLはストレージにデータを保存するフォーマットとしては使用されると思うが、Webサービスのインターフェイスや、システム間ネットワーク連携のデータフォーマットとしては使用されなくなる。
ITベンダーがサポートしなくなるからだ。
JSONの仕様書
JSONの仕様を策定している団体は二つある。
RFC と Ecma である。
JSONの規格は互いに微妙に異なるRFC規格とEcma規格がそれぞれ定められ、二つの規格を開発者や企業が状況に合わせて使い分けていた。
RFCは Request for Comments の略で、インターネットとほぼ同時に生まれ、インターネットに関する様々な規格やルールを定め世界で共有する為の「文書群」である。
厳密に言えばRFCは団体ではない。
Ecmaは Ecma International (エクマ・インターナショナル) という欧州の標準化団体であり、本部はジュネーヴにある。
Ecma は略称ではなく名前である。
RFC と Ecma の JSON 規格は 2017年12月に仕様の統一が行われ、それぞれから同一の内容の JSON 仕様書として規定され、仕様書が公開されている。
RFC 側の呼称は「RFC 8259」、Ecma 側の呼称は「ECMA-404 2nd edition」となる。
それぞれの仕様書は以下のリンク先で提供されている。
Information on RFC 8259 » RFC Editor
RFC 8259- JSON(JavaScript Object Notation)データ交換フォーマット
Final draft ECMA-404 2nd edition
ECMA-404 2nd edition PDF
https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
この仕様書は英語で、説明の内容も細か過ぎて分かりにくいので、JSON の仕様解説は以下のサイトをオススメする。
JSON入門 – とほほのWWW入門
仕様書の文字エンコーディングに関する引用と解説
先のリンク先「RFC 8259- JSON(JavaScript Object Notation)データ交換フォーマット」から「文字エンコーディング」の項目を引用します。
「8.1. 文字エンコーディング
閉じたエコシステムの一部ではないシステムの間で交換されるJSONテキストは、UTF-8[RFC3629]を用いてエンコードしなければなりません(MUST)。
以前のJSON仕様では、JSONテキストの送信時にUTF-8を用いる必要はありませんでした。しかし、JSONベースのソフトウェア実装の大半は、UTF-8エンコーディングが相互運用性を実現する唯一のエンコーディングであるという程度にまでUTF-8エンコーディングの使用を選択しています。
実装では、ネットワーク送信されるJSONテキストの先頭にバイト・オーダー・マーク(U+FEFF)を追加してはなりません(MUST NOT)。相互運用性のために、JSONテキストを解析する実装は、バイト・オーダー・マークの存在をエラーとして扱うのではなく、無視することができます(MAY)。」
最初に解説したように、JSON では 文字エンコーディングに UTF-8 を使用しなければならない。
最後の JSON 規格である「RFC 8259」より前の規格では、複数の文字エンコーディングの使用が許可されていたが、「RFC 8259」で UTF-8 だけに限定された。
また、 UTF-8 だけに限定しているのだから、BOMによって文字エンコーディングを識別する必要がないので、BOMを付けては為らないことになった。
また、古い JSON などで先頭にBOMが付加されていた場合は、エラーにしないで「無視」する事が推奨されている。
これは「義務」ではないが、事実上は義務に近いと思う。
JSON 連携では Shift-JIS は使用できない
XMLではエンコーディング宣言すれば Shift-JIS の使用は認められる。
しかし、最後の JSON 規格である「RFC 8259」からは、UTF-8 以外の文字エンコーディングは使用できなくなった。
広く普及していて、将来的にはシステム間連携は全て JSON に統一されると思われるが、その JSON では UTF-8 以外は使用できないのだから、現在 Shift-JIS で開発されている業務系システムの場合、他システム連携の作り方に制限が加えられる事になる。
正直なところ、このまま Shift-JIS だけで開発を続けるのは難しくなっていくだろう。
社内だけで Shift-JIS で作った偽物の JSON を使用する事はできるだろうが、そのシステムが他社と連携する事になったとき、相手のシステム担当に「JSONで連携します」と言っておきながら「Shift-JIS の偽物 JSON」を送ったら「詐欺」になる。
連携先の会社のシステム担当が、UTF-8の本物のJSONで連携部分を開発していたら、「Shift-JIS の偽物 JSON」と分かった時点で追加のシステム改修コストが発生する。
そのコストを支払う義務があるのは、「Shift-JIS の偽物 JSON」を使用している事を事前に説明しなかった自社である。
受託開発業界では発注者による、こういうくだらないミスは多い。
くだらないトラブルを避ける為にも、非ITエンジニアを含めて、こういう一般的なＩＴ規格については知っておいて欲しい。
知らないなら「分ったフリ」などしないで、IT担当者に質問して欲しい。
私は以前から「UTF-8 と Shift-JIS を共存させる形で、UTF-8 を導入するべきだ」と主張している。
企業の場合、レガシーシステムを多く抱えており、 Shift-JIS で記述されたデータ資産を捨てたり、UTF-8 に全変換したりできない。
だから、レガシー資産とUTF-8を前提にした最新技術製品を「共存」させる事が必要だ。
その為の注意点とノウハウは以前の記事に書いた。
.NET Framework においても、WCFのようなXML連携の機能は廃止される。
今後、海外と連携する予定が無くても、 Shift-JIS だけで業務システムを開発し続けていると、JSONのようにUTF-8を前提にした最新技術製品を、導入できなくなる。
これは他社との競争においても、他社とのシステムやデータ資産の共有においても「不利」になる事を意味する。
まだ、UTF-8 環境の導入を行っていない企業は、そろそろ UTF-8 と Shift-JIS の共存方法を検討した方が良いと思う。
最近、古い技術を「廃止」する動きが早くなっているように感じる。
