JSONはBOM無しのUTF-8で書かなければならない

2020年11月21日土曜日

システム開発

t f B! P L


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

https://www.rfc-editor.org/info/rfc8259

 

RFC 8259- JSON(JavaScript Object Notation)データ交換フォーマット

http://www.asahi-net.or.jp/~ax2s-kmtn/internet/rfc8259j.html

 

Final draft ECMA-404 2nd edition

https://www.ecma-international.org/publications/standards/Ecma-404.htm

 

ECMA-404 2nd edition PDF

https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

 

この仕様書は英語で、説明の内容も細か過ぎて分かりにくいので、JSON の仕様解説は以下のサイトをオススメする。

 

JSON入門 - とほほのWWW入門

http://www.tohoho-web.com/ex/json.html

 

仕様書の文字エンコーディングに関する引用と解説

 

先のリンク先「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規格については知っておいて欲しい。

知らないなら「分ったフリ」などしないで、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 の共存方法を検討した方が良いと思う。

 

最近、古い技術を「廃止」する動きが早くなっているように感じる。

 


shift-jis と utf-8 の混在問題に関する記事(リンクリスト)に戻る


このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ