文字コードって、とっても難しいです。
そんな文字コードの中で、文字コードの歴史を通じて、複雑な文字コードの理解が深まるように解説します。
１．すべては ASCⅡ からはじまった
文字コードの始まりは、ASCⅡ です。
それは 94 文字の単純な 1 バイトコードでした。しかしこれは、欧州の言語には対応していませんでしたし、漢字にはとても対応できる体系ではありませんでした。
最初は各国の 1 バイトコードの文字コードが乱立し、それらを併用したいというニーズと、漢字も収録したいというニーズがあり、2 バイトの文字コードが誕生します。
1 バイトでは最大 256 文字しか収録できませんが、2 バイトであれば 65,536 文字も収録できます。
そして 2 バイトの文字コードは、使用する文字集合を切り替える性質を ISO/IEC2022 として備えました。
それまでは「符号化文字集合＝文字符号化方式」でしたが、この ISO/IEC 2022 の誕生で、符号化文字集合と文字符号化方式が分離され、日本でいえば、EUC-JP や ISO-2022-JP 、Shift-JIS といった文字符号化方式が誕生します。
さらに日本語でいえば、JIS第3水準漢字、JIS第4水準漢字の利用のニーズが高まり、収録する文字数が 65,536 で足りなくなったため、この 2 バイト文字集合を 2 つ利用する文字符号化方式 JIS X 0213 が誕生しました。
このように ISO/IEC 2022は、上限なく収録する文字を増やしていくことができる規格ですが、文字集合を切り替えるための制御コードが必要となり、ソフトウェアもその制御コードに対応する必要があるため、世界中の文字を一つの文字集合に収録する動きがでてきました。それが Unicode です。
初期の Unicode は、初期の ASCⅡ のように「符号化文字集合＝文字符号化方式」でした。
この Unicode の失敗は 2 バイト固定の文字コードとしたことです。2 バイト固定なので、65,536 文字しか収録できません。当然のことながら、あっという間にコードが足りなくなりました。
そこで Unicode が 4 バイトに拡張されることになりましたが、いきなり 4 バイトと言われても、それまで 2 バイト 1 文字で処理していたソフトウェアは対応できません。
そのため従来の 2 バイト固定の Unicode を UTF-16 とし、4 バイト固定の文字コードを UTF-32 としました。それ以外にも ASCⅡ と互換性のある可変長文字コード UTF-8 も誕生し、Unicode は符号化文字集合、UTF が文字符号化方式という形で ASCⅡ と同じ道を辿ることになりました。まさに「歴史は繰り返す」です。
そして UTF-16 は、コード不足という課題に対して、2 バイト文字コード 2 つで 1 文字というルールを追加することで、収録する文字を増やすこととしました。これがサロゲートペアです。
さらに Unicode は、字体や字形の違いを枝番を付加することで表現できる IVS を導入し、ますます複雑さを増していくことになりました。
２．JIS2004 問題
文字コードの歴史は、Windows の歴史と大きく関わります。もっとも文字コードが大きく影響したのは、JIS2004 問題と呼ばれるものです。
最近はあまり聞かれなくなりましたが、2006 年の Vista 発売から 2015 年くらいまではJIS2004 問題が文字コードの最重要課題の一つでした。
XP までは、採用されている文字コードは Shift-JIS（正確には CP932 ）でしたが、 2006 年に発売された Vista からは Unicode が採用されました。
ここで何が問題かというと、XP までは入力できる文字の範囲も字体・字形も JIS90 でしたが、それが Vista からは JIS2004 になったことです。
まず JIS90（正確には CP932 ）に収録されている文字数は 6,879 文字なのに対して、 JIS2004 は 11,233 文字にもなります。単純に文字数が増えるだけでなく、サロゲートペアが含まれることが大問題でした。
まだ当時のソフトウェアでサロゲートペアの対応ができているものは少なく、PC がサロゲートペアを入力できてしまうようになると、ソフトウェアが誤動作を起こしてしまうことが懸念されました。
もう一つの問題は字体・字形の変更です。JIS2004 では 168 文字の字体・字形が「昔の」字体・字形に変わりました。これによりお客様の氏名等の字体・字形が突然変わってしまうことが問題となりました。
３．JIS2004 問題への対応
JIS2004 問題とは簡単にいうと「サロゲートペアが入力できてしまう問題」と「字体・字形が変わってしまう問題」の 2 つがあります。
そこでサロゲートペアの入力に対しては、ソフトウェア側で入力文字の制限を行い（ CP932 以外の文字の入力をエラーとする対応）、字体・字形の変更に対してはマイクロソフトが提供する「JIS90 互換フォント」と呼ばれるフォントを適用することで、引き続き JIS90 の字体・字形を継続する対応を取りました。
その「JIS90 互換フォント」が、Windows8 から提供されなくなり、代わりに IVS が標準で利用できるようになります。つまり今まで通りJIS90の字体・字形を利用したい場合には、「JIS90 互換フォント」を利用するのではなく、IVS を利用することになりました。
そこでまた新たに発生した問題が IVS です。サロゲートペアと同様に対応しているソフトウェアが少ないため、Windows7 からOSのバージョンを上げる際には、実質、字体・字形の変更を覚悟することになりました。
今はもう Windows8 どころか Windows10 が普及し、Windows11 の発表までされているので、JIS2004 問題は過去の問題となりつつありますが、それでも IVS はまだ対応しているソフトウェアは少ないのが現状です。
４．文字コードの歴史
このように文字コードの歴史は、扱える文字の拡張の歴史でもあります。
ASCⅡ という 94 文字の文字集合から始まって、JIS第1、第2水準漢字を扱える JIS X 0208 が誕生し、それを使用する文字符号化方式である Shift-JIS（CP932）や EUC-JP、ISO-2022-JP が広く使われるようになりました。
その後、JIS第3、第4水準漢字を扱える JIS X 0213 が誕生しましたが、Unicode が普及し始め、文字符号化方式は UTF-8 や UTF-16 が主流となりました。
せっかく誕生した JIS X 0213 はあまり使われることがないのですが、その過程で誕生した JIS2004 字形が波紋を呼び、IVS のようなものまで登場することになりました。
JIS X 0213 は、2004 年に改定をしてから文字の追加はありませんが、その間にも Unicode はどんどん収録する文字を拡張し続けています。
最近では「令和」の合字である「㋿」も Unicode に追加されました。
もう Unicode の王座の座は揺らがないのでしょうか。それともまた新しい文字コードが登場するのでしょうか。
Shift-JIS にはいろいろ問題はありますが、半角 1 バイト、全角 2 バイトと分かりやすいという利点があります。
それに対して UTF-8 は、漢字の大部分は 3 バイトとなり容量が大きくなる上に、1 文字が何バイトなのか分かりにくいという欠点があります。
Shift-JIS であれば画面の入力域の上限を「20 文字」と文字数で制限できていましたが、UTF-8 の場合「30 バイト」といったユーザーに分かりにくい上限になるケースが多いです。（UTF-8 でも文字数での上限にすることができますが、実装が大変なので社内システムの場合にはバイト数での上限にしているケースが多いです）
今後の文字コードの行方が楽しみです。
【振り返り】
第七回は、文字コードの歴史でした。第八回は、文字化けです。
第一回：概要
第二回：符号化文字集合
第三回：文字符号化方式（前編）
第四回：文字符号化方式（後編）
第五回：サロゲートペア
第六回：IVS
第七回：文字コードの歴史
第八回：文字化け
