なぜU+53E0はMacとWindowsで違うのか

• 前回のエントリでUnicodeがウカンムリとワカンムリを包摂している例について調べていて気付いたのだが、U+53E0の実装は、けっこう妙な運命を辿っている。まず、U+53E0をヒラギノ明朝とMS明朝で表示してみると、下図のようにウカンムリ／ワカンムリの違いがある。

• ヒラギノにおけるCID=19219（ウカンムリ形）のソースは、写研の電算写植の文字。これがISO/IEC 10646-1:1993のT欄のグリフ（下図）と一致したため、U+53E0と対応付けられたものと思われる。このマッピングはAdobe-Japan1-5以降に受け継がれている。

• 一方ワカンムリ形のほうは補助漢字（JIS X 0212:1990）の例示グリフであり、これをソースとしてAdobe-Japan1-6でCID=21248に追加された。かつてAdobe-Japan1-5がJIS X 0213に対応した際には、JIS X 0213の例示グリフを優先するようマッピングの変更が行われたが、補助漢字についてはそのような変更は行われていない。Adobe-Japan1-6でも、U+53E0と直接対応するのはウカンムリ形（写研出自）のCID=19219であり、補助漢字の例示グリフであるCID=21248は、'hojo'タグによって参照されるのみである（下図）。

• ところが（1993年版よりも新しい）ISO/IEC 10646-1:2000では、（台湾の規格であるCNS 11643で何があったのかは知らないが）U+53E0の5欄併記の例示グリフの中から、ウカンムリ形のもの（CID=19219）は消えてしまっている（下図）。

• そんなわけで、ヒラギノあるいはAdobe-Japan1フォントにおけるU+53E0の実装グリフは、「どの規格にも一致する形がない」という一見不思議なことになっている。一方、MS明朝が参照しているのは補助漢字だから、その実装と規格（JIS X 0212、ISO/IEC 10646、Unicode）の例示は一致している。