More than 5 years have passed since last update.

Unicodeと異体字とフォントについて調べてみた

Last updated at 2016-12-24Posted at 2016-12-24

はじめに

外字について色々調べているうちに、自分自身がUnicodeや異体字について、ちっとも分かっていないということが分かりました。そこで、調べた内容をまとめてみました。

情報の密度よりも、文字コードやフォントに関わるときの最低限の知識として、またはCheatsheetとして読み返せる内容としてまとめたつもりです。

誤った内容があればご指摘頂けると幸いです。

JIS97

JIS漢字コードはJISが規定した文字集合。俗にJIS漢字コードというと以前はJIS97を指し、正確には「JIS X 0208:1997」という規格である。
6,879個の図形文字を規定。漢字は第一水準と第二水準を搭載。基本的には、区と点で表現し区点コードによって配置している。区点コードは全角文字（非漢字含む）の定義であり、半角文字は含まれていない。

区点コードのような文字集合の中での配置番号を「コードポイント」と言う。

区点コードは10進数であり、また半角文字は制定されていない。また、ASCIIとの互換性もなく、あくまでも文字集合としてのコードであるため、文字コードとして符号化（エンコーディング）されている。文字コードは符号化形式とも言う。

JISが制定した符号化形式を俗に「JISコード」といい、メールソフトウェアなどでは「ISO-2022-JP」というISO規格番号で表記されることが多い。

他にもEUC-JPやShift_JISといった符号化形式が存在する。

EUCとは、主にUNIX上で使われていた符号化形式。コンピュータの黎明期にはOSなどによって符号化形式が異なることがあった。IBMのオフコンでは、EBCDICという文字コードもあった。
そのEUCの上に、ASCIIとJIS X 0208を搭載したものをEUC-JPという。

一方、JISコードは、半角カナは制定されていない符号化形式であるが、パーソナルコンピュータで漢字が扱えるようになるに従い、それよりも前に普及していた「半角カナ」が使用できないJISコードでは不都合があった。そのため、文字コードをずらして（シフト）、半角カナも扱えるようにした文字コードがShift_JISである。

いずれも過去との互換性重視によって乱立したともいえ、Unicodeの誕生はこうした時代背景による要請の帰結と言える。

UnicodeとUCS

Unicodeは文字集合であり、JISのような区点の他に面という概念が加わっている。
Unicodeに関連して、UCSという規格も出てくるが、Unicodeはゼロックスが提唱し、コンピュータメーカー等が参加する「ユニコードコンソーシアム」が制定したものであるのに対し、UCSは国際規格（ISO/IEC 10646）である。

UCSは元々各国の文字コードを包括したものとして企画されていたが、実質Unicodeに乗っ取られ、Unicodeをそのまま包括している。ただしUnicodeが16bitで全ての文字を表現するという理想で２オクテットのコード体系であったのに対し、群面区点の４オクテットのコード体系（UCS-4）となっている。UnicodeのBMP（基本多言語面）だけ使用したUCS-2もあるが、2011年の改定で廃止されている。

このコードポイントを符号化する形式（文字符号化スキーム）として、UTFがある。

符号化形式	摘要
UTF-16	１文字を16bit（またはサロゲートペアにより32bit）で符号化される形式
UTF-32	32bit固定長の符号化形式
UTF-8	従来のASCIIと互換性を持たせた可変長形式（１～４オクテット）
符号化する仕方の違いであるから、いずれの符号化形式でも、表現できる文字数に差はない。

Unicodeはその理想から、当初、似たような漢字は同じ文字と見なす（CJK統合漢字）というCJK地域にとっては乱暴な文字集合となっていたため、Unicode1.0で未定義の領域への追加文字要求が起こった。結果として基本多言語面だけでは文字が不足し、16bitでは収まらなくなった。そのためCJK統合漢字拡張B以降の拡張漢字集合は追加面（BMP以外の面）に制定しており、Unicode2.0からサロゲートペアが導入された。

UTF-32は４オクテットであるから、UCS-4と互換性があり全ての文字が表現できるが、UTF-16では２オクテットであるから、UCS-2とは互換性があるがUCS-4とはない。このため「16bit単位」のままで表現できるようにしたのがサロゲートペアである。

サロゲートペアは、使用されていない文字コードを使って面を表現する。そのため、サロゲートペアが使用されていない場合は、１文字は16bitであるが、使用されている場合は１文字が32bitとなる。その性質から、サロゲートペアはUTF-16でしか使用されない。

固定長のUTF-16/32では、8bit単位での処理（メモリに直接配置など）に向いている特性から、バイト順マーク（BOM）を付ける（バイトオーダーが明確なUTF-16LE/BE、UTF-32LE/BEを除く）。省略した場合は、リトルエンディアンとして扱う。

一般的にUTF-8を使用することが多いが、UTF-8は8bitを基本としていることからも分かるとおり、欧米での効率がよい。日本語の場合は３オクテット必要となることから、BMPであれば２オクテットで収まるUTF-16の方が効率がよいとされている。（基本的な文字はBMPだけで表現できる）

ちなみにutf8mb4は、UTF-8でありながら３オクテットまでしか扱えない「CESU-8」仕様で実装したDBMSにおいて４オクテット目まで使えるようにした「本来のUTF-8」であるため、たぶん当該DBMS以外では使用しない名称。

JIS2004

JIS97をベースに必要性の高い4,354字を加え、第三・第四水準漢字として定めた文字集合として改定されたのが、JIS2004（JIS X 0213:2004）である。

JIS2004では、168字例示字形が変更された。例示字形とは、その名の通り字形の例示であって、何ら規範的な役割を持たないと謳われているが、実際に字形が変更されたことによる混乱が少なからず発生している。

元々、手書きが普通であった時代に、最低この漢字は使いましょうと定義されているのが「常用漢字表」、コンピュータの普及によって、この表に含まれていない文字も安易に使用できるようになった一方で、その字形についてはバラツキが生じていたため、国語審議会の答申として定められているのが「表外漢字字体表」である。

変更される前のJIS90字形では、戦後の（手書きの）略字ルールが反映されて、本来の漢字とは異なる字形であった。コンピュータ化…つまり手書きを考慮する必要性が減ったことによって、本来あるべき字形は「表外漢字字体表」の字形あるという観点から、こちらに合わせることになった。

符号化形式としては、「ISO-2022-JP-2004」「Shift_JIS-2004」「EUC-JIS-2004」として対応を図っており、ISO-2022-JP-2004とEUC-JIS-2004が面の拡張（エスケープシーケンスの違い、または空き領域への制定）なのに対し、Shift_JIS-2004は、無理矢理詰め込んだため、Shift_JISの上位互換となっているが、JIS X 0208とは整合的ではない。

Unicodeの場合、一部の文字が追加面にあるため、使用するアプリケーションにおいて、UTF-16ではサロゲートペアに対応している必要がある。

異体字とIVS

異体字とは、意味としては同じ文字であるが字形が異なる文字を言う。

「高」に対する「髙」は異体字ではあるが、全ての異体字を一括りにして捉えることはできない。
それは、文字によって独立したコードがある文字と、VS（字形選択肢）によって表現するものとがあるからである。

JIS規格が字形を重視していなかった間に、IBM拡張文字という400字弱の文字がWindowsで独自採用されたため、JIS規格外の文字（機種依存文字）が生じてしまった。

現在は、基底文字に対して、異体字セレクタと言われるコードを付加することによって、異体字を表現する仕組みとして、IVD/IVSという規格が制定されており、多種多様な字形に対応するが、この「IBM拡張文字」に含まれている文字は、文字コードとしても別のコード体系を持っている。
IVSは、VSの種類の一つ。IVSで符号化する前に、字形を登録するデータベースがIVDである。

例として、高は「U+9AD8」であるが、髙は「U+9AD9」である。対して、葛の字はどの字形であっても基底文字コードは「U+845B」であり、IVSによって「U+845B U+E0100」とするか「U+845B U+E0101」とするかで字形が変わる。

このあたりは図形表現の揺れとみるか、個々に意味を持つものかという判断ではないだろうか。JIS第三・第四水準が人名漢字等を重視して制定されているのも、そうした理由ではないかと思われる。

フォントにおける字形選択の仕組み

文字コードは、エンコーディングやプラットフォームによって異なる場合があることから、元々フォントデータは特定の文字コードでは管理されていない。
フォント上はGID（TrueType/OpenType）またはCID（PostScript）というコードで文字データを管理している。実際の文字コードとGID/CIDをマッピングするのがcmapである。JIS2004の字形変更は、このcmapのマッピング変更によって対応している。

また、縦書き・横書きなどといった違いにも対応できるようになっている。フォント上は、文字コードが何も割り当てられていないが文字データは存在するということが可能である。

実際、IPAmj明朝は、文字情報基盤漢字として58,860文字を収容済であるが、1,982文字はまだUCS符号化やIVDへの登録が行われていないため、文字コードでは呼び出すことができない。これは国際提案済で、承認されれば追加されるとしている。

Adobe-Japan1

DTPにおいては、特に漢字の再現性が重視されることもあり、Adobeの独自規格としてAdobe-Japan1（AJ1）という文字集合規格が制定されている。
もっとも文字コードとのマッピングはCmapを使っているため¹、AJ1用の符号化形式は存在しない。どちらかというと、JIS第一水準・第二水準…等の定義と同様である。

Adobe独自の規格ではあるが、DTPにおいてはPostScriptがデファクトスタンダードであったことや、JIS規格が紆余曲折あったのに対して、安定して拡張されていることからも、特に業務用フォントにおいては事実上の標準となっている。

規格	摘要	フォント名	搭載グリフ数
AJ1-3	JIS第一第二水準＋IBM拡張文字	Standard	9,354
AJ1-4	人名漢字などを拡張	Pro	15,444
AJ1-5	JIS第三・第四水準をカバーした	Pr5	20,317
AJ1-6	JIS2004の全ての図形文字をカバー	Pr6	23,058

これだけ種類がある理由は、段階的に拡張してきたという点もあるが、例えばポップ体に第四水準漢字があまり必要とされていないといった書体ごとでどこまで対応するか方針が異なるという点もある。
AJ1-4とAJ1-6でも7,614文字異なり、必要とされていない文字にコストをかけたくないというメーカーの判断もあるだろう。特にフォントが多様化した現代においては、安易にAJ1-6対応がベストというわけではない。
また、先のIPAmj明朝への搭載グリフ数（58,860）で分かる通り、AJ1-6が全ての漢字を収容しているわけではない点を誤解のないよう。この点はIPAも、外字を無くすための取り組みとして行っており、いたずらに使用文字種を増やすべきでなく、アイデンティティに関わる用途等に限定すべきであるとしている。²

なお、JIS2004での字形変更に対応したフォントはNが付き、ProN,Pr5N,Pr6Nとなる。

参考文献

漏れがありますので、随時追記します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up