No215 「はしご高」のややこしい歴史

前回、「はしご高」のような異体字というものについて解説をしま
した。

今回は異体字を現在のコンピュータ上で表示する方法について解説
します。

1. 異体字の表示はずっと以前からの課題

前回も書きましたが、昔から人名で使う文字は課題の山でした。

それこそ1970年代まではコンピュータで漢字を扱うことができま
せんでしたから、まず漢字を出せるようにすること自体が大きな
チャレンジだったのです。

70年代後半にようやく漢字が出せるようになると、スグに問題に
なったのが異体字の問題でした。

特に役所の戸籍係では、文字を正確に把握することが重要ですから
文字を正しく表記することに神経を使っていました。

一方、前回も解説したように文字コードの標準化を考慮すると筆記
上の誤差や略字に別のコードを割り当てるのはデータの整合性を
考えるとあまりやりたくない方法です。

こういった矛盾した状況下で、異体字に適応するためにいろんな
方法が採られたのです。

2. 外字というもの

役所の戸籍係では早期からコンピュータ化による検索の高速化が
強く期待されてきました。
それまでは氏名検索をするには、紙の書類をくるしかなく非常に
効率が悪かったのです。

それでも手書きの時代は申請者が書いた申請書自体が原本ですから
「はね」や「とめ」が多少違っていても、戸籍係が探せるものなら
問題にはなりませんでした。
「はしご高」のような異体字はもちろん、場合によって誤字でも
申請が通る場合さえありました。
（実際、筆者の知っている年配の方でどんな辞典にも載っていない
漢字を使う方がおられます）

ですが、これをコンピュータ化しようとすると大変です。
なにせコンピュータでいくら探しても出てこない文字がたくさん
あるわけです。
申請する側は自分の氏名ですから申請を受け付けられないことに
文句を付ける人も多かったのです。
役所側は「コンピュータの文字に不満のある方は手書き申請も可と
する」としたものの、検索を考えると少しでもコンピュータ化を
推進したいため、やむを得ず外字というものを利用しました。

外字というのは、存在しない漢字のデザインを戸籍係が字の形を
登録することを言います。
これは、どんな文字でも作れるという意味では最強で、利用者の
ウケも良いのですが、どうにもならない問題が二点ありました。

１）文字デザインの共有が面倒
２）他組織との共有が事実上できない

最初のデザイン共有の面倒さですが、外字というのは漢字を絵と
して作るのですから、デザインデータがあるコンピュータでしか
使えません。

しかも外字を使いたい全てのコンピュータに事前配布する必要が
あります。外字を追加した時やデザイン変更する都度、全コン
ピュータに外字データを再配布するのは神経を使いますし、手間も
かかります。

二つ目の問題は外字のコードポイントを自由に選択ができること
です。（範囲の制約はあります）
好きにコードポイントを選べるわけですから、ホントなら同じ
デザインの文字は同じコードに統一したいところですが、役所に
よってコードポイントはバラバラです。

これが規約で規定されている文字なら、どの文字が何番と決まって
います。例えば"A"という文字は65番、"B"は66番、"C"は67番と
いった具合です。
だから、ABCという文字列は必ず65 66 67 という三つのデータに
なり、データ交換しても"ABC"として通じるのです。

ところが、外字のコードポイントは自分で決めるしかありません。
同じ「はしご高」であっても東京の戸籍係はコードポイント100番、
大阪の戸籍係は120番、神奈川では150番などとバラバラになら
ざるを得ません。

逆に言えば、東京では120番に「たち崎（右上が立になってる崎）」
なっていたり、大阪では100番に「つち吉（上半分が士ではなく土
になってる吉）」が割り当てられているかもしれないのです。

こうなると、東京と大阪で名前データを交換しようとしても、
無茶苦茶になります。
東京の「山崎」さんが大阪では「山高」さんになり、大阪での
「吉田」さんが東京では「高田」さんになってしまいます。

これでは、全くデータ交換ができません。

特に後者のデータ交換がまともにできないということは致命的な
問題であるため、外字による文字作成は除々に行われなくなり
ました。

3. メーカ毎の拡張文字の登場

外字に頼る方式ではデータ交換が行えないため、当時の大型コン
ピュータを作っていた各メーカは独自に定義した文字コードを
ユーザに提供していました。
例えば次のようなものがありました。
　IBM：IBM漢字コード
　日立：KEIS（ケイス）
　富士通：JEF（ジェフ）

こういった文字コードはJISの漢字コードとの親和性を確保しつつ
様々な記号や異体字を積極的に取り込んでいました。
当時はコンピュータメーカにとって行政は上得意さんでしたので、
戸籍用にも採用されるように積極的に文字追加をしたのです。

これなら同じメーカ製品を使っている限り文字コードが共通化でき
ますから、外字に比べてずっと運用はラクになりました。

また、メーカ側から他社の文字コードへの変換ツールなどが提供
されましたから、多少の手間はかかりますが他の役所とデータ交換
できるようになったのは大きな進歩でした。

それでもまだ問題は残りました。

ひとつは、メーカによって収録されている文字が違っているため、
一部の文字はデータ交換ができませんでした。
また、同じ氏名でも異体字での検索洩れが起きやすい点も未解決
のままでした。

4. IBM拡張文字

こんな中でいろいろな動きがありました。
（面白い話もいろいろあるのですが昔話ばかりなので、ばっさり
省略します。）

その中でパソコンでよく使われる「はしご高」や「たち崎」を
含んだIBM拡張文字と呼ばれる400文字弱の文字セットがWindowsで
採用されました。20年以上も前の話です。

実は、この時点でWindowsパソコン限定で「はしご高」などは表示
可能だったのです。

実際、今のWindowsパソコンであれば「たかはし」を変換すると
「はしご高」の髙橋さんが出てきます。

では、「はしご高」問題は解決しているのでしょうか？

いえいえ、ここで解決したのは「Windowsでは入力ができ、表示
できるようになった」点です。
コンピュータの間で文字情報の交換ができるという意味では解決
はできていないのです。

2021年現在、パソコンと言えばほぼWindowsPCですが、スマホは
AndroidかiOSですし、サーバについてもWindowsは少数派です。
つまり、インターネット上での情報交換と考えるとWindowsだけが
対応していてもどうにもならないのです。

また、IBM拡張漢字で解決できるのは比較的よく使われる一部の異体
字だけで、「つち吉（上半分が士ではなく土の吉）」や「一点しん
にょうの辻」、「点のついた土」など含まれていない字はたくさん
あります。

これらをクリアできる方法がいろいろと模索され「異体字セレクタ」
というものが考案されました。

5. 救世主としての異体字セレクタ

その中に異体字セレクタというアイデアがありました。

その方法というのは、特定の文字コードの後に異体字を示す専用の
コードを埋め込むことで、異体字を示すというものです。

言葉だとわかりにくいですが、そんなに難しい方法ではありません。

具体例として「辻」さんを考えてみます。

標準字体（普通に漢字変換した時の字形）ではしんにょうの点は
二つです。（意識したことのある方は少ないと思いますが...）

通常の「辻」さんをUNICODEという方式でコード化するとこうなり
ます。

　辻　-> 36795

この36795という番号が「辻」という文字のコードポイントです。
一方、一点しんにょうの辻本さんの場合は後ろに別の数字が付きます。

　辻　-> 36795 917761

この9177615 が異体字セレクタで、36795の後に9177615という異体字
セレクタを加えて2データで一点しんにょうの「辻」さんを示すわけ
です。

「36795のデータの後に9177615（付加情報）が付いている」ことは
異体字セレクタを理解できないアプリでも理解できます。
ですから、異体字セレクタが処理できなくても「辻」という文字は表示
できるというわけです。

この方式のもう一つのメリットは検索をする時にあります。
「辻」を検索する時には上記の 36795 というコードを探すわけですが、
この方式なら、二点しんにょうでも一点しんにょうでも検索が可能です。

こうして、ようやく異体字が識別できる環境が整いました。

6. 常に異体字が表示できるわけではない

上述の異体字セレクタという考え方が採用されたのですら15年以上
も前の話です。

15年も経ってるというのに、今だに異体字が表示されない状況が
続いているのはどういうことでしょうか？

異体字の定義はJISのような公的な団体が行っているわけではあり
ません。
Adobeなどの私企業が集まって行っている活動です。
そもそも異体字の仕組みが決まったからといって異体字がただちに
揃うはずもありません。異体字の登録を受け付ける窓口も必要ですし、
登録された異体字を含むフォントを作ったり、その配布を行ったり
といった作業が必要です。
こういったものを何もない状態から作り上げるにはどうしても時間が
必要です。

2021年現在、登録済の異体字は既に２万字を越えており、使えない
異体字はもはやないと言っていい状況です。

ですが、異体字セレクタは単なる文字追加ではありませんから、各
アプリ側の対応が必須です。

残念なことに、様々なサービスを提供している側から見ると、異体
字セレクタに対応してもあまりアピール度は高くありません。
いきおい、それよりもアピールしやすい機能の実現が優先されるの
は仕方ないとはいえ残念な話です。

こういった問題もあるため、異体字がどこでも問題なく表示できる
ようになるにはまだ時間が必要、というのが実際のところです。

7. まとめ

異体字が表示できないという問題は既に1970年代に戸籍係などで
表面化していました。

当時は外字という文字デザインを役所の戸籍係が個別に作ったり
していましたが、そのままではまともにデータ交換が行えません。

そのため、各メーカはJISに含まれない人名漢字などを積極的に
追加しましたが、これもメーカ間の統一が取れず、決して成功した
とは言いがたいものでした。

その後、UNICODEという文字コードの中で異体字セレクタという
方式が採用され、その方式にもとづいて２万を越える文字が登録
されています。

その意味で異体字を使える環境は整っているのですが、現在は
各アプリの対応が必要です。

また、一部ではサービス側の定義が古くて未対応というものもあり
ます。例えば電子メールでは、ベースとなる規約上は今も日本語の
異体字セレクタには未対応のままです。

次回は、今回説明しきれなかった電子メールやWeb上で異体字が使え
たり使えなかったりする理由について解説します。

次回もお楽しみに。

このNoteは私が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html