日本語の「昔の文字コード」は今も残っている
WHATWGの標準は、Webのブラウザが対応している文字コードを一覧にしています。
その中には、日本語用の昔の文字コードとして次の3つが含まれています [K4]。
- EUC-JP
- ISO-2022-JP（主にメールで使われてきた方式）
- Shift_JIS
WHATWGは、これらの「昔の（レガシーな）文字コード」について、過去に定義されたものの、ブラウザなどが同じやり方で実装してきたわけではないと説明しています。名前の付け方（ラベル）も、未定義の部分や独自の拡張部分の扱いもまちまちでした。
そのため、標準で動きを決めてそろえたのです [K4]。
「Shift_JIS」という名前には、複数の呼び名が含まれる
WHATWGの標準では、Shift_JISという1つの文字コードに、複数の名前（ラベル）が結び付けられています。
具体的には、「shift_jis」「shift-jis」「sjis」「ms_kanji」のほか、「windows-31j」「ms932」などもすべてShift_JISとして扱われます [K4]。
また、日本語の文字の対応表（JIS X 0208）は、IBMやNECがかつて独自に加えた拡張部分を含むものとして扱われる、と説明されています [K4]。
注記：標準としてのShift_JISと、WindowsのCP932（windows-31j）との細かい違いは、
今回の資料では確認できていません。
ブラウザの標準が両者を同じものとして扱っている、という点までが確認できた内容です。
使う製品によって扱いが異なる場合があります。
古い文字コードの危うさ：セキュリティの例
WHATWGの標準には、文字コードのズレによる攻撃の例が載っています。
2011年に報告された攻撃では、Shift_JISの「先頭バイト0x82」を使って、JSONの中の「0x22（ダブルクォート）」を隠しデータの意味を書き換えました。
データを作る側は問題に気づけませんでしたが、読む側は不正なバイトの並びを1つの文字に変えてしまい、結果として区切り文字の解釈が変わってしまったのです [K4]。
現在の標準ではこうしたズレを防ぐため、不正なバイトの並びがあっても、ASCIIの範囲の文字は隠せないようになっています [K4]。
WHATWGは、こうした問題はUTF-8だけを使うことでなくなるとしています。それこそが、UTF-8がすべてに必須の文字コードとされる理由のひとつです [K4]。
絵文字や特殊な文字が、消えることがある
昔の文字コードは、表せる文字の範囲が限られています。
WHATWGは、Webのフォームで表せない文字が入力されたとき、「💩」のような別の表記に置き換わり、本来の入力と区別できなくなる例を挙げています。
これは、データが静かに失われる原因になるため、UTF-8の利用が強くすすめられています [K4]。
注記：WHATWGが挙げている例は、Windows-1252という西欧向けの文字コードでの例です。
日本語のShift_JISでも、表せない文字（絵文字や特殊な漢字など）は、
同じように別の表記への置き換えや「？」への変化などが起きる可能性がありますが、
これは私の推測で、この資料に日本語の例があるわけではありません。
発注・運用の前に確認したいこと
- システムの内部と、画面、データベース、ファイルの文字コードはそれぞれ何か
- Shift_JISなど、古い文字コードを使う部分はどこか。なぜそれが必要か
- Shift_JISを使う場合、WindowsのCP932との違いを把握しているか
- 表せない文字が入力されたときにどう扱うか（エラー、置き換え、削除）
注記：この4点は、上の資料から私が整理した確認項目です。
資料がこの形のチェックリストを示しているわけではありません。
参照元
[K4] WHATWG, Encoding Standard — https://encoding.spec.whatwg.org/
コメント