これまで、キホンのキを第１回。キホンのホを第２回。そして、最終回の第3回目は、キホンのンと言いたいところだが、書き忘れてたりしたものを、とめどなく綴る。

①字形と字体と書体

文字の形の話。今まで、文字オタクの領域だとすっ飛ばしたが、このあと異体字セレクタの説明をする以上、ここで軽く触れたい。簡単に言うと、以下の図の通りだ。

②サロゲートペアに並ぶ奇策中の奇策「異体字セレクタ」

自治体基幹システムで利用するフォントが「IPAmj明朝」となったときはベンダー各社衝撃が走ったはずだ。え？「MSゴシックをMS明朝に変えるだけだけやん！」というそこのあなた！まず「バカヤロー」と怒られなさない。次元が違うのである。
「IPAmj明朝」というフォントは、今までおそらくどのフォントも足を踏み入れなった、サロゲートペアと異体字セレクタのUnicode２大ラスボスを使った最強の敵なのである。パンドラの箱を開けてしまったと言う所以だ。
以下のUnicodeの各面を見ていただきたい。我々エンジニアは、令和のこの時代まで第0面のみで戦ってきた。当然、第0面に無い文字もあった。
そこは、第0面の空いているところが6400文字分あって、自由に使ってよいルールだ。各社、第0面に無い字のフォント(EUDC)を作って、その6400文字の空いているコードを割り当てて使っていた。いわゆる、「外字」である。
しかし、デジタル庁は「外字」の排除を宣言したのである。

「異体字セレクタ」の話に戻そう。全世界の文字をかき集めて文字コードを振るのがUnicodeだった。ただ、同じ字（とみなす物）に別なコードを振ることはしない。あなたの周りに斉藤さんはいないだろうか？あの人は、斉藤さん。あの人は、斎藤さん。そしてあの人は、齋藤さん。※あくまでもわかりやすく説明する目的であり「斉」が異体字対象かは別
Unicodeからすると、それ全部「斉」だからコードは１個しか振らんぞ！
その代わり、お前ら日本人（アジア人）がアイデンティティーって騒ぐから、同じ字でも字の形を変えたい気持ちは分かった。文字コードの後ろに形を分別するコードをあげるからそれで我慢しろ！これが異体字セレクタだ。（完全な妄想である）
具体的には、第14面の一部（U+E0100〜U+E01EF）の240個分を異体字セレクタ。ようは、1文字240パターンの形を分別できる。
異体字セレクタは文字コードであって文字コードではない。それだけでは、文字は表せないからだ。基底となる文字（Unicodeがいろいろ形はあれどこれが代表的な形だよねという文字）に続いて使う必要がある。
下図の赤い★マークは基底文字。（どの文字が基底文字か調べる方法はあるが割愛）

異体字セレクタはラスボス中のラスボスたる所以。それは、異体字セレクタ自体がサロゲートペア領域のコードなのである。よって、「葛」の字を分別するのに、今まで2byteでよかったのが6byteも必要となる。
コンピューター側も準備が必要だ。基底文字を読み込んで終了だったのが、異体字セレクタのコードが来たからその前にもってきた字の形ではなく、異体字として保存されている文字をフォントファイルから引っ張ってくる必要がある。そもそもサロゲートペア自体も計算が必要だ。大変な処理であることは、想像に難くないだろう。

UTF16で動くシステムの話前提だが、これまでは1文字2byte固定でしかなかった。2byteずつ切って文字を判断すればよかったし、それで世の中ほとんどのシステムがうまく回る。ところが、自治体基幹システムという世界から見ても日本から見ても、そんなニッチな使い方はまずしない。だから、道具が圧倒的に少ない（ないと言っても過言ではない）。特に帳票ツールの対応ができていない。サロゲートペアや異体字セレクタに対応していないシステムで、上の例にある「葛」を扱った場合、エラーで止まるか「葛□□」のような、3文字に分離され後半2文字は文字じゃないので文字化けすることだろう。文字のカウントをとった場合、期待値1文字のところ3文字とでる。Excelでも実験できるからやってみるとよい。

③UTF16が、1文字2byte固定から最大8byteの4種類の可変長に！

サロゲートペア、異体字セレクタの話に続きになってしまう。
②では、第0面(BPM)の文字に異体字セレクタがある場合を例題としたが、実際問題、第2面(SIP)の文字にも異体字セレクタが付く文字もある。
サロゲートペア+サロゲートペアで、なんと1文字8byteも消費する。

まとめると、UTF16のシステムは、これまで1文字2byte1種類だったのが、1文字2byte、4byte、6byte、8byteの4種類となる。データベースの文字数定義が大変だ。1文字8byteで計算すれば問題ないが、世の中そんな単純な話ではない。

④標準化の始まりは、Shift_JISの終焉

Shift_JISとかS_JIS（これ以降、S_JISとする）とか耳にしないだろうか？無意識含め、なんとなくS_JISで要求したり仕様書を書いたりしていないだろうか？標準化が始まるとS_JISは終焉することになる（個人の感想）。
国の文字要件を下にピックアップした。文字セットは「行政事務標準文字」又は「JIS X 0213:2012」の2択に絞られた。なお文字数は、「行政事務標準文字」＞「JIS X 0213:2012」なので、要件の最低限が「JIS X 0213:2012」となることは理解できるだろう。

話を「S_JIS」に戻そう。そもそも、S_JISは、「JIS X 0208」という文字セット文字コード専用の文字符号化方式だ。よって、S_JISを指定することは「JIS X 0208」を意味する。要件の最低限に満たないのだ。
これは今から調査と準備が必要だ。標準化対象外業務システムや外部システムがS_JIS前提の場合、標準準拠システムからは出力できないのだ。

⑤デジタル庁への突っ込み

どうしても文字要件で解せない記載がある。下図後半「標準準拠システム内の符号化方式については、UTF-8又はUTF-16とする。」
第一声は「ほっとけ！この！内部構造に口出すんじゃね！」だ。
ファイル連携はUTF-8だけで伝わる。
何が問題かといえば、書いた奴が本当に文字コード文字セットを理解しているか疑問に思うからである。余計な事は書くな。

⑥おわりに

自治体基幹システムの標準化において、文字要件が2転3転している。これはシステム屋からすると実に滑稽で、罵詈雑言浴びせられても仕方がないことと関係者には猛省を促す。システムの根幹をなすからだ。仕舞には、文字数多すぎて2フォントファイルにします。バカか。それに労力を割いて対応しようとするベンダーも同じ穴の狢なのである。文字が大切かどうかではない。基幹システムだけよければよいのか？全体を俯瞰で見たときに、何が大切か、何に労力をかけるべきかを見失ってはダメだ。たかが文字に右往左往（しかも莫大なコストをかける）する自治体基幹システムに魅力と価値はあるだろうか？