Shift_JISの5C問題について

日本ではShift_JISでよく言われてい「た」であろう0x5C問題、いわゆる以下のようなコードのときに、「0x5C"」となどとなったときに、パーサーがバックスラッシュと勘違いし、エラーを起こすという問題についてです。

要約

• 0x5C問題は、Shift_JISだけではなく、文字の末尾が0x5Cならばどんな文字コードでも起こりうる
  • Shift_JISだから過去の話だと思っていると足元を掬われる
• 台湾、香港、マカオなどにある繁体字の文字コードBig5にもあります
  • Big5には、HKSCS という、香港の公的拡張もあり、現在でも5C問題はありえます
• 中国の文字コードであるGB 18030にもあります
  • GB18030では、話題として新しいGB 18030-2022も当然5C問題に気をつけなければなりません
• 韓国の文字コードであるKS X 1001 (Johab)にもあります
• 韓国の文字コードであるUHC (ks_c_5601-1987)にもあります
  • こちらはWindowsで標準になっているとありますが、現在でもそうなのかはわかりません

Big5とHKSCS

https://uic.jp/charset/show/big5-hkscs/ によれば、やはり末尾が5Cになっている文字があることがわかります。

GB 18030

https://uic.jp/charset/show/gb18030/ によれば、最近2022年版が公表されたことで一部で話題だった、GB 18030-2022についても同様に起こり得ます。

KS X 1001 (Johab)

http://www.asahi-net.or.jp/~ax2s-kmtn/ref/ksx1001.html によれば、やはり末尾が5Cになっている文字があることがわかります。ほんの一例として￦とかㅬが該当しそうです。

UHC (ks_c_5601-1987)

https://uic.jp/charset/show/ks_c_5601-1987/ によれば、やはり末尾が5Cになっている文字があることがわかります。

参考: https://q.hatena.ne.jp/1223286172

5C問題を起こす文字コードに共通していること

紹介した文字コードのいずれも、1バイト目にASCIIとの衝突を防ぐために、1バイト目が0x81〜になっていることが特徴で、2バイト目が0x40から0xFFの間になっている(Big5に関しては0x80から0x9Fは抜けていますが)ことも共通しているかと思います。1バイト目についてはいいものの、2バイト目が0x5Cのことを考慮していないため、そのことを考慮していないプログラミング言語のパーサーでパースエラーを引き起こすことに繋がります。

5C問題は過去の問題ではない

このように、5C問題というのは過去の問題ではなく、現在でもありうる問題です。したがって、プログラミング言語でパーサーを書く際に、強制的にUTF-8などUnicodeになっていない言語なのであれば、現在でも気をつけなければならないことに変わりはありません。

元々この問題はPHPのInternalsメーリングリストでの「Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?」で議論したことでもありますが、何もShift_JISだけではないということはこのエントリーでわかっていただけたでしょうか。

Thanks

ダメ文字（0x5C）は，Shift_JIS だけでなく，GB 18030（エンコーディング）、Big5、Johab（11172字 ハングル & KS X 1001） にも 影響します。
中国でも GB 18030（文字集合）を 扱う 際に UTF-8、UTF-16 で エンコードしてもよいことに なっています。https://t.co/W7OEkJJuOa

— ソケセテ（Sokesete，소케세테）ﾙ{ほんあか|本赫} (@madeinwariofan) December 20, 2023

ソセケテさんサンクス

2023/12/21 23:47