しってても教えてくれない。文字コードの呪い【後編】— フォントの呪いと“見た目が違う同じ文字”

はじめに：先人は頑張っていた。でも、時すでに遅かった。

前編（¥とShift_JISの話）では、文字コードの衝突が引き起こした“¥問題”を取り上げました。
しかし日本語の混乱は「コード」だけでは終わりません。
フォント（字形）そのものが別の地雷を埋めていたのです。

同じ文字なのに見た目が違う。

そして、見た目が同じなのに別の文字。

——それが「フォントの呪い」。

1980年代のNEC PC-9801 シリーズは、当時の日本のPCの事実上の標準機でした。
このマシンのフォントはなんと ROMチップに焼き込み済み。

つまり：

この方式は超安定。
Shift_JISの欠陥も「ハード側が帳尻を合わせる」ことで表面的には破綻しませんでした。

1990年代に入り、IBMが「日本語もVGAで出そう」と考案したのが DOS/V。
（VはVGAのV。NECへの“勝利”を皮肉ってVictoryとも）

フォントをROMから外し、メモリ上で描画するアーキテクチャを採用。
これにより：

“日本語がマシン依存”から“フォント依存”に変わった瞬間です。

Windows 3.1／95 では、TrueTypeフォント（.ttf）が導入され、誰でも独自フォントを作れるようになりました。
結果、こんな状況に：

文字	フォントA	フォントB	結果
`\`	¥に見える	バックスラッシュに見える	見た目バラバラ
`～`（波ダッシュ）	長い波線	チルダに近い形	両者で印象が違う
`ー`（長音）	太め直線	細めチルダ風	音引きがズレる

MSゴシック・DF平成ゴシック・リコー明朝・ヒラギノ…
どれも同じ文字コードを持つのに、グリフが違う。

しかも、印刷所や自治体では「フォントが違うだけで文書がずれる」事故が多発しました。

有名な例が 「～」(波ダッシュ) 問題。

種類	コード	Unicode	意味
波ダッシュ	JIS X 0208:0x2141	U+301C	日本語規格（古）
全角チルダ	Unicode互換	U+FF5E	欧文互換（新）
全角マイナス	—	U+2212	数式で使われる
長音符	—	U+30FC	カタカナ語用

同じ「～」でも、フォントによってはチルダやマイナスに見える。
印刷の現場では「~」が波線でなくチルダっぽく印字されるなど、混乱が日常茶飯事でした。

さらにWindowsが“日本語独自文字”を拡張。
「①」「㎡」「㍉」「㌢」「㌔」「髙」「﨑」などの 機種依存文字 を多数導入。

問題はこれ：

他のOS・フォントでは「存在しない」。

→ Wordで書いた請求書を別PCで開くと「□」になる。
→ Webで送ると「?」になる。

つまり、フォントが違えば文書の意味が壊れるという恐怖が広がったのです。

「直すと壊れる」
——それが、フォントの呪いの根底です。

いずれも「コードは同じ」「フォントが違う」だけの話。
でも、人間には“違う”と見える。
つまり 認知上のバグ が発生しています。

理由は単純。
歴史的資産の互換性を壊せないから。

コードではUTF-8を使う
　→ Shift_JISは過去資産専用と割り切る。
Webでは等幅ラテン系フォントを優先指定
　→ 特にバックスラッシュ、チルダ、マイナス記号対策。
WordPressでは投稿内CSSでフォントスコープを切る
　html 　<style> 　.bs-scope, .bs-scope code { 　 font-family: "Consolas","Menlo","Monaco","Courier New","Noto Sans Mono",monospace; 　 font-variant-east-asian: normal; 　} 　</style> 　
KaTeXでは文字出力時に \text{\textbackslash} を使う
PDF書き出し時は「フォント埋め込み」をONに

「バグではない、文化だ」
そう言う人もいます。

確かに、ROMフォントの精緻なドット設計は芸術でした。
だが、互換性の維持という呪いが長すぎた。

日本語のコンピュータ文化は、
努力と混乱の両方で作られた。

そして今、UTF-8とオープンフォントの時代に入った私たちには、
その歴史を「知って避ける」責任があります。