「Unicode」の版間の差分

Unicode(ユニコード)とはコンピュータ上で多言語の文字を単一の文字コードで取り扱うために1980年代に提唱された文字コードである。

ゼロックス社が提唱し、マイクロソフト、アップル、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られ、1993年にISOでもISO/IEC 10646の一部として標準化された。

Unicodeは世界で使われる全ての文字を共通の符号化文字集合にて利用できるようにしようという考えで作られ、NT系のMicrosoft Windows、Mac OS X、LinuxやJavaなどでの内部コードとして利用されている。

元々16ビットの文字集合^[1] で全ての文字の網羅を目指して開発されたが、コードポイントが圧倒的に足りず、現在では21ビットの文字集合^[2] として規定されている。

収録されている文字は、各国で標準として規定されている文字セットや実際に使用されている文字を持ち寄り、委員会により取捨選択されている。日本の文字については当初よりJIS X 0201、JIS X 0208とJIS X 0212を、Unicode 3.1ではJIS X 0213の内容を収録している。

また収録においては同じ意味・目的の文字は、できる限り同じコードポイントに割り当てる方針を取っている。そのため、CJK統合漢字(中国語、日本語、朝鮮語で使用される漢字が統合された領域)は大きな議論となった。各国のコードはISO/IEC 10646とは別の組織で標準化されているため、厳密には違うものであるが、コードポイントを共有する文字の間で非互換が生じないように慎重に標準化が進められている。

既存の符号化方式との相互運用性もある程度考慮されており、同じグリフ(字形)の文字であっても、歴史上・実用上の識別が求められる場合には互換領域がとられ、Unicodeを介在して文字コード変換を行った際に、復元可能となるように考慮されている。しかしながら、他の符号化文字集合(文字符号化方式)との変換の整合性においては、いくつかの問題がある^[3] 。

Unicodeの文字を表現する場合、"U+"にその文字のコードポイントを表す16進数を続けた文字列を使って表す。BMPの場合は4桁、それ以上では必要に応じて5、6桁で表す。

Unicodeに収録されている文字については、#一覧の「コード順分類一覧」を参照。

UTF-7

UTF-16 (後述)で表したUnicodeをBase64で変換して表す方式。ただし、ASCIIのアルファベット範囲等についてはBase64に変換しない等、特殊なエンコーディングを行う。かつてのSMTP等のように、7ビット単位でしかデータを扱えない通信方式を利用する場合を想定して作られている。ステートフルエンコーディングであり、運用上問題が多いため、現在ではこの方式は推奨されていない。Unicode文字を7ビット単位伝送通信にどうしても通さなければならない場合は、替わりにUTF-8をQuoted-printableあるいはBase64で変換するなどの方式が好ましいとされる。

UTF-8(UTF-2、UTF-FSS)

8ビット単位の可変長コード(1〜4バイト)にエンコードする方式。ASCIIに対して上位互換となっており、文字の境界が明確である、エンコード・デコードに際して乗除算などの負荷の高い処理が必要ないなどの特長を持ち、インターネットではもっとも一般的に利用されている。

日本国内でのみ、 BOM (Byte Order Mark) がついているものをUTF-8、ついていないものをUTF-8Nとして区別することがあるが、国際的には認知されていない。^[4] Internet Explorerでは、BOMのついていないUTF-8の文書を読み込むと(日本語版の場合)Shift_JISだと誤認する一方で、BOMがついていると有効なデータとして受け付けないアプリケーションも存在する。^[5]

UTF-16

BMP (基本多言語面)を16ビット、その他を#サロゲートペアという仕組みを使い32ビットで指定する方式。Windows XPなどの近年のOSの内部コードには、この形式が使われている。UCS-2ともBMPの範囲で互換性がある。

ファイルの先頭には通常BOM^[6] が付与される。ビッグエンディアンのものをUTF-16BE、リトルエンディアンのものをUTF-16LEとして区別することもある。MIMEなどの手段で文字符号化方式にUTF-16BEやUTF-16LEを指定している場合にはBOMを付与することは許容されない(ZERO WIDTH NON-BREAKING SPACEとして扱う)。Windows上の文書における「Unicodeテキスト」は特に明記のない場合につき、リトルエンディアンのUTF-16のことを指す。TCP/IPネットワークではプロトコルヘッダやMIME等の手段で文字符号化方式が指定されずBOMも付与されない場合、ビッグエンディアンに決められている(→ エンディアン)。

UTF-32 (Unicode 3.1より)

Unicodeの全コードを単一長のコードとして32ビットで指定する方式。実際に使われるのは21ビット(Unicodeの空間がU+10FFFFまでであるため)。この21ビットの範囲内ではUCS-4と互換性がある。これもUTF-16と同じく、ビッグエンディアンとリトルエンディアンが存在し、それぞれUTF-32BE、UTF-32LEと呼ばれる。MIMEなどの手段で文字符号化方式にUTF-32BEやUTF-32LEを指定してる場合にはBOMを付与することは許容されない(ZERO WIDTH NON-BREAKING SPACEとして扱う)。単純な符号化方式であるが、テキストファイルなどでは文章のサイズが大きくなるため(全てBMPの文字からなる文章の場合はUTF-16符号化の2倍のサイズとなる)使用されることは稀である。そのためかMicrosoft Officeでのエンコードされたテキストファイルの読み書きはこの符号化方式には未だ対応していない。フリーウェアおよびシェアウェアの多数の符号化方式に対応しているテキストエディタでもこの符号化方式には対応していないものは多い。ただしすべてのUnicodeを扱う処理を行う場合には、すべての文字を同一のバイト数で表現したほうが処理に適するため、内部の処理ではUTF-32(あるいはUCS-4)で行うことも多い。

UTF-16などと同様にUTF-32にもBOMがあり、データストリームの先頭に付される。先頭の4バイトが0xFF,0xFE,0x00,0x00ならリトルエンディアン、0x00,0x00,0xFE,0xFFならビッグエンディアンになる。UTF-16のリトルエンディアンとUTF-32のリトルエンディアンは最初の2バイトが等しいため、4バイトまで読んで判断する必要がある。

以下はエイプリルフールに公開されたジョークRFCである。UTF-9に関しては同名の規格が実際に検討されていたが、ドラフト段階で破棄されているため重複にはならない。

UTF-9

可変長の9ビットコードによりエンコードする方式。1バイトが8ビット(オクテット)ではなく9ビット(ノネット)であるような環境での利用を想定している。UTF-8と比較した場合、Latin-1領域が1バイト、CJK統合漢字領域が2バイトで表現できる特長があり、データ量が少なくなる。ワード長が9の倍数のコンピュータ(ACOS-6など)であれば計算コストも低い。

UTF-18

Unicode符号位置を単一の18ビットによりエンコードする方式。UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた4つの面を余った2ビットで識別するため、サロゲートは使わない。

以下はドラフト段階で破棄された規格案。

UTF-5

国際化ドメイン名での利用を想定し、0〜9、A〜Vの32文字でエンコードする方式。国際化ドメイン名にはPunycodeが採用されたため、利用されていない。

UTF-9

8ビット単位の可変長コード(1〜5バイト)にエンコードする方式。ISO-8859-1に対して一部互換である。しかし、UTF-8が普及しつつあり、それと比べて欠点がいくつかあったため、破棄された。

Unicodeは 2¹⁶ = 65,536 種類の文字を収録でき、当初の構想では世界中のすべての文字をこの16ビット固定長のコード体系に登録可能と思われていた。だが、Unicode 1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。その内容は中国、日本、台湾、ベトナム、シンガポールの追加漢字約1万5千字、古ハングル約5千字、未登録言語の文字等々である。このため、Unicodeの16ビット枠内に全世界の文字を収録するという計画は早々に破綻し、1996年、Unicode 2.0ではサロゲートペア (Surrogate Pair) の拡張が盛り込まれた。Surrogateは「代理」、Pairは「対(つい)」の意味。

サロゲートペアは16ビットUnicodeの未定義領域1024文字分を2つ使い(前半0xD800〜0xDBFF, 後半0xDC00〜0xDFFF)、それをペアにすることで1文字を表し (1024 ×ばつ 1024 = 1,048,576文字)、その1,048,576文字を256 ×ばつ 256の区点 (row, cell) からなる「面」 (plane) に順番に割り振っていく。これにより 1,048,576 / (256 ×ばつ 256 = 65,536) = 16 で、全部で第16面までの文字を収録することができる。つまり第01面から第16面までであり、これに加えて第00面 (BMP) も使用可能なので、合計で 1,048,576 + 65,536 - 2,048 = 111万2,064文字が使用可能になる。エスケープシーケンスこそ使用しないものの、16ビット文字コード体系との互換性を維持するために、UTF-16(16ビットを基本単位とする文字符号化方式)を採用した結果、Unicodeは16ビットと32ビットが混在する複雑な可変長文字コードとなってしまった。

サロゲートペアの方式は16ビット固定長を志向したUTF-16との互換性維持のために設けられた拡張であり、UTF-8符号化方式やUTF-32符号化方式では利用できない。

現在第1面はSupplementary Multilingual Plane(SMPと略される。追加多言語面。主に古代文字が収録されている。)、第2面はSupplementary Ideographic Plane(SIP, 追加漢字面。漢字専用領域。)、第14面はSupplementary Special-purpose Plane(SSP, 追加特殊用途面。制御コード専用領域。)、第15面および第16面は私用目的のための面(BMPのU+E000〜U+F8FFの領域の拡張)と決められている。

第3面〜第13面は未使用である。(そのうち第3面は漢字が第2面で足りなくなったときのために予約されている。)

日本では2000年にJIS X 0208を拡張する目的でJIS X 0213(いわゆるJIS第3第4水準)が制定されたが、この際、新たに採用された文字でUnicodeに無かったものの一部は、BMPに収録できず、第2面への収録となった(最終対応は2002年)。このため、JIS X 0213収録文字をUnicodeで完全にサポートするには追加漢字面をサポートしたOS、フォント、アプリケーションが必要となる^[7] 。

Unicodeは同一のコードでもバージョンが変わったとき完全に異なった文字を定義し直したことがある。

最も有名な事象がUnicode 2.0でのハングルの大移動である。これはUnicode 1.1までで定義されていたハングルの領域を破棄し、新しいハングルの領域を別の位置に設定し、破棄された領域には別の文字の領域を割り当てることとなった。その後、Unicode 3.0でCJK統合漢字拡張Aが割り当てられた。このように、Unicode 1.1以前でハングルを記述した文書とUnicode 2.0以降でCJK統合漢字拡張Aを記述した文書には互換性がない^[9] 。

Shift_JISではJIS X 0201における円記号 "¥" が0x5Cに置かれている。これをUnicodeのマッピングに合わせるとYEN SIGN (U+00A5) にマップされる。しかし、0x5CはASCIIではバックスラッシュ "\" に相当し、C言語などのエスケープシーケンスに使われる事から、この文字のコードを変更すると問題が起きる。そのためUnicodeを利用するアプリケーションはU+007F以下のコードに関しては移動させないという暗黙のルールができている。

そうなると、Unicode環境では円記号がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの0x5Cの位置には円記号の字形を当ててしまうことで対処している。これによって、それまでの文字コードを使用していたときと同じ感覚で円記号を用いることができる。

この問題は日本語環境に限った事ではない。もともと、ISO646上で0x5Cを含む数種の文字は自由領域(バリアント)として各国での定義を認めていた。そのため、日本語以外でもASCIIでバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、韓国ではウォン記号 (WON SIGN, U+20A9, "₩") である。

JIS X 0221規定のJIS X 0208とJIS X 0221の対応表では、波ダッシュはWAVE DASH (U+301C, "〜") に対応させているが、マイクロソフトはWindowsのShift_JISとUnicodeの変換テーブルを作成する際に、JIS X 0208において1区33点に割り当てられている波ダッシュ "〜" を、Unicodeにおける全角チルダ (FULLWIDTH TILDE, U+FF5E, "～") に割り当てたため不整合が生じる。この結果、Mac OS等のJIS X 0221準拠のShift_JIS ⇔ Unicode変換テーブルをもつ処理系と、Windowsとの間でUnicodeデータをやり取りする場合、文字化けを起こすことになる。そこでWindows以外のOS上で動くアプリケーションの中には、CP932という名前でマイクロソフト仕様のShift_JISコード体系を別途用意して対応しているケースが多い。この原因とされているUnicode仕様書の例示字形の問題に関しては、波ダッシュ#Unicodeに関連する問題を参照すること。

また、マイクロソフトは同様にEM DASH (U+2014, "—") をHORIZONTAL BAR (U+2015, "―") に、DOUBLE VERTICAL LINE (U+2016, "‖") をPARALLEL TO (U+2225, "∥") に、MINUS SIGN (U+2212, "−") をFULLWIDTH HYPHEN-MINUS (U+FF0D, "－") に割り当てており、これらの変換時にも問題が起こる。^[10]

ブロックの日本語名称はJIS X 0221-1:2001によった。他の記事で用いられている名称と異なる場合、その名前を併記した。

• ISO/IEC 10646
• 文字コード
• OpenType
• 機種依存文字
• 国際化と地域化

• 公式サイト
• DecodeUnicode

1. ^ 現在、BMPで規定されている領域のみの文字集合。この文字集合の範囲は、ISO/IEC 10646におけるUCS-2で定義される範囲と同一。
2. ^ ISO/IEC 10646におけるUCS-4は31ビットの文字集合であり、これとは別物。
3. ^ 例えば、CP51932とeucJP-MSのように既存文字コード同士でUnicodeとの対応が一部違う場合には文字化けが発生する等がある。
4. ^ もともと8ビットを基本とするUTF-8ではBOMを付与する必要はないが、UTF-8であることが識別できるようにデータストリームの先頭に EF BB BF の3バイトが付与されることがある。Windowsのメモ帳で作成した「Unicodeテキスト」には標準でBOMが付与される。
5. ^ ここでいうBOMはバイトオーダーを表すものではなく、UTF-16における「真の意味でのBOM」と類似する存在であるがゆえに慣用的にこう呼ばれているに過ぎない。
6. ^ BOMとは、8ビットを基本とするシステムでバイトオーダーを識別するための印であり、データストリームの先頭に付与される。値はU+FEFF。システムが読み込んだ先頭2バイトが0xFF,0xFEならリトルエンディアン、0xFE,0xFFならビッグエンディアンとして後に続く文書を処理する。
   RFC 2781 ではBOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Windowsのメモ帳で作成した「Unicodeテキスト」は標準でBOMが付与されるようになっている。
7. ^ Shift_JIS等、Unicodeにて規定されるもの以外のエンコーディングを利用する場合であっても、JIS X 0213に対応するフォントやアプリケーションが必要なことは言うまでも無い。
8. ^ "BETA Unicode 5.1.0". Unicode Consortium (2008年03月26日最終更新). 2008年3月27日閲覧。
9. ^ RFC 3629の5. Versions of the standardsでKorean mess (ハングル大移動) について、8. MIME registrationでUTF-8にバージョン指定がない理由についての言及がある。
10. ^ Windows VistaやOffice 2007に付属するIMEパッドにおいてJIS X 0208やJIS X 0213のマッピングは上記の文字についてもJISで規定されているマッピングと同じマッピングを使用している。

Template:Link FA ru

Template:Link FA

• Unicode

• RFCマジックリンクを使用しているページ