Unicode
出典: フリー百科事典『ウィキペディア（Wikipedia）』
Unicode（ユニコード）とはコンピュータ上で多言語の文字を一つの文字コードで取り扱うために1980年代に提唱された文字コードである。
目次 |
[編集] 概要
ゼロックス社が提唱し、マイクロソフト、アップル、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られ、1993年にISOでもISO/IEC 10646の一部として標準化された。
世界で使われる全ての文字を共通の符号化文字集合にて利用できるようにしようということで作られ、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とは別の組織で標準化されているため、厳密には違うものであるが、互いに非互換が生じないように慎重に標準化が進められている。
既存の符合化方式との相互運用性(interoperability)もある程度考慮されており、同じグリフ(字形)の文字であっても、歴史上・実用上の識別が求められる場合には互換領域がとられ、Unicodeを介在して文字コード変換を行った際に、復元可能となるように考慮されている。しかしながら、他の符号化文字集合（文字符号化方式）との変換の整合性においては、いくつかの問題がある[3]。
[編集] 文字集合
UNICODEに収録されている文字は以下の通り。
- 0面 BMP U+xxxx
- 基本多言語面(Basic Multilingual Plane)
- 収録されている主な文字は次の通り（一部記号などは省略）
- Basic Latin (アルファベットと一部の記号)
- Latin-1 (主にヨーロッパ諸国で使用される文字や記号)
- Latin Extended (主にヨーロッパ諸国で使用される文字や記号)
- IPA Extenshions （発音記号）
- Combining Diacritical Marks (ダイアクリティカルマーク)
- Greek and Coptic (ギリシャ文字とコプト文字）
- Cyrillic (ロシア語）
- Armenian (アルメニア語）
- Hebrew (ヘブライ語）
- Arabic (アラビア語）
- Syriac (シリア語）
- Thaana (ターナ文字)
- Devanagari (サンスクリット語）
- Bengali (ベンガル語）
- Gurmukhi (グルムキ文字)
- Gujarati (グジャラート語)
- Oriya (オリヤー語)
- Tamil (タミール語）
- Telugu (テルグ語)
- Kannada (カンナダ語)
- Malayalam (マラヤーラム語)
- Sinhala (シンハラ語)
- Thai (タイ語）
- Lao (ラオス語）
- Tibetan (チベット語）
- Myanmar (ビルマ語）
- Georgian (グルジア語)
- Hangul Jamo (ハングル文字）
- Ethiopic (エチオピア語)
- Cherokee (チェロキー語)
- Ogham
- Runic (ルーン文字)
- Tagalog (タガログ語）
- Hanunoo
- Buhid
- Tagbanwa
- Khmer (クメール語）
- Mongolian (モンゴル語）
- Limbu
- Tai Le
- General punctuations (句読点)
- Superscripts and Subscripts
- Currency Symbols (通貨記号)
- Combining Diacritical Markds for Symbols (記号用の合成記号)
- Number Forms（分数やローマ数字）
- Arrows (矢印)
- Mathematical Operators (数学記号)
- Optical Character Recognition (OCR用文字)
- Enclosed Alphanumerics (丸付き数字など)
- Geometric Shapes (地図記号)
- Dingbats
- Hiragana (ひらがな)
- Katakana (カタカナ)
- Bopomofo
- Kanbun （漢文用記号)
- CJK Unified Ideographs (漢字)
- サロゲート領域（文字ではない。後述のサロゲートペア用領域）
- Alphabetic Presentation Forms (合字）
- など
- 1面 SMP U+1xxxx
- 補助多言語面(Supplementary Multilingual Plane) - 古代文字、音符用記号など
- 2面 SIP U+2xxxx
- 補助漢字面(Supplementary Ideograph Plane) - CJK統合漢字Extension-Bなど
- 14面 SSP U+Exxxx
- 補助特殊用途面(Supplementary Special-purpose Plane) - 言語タグ、異体字セレクタなど
- 15面/16面 U+Fxxxx, U+10xxxx
- 私用領域（Private Use Area) - 外字
基本多言語面(BMP Basic Multilingual Plane)と呼ばれる16ビットで表現できる部分(プレーン)の標準化を終え、残りの16面(補助プレーン)の文字を選定中である。
[編集] エンコーディング(符号化方式)
UnicodeのUTFはUnicode Transformation Formatの略。
- UTF-1
- 初期に提案されていた、8ビットコードによる方式。ほとんど利用されることなくUTF-8にとって代わられた。
- UTF-5
- 国際化ドメイン名での利用を想定し、0～9、A～Vの32文字でエンコードする方式。利用されていない。
- UTF-7
- UTF-16で表したUnicodeをBase64で変換して表す方式。ただし、ASCIIのアルファベット範囲等についてはBase64に変換しない等、特殊なエンコーディングを行う。かつてのSMTP等のように、7ビット単位でしかデータを送信出来ない通信方式を利用する場合を想定して作られている。運用上、厄介な問題が多いため、現在ではこの方式は推奨されていない。Unicode文字を7ビット単位伝送通信にどうしても通さなければならない場合は、替わりにUTF-8を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として区別することもある。Windows上の文書における「Unicodeテキスト」は特に明記のない場合につき、リトルエンディアンのことを指す。
- UTF-32 (Unicode 3.1以降)
- Unicodeの全コードを単一長のコードとして32ビットで指定するコード。実際に使われるのは21ビット（Unicodeの空間がU+10FFFFまでであるため）。この21ビットの範囲内ではUCS-4と互換性がある。
また、一般には用いられていないが以下のような方式もある。
- UTF-9
- 可変長の9ビットコードによりエンコードする方式。1バイトが8ビット（オクテット）ではなく9ビット（ノネット）であるような環境での利用を想定している。UTF-8と比較した場合、Latin-1領域が1バイト、CJK統合漢字領域が2バイトで表現できる特長があり、データ量が少なくなる。ワード長が9の倍数のコンピュータ(ACOS-6など)であれば計算コストも低い。
- UTF-18
- UTF-9に拡張を施し、18ビットと36ビットで表現するようにした方式。UTF-8に対するUTF-16のようなもの。
なおこれら規格はエイプリルフールに公開されたジョークである。（UTF-9に関しては同名の規格が実際に検討されていたが、ドラフト段階で破棄されているため重複にはならないものと思われる。）
その他
- UCS-2
- これは、ISO/IEC 10646(UCS-4)のサブセットとしての符号化文字集合であるが、Unicodeの非公式な文字符号化方式としてよく使われる。UTF-16と似ているが、Unicode番号が5桁以上の文字(BMPに無い文字)を一律扱わない点が違う。
[編集] サロゲートペア
Unicodeは216＝65,536種類の文字を収録でき、当初の構想では世界中のすべての文字をこの16ビット固定長のコード体系に登録可能と思われていた。だが、Unicode 1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。その内容は中国、日本、台湾、ベトナム、シンガポールの追加漢字約1万5千字、古ハングル約5千字、未登録言語の文字等々である。このため、Unicodeの16ビット枠内に全世界の文字を収録するという計画は早々に破綻し、1996年、Unicode 2.0ではサロゲートペア (Surrogate Pair)の拡張が盛り込まれた。Surrogateは「代理」、Pairは「対（つい）」の意味。
サロゲートペアは16ビットUnicodeの未定義領域1024文字分を２つ使い（前半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ビットが混在する複雑な可変長文字コードとなってしまった。
なお、2000年にJIS漢字を拡張する目的でJIS X 0213（いわゆるJIS第3第4水準)が制定されたが、この際、新たに採用された文字でUnicodeに無かったものの一部は、BMP に収録できず、第2面への収録となった(最終対応は2002年）。このため、JIS X 0213収録文字を完全にサポートするにはサロゲートペアをサポートしたOS、フォント、アプリケーションが必要となる[7]。
サロゲートペアの方式は16ビット固定長を志向したUTF-16との互換性維持のために設けられた拡張であり、UTF-8符号化方式では利用されることはないが、多くのOS、アプリケーションは内部のエンコード方式にUTF-16を使用しているため、事実上、UTF-8で使用できる文字もサロゲートペアへの対応、非対応に拘束されることになる。
[編集] 歴史
- 1991年 - Unicode 1.0
- 1993年 - Unicode 1.1
- 1996年 - Unicode 2.0 ハングルの大移動、サロゲートペアの導入。
- ハングルの文字数が6656字から11172字へ増加され、1.xと互換性のない文字コード位置に移動した。
- 65536文字の制限を取り払い、収容可能な文字を大幅に増やした。
- 1998年 - Unicode 2.1
- 2000年 - Unicode 3.0 CJK統合漢字の拡張Aで漢字6582字を追加(2月)
- 2001年 - Unicode 3.1 BMP面以外の拡張。CJK統合漢字の拡張Bで漢字42711字を追加し、JIS X 0213一部対応 (3月23日)
- 2002年 - Unicode 3.2 JIS X 0213正式対応
- 2003年 - Unicode 4.0.0 （4月16日）
- 2005年 - Unicode 4.1.0 （3月31日）
- 2006年 - Unicode 5.0.0 （7月18日）
[編集] 日本語環境でのUnicodeの諸問題
- YEN SIGN問題
- Shift_JISではJIS X 0201における円記号(YEN SIGN)が0x5Cに置かれている。これをUnicodeのマッピングに合わせるとYEN SIGN(U+00A5)にマップされる。しかし、0x5CはASCIIではバックスラッシュに相当し、C言語などのエスケープシーケンスに使われる事から、この文字のコードを変更すると、コンパイルが通らない、動作に不具合が生じるなどの問題が起きる。そのためUnicodeを利用するアプリケーションは0x007F以下のコードに関しては移動させないと言う暗黙のルールができている。
- そうなると、Unicode環境では半角￥がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの0x5Cの位置には￥記号の字形を当ててしまうことで対処している（Windowsの場合）。これによって、それまでの文字コードを使用していたときと同じ感覚で￥を用いることができる。
- この問題は日本語環境に限った事ではない。もともと、ISO646上で0x5Cを含む数種の文字は自由領域（バリアント）として各国での定義を認めていた。そのため、諸外国でもASCIIでバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、大韓民国ではウォン記号である。
- WAVE DASH - FULLWIDTH TILDE問題
- JIS X 0208において、『0x2141(Shift_JISでは0x8160)』に割り当てられている『波線(〜)』を、MicrosoftはWindowsのShift_JIS⇔Unicode変換テーブルを作成する際にUnicodeにおける『FULLWIDTH TILDE＝全角チルダ＝U+FF5E(～)』に割り当てた。JIS X 0221規定のJIS X 0208⇔JIS X 0221対応表では『波線＝0x2141 (〜)』は『WAVE DASH＝波ダッシュ＝U+301C (〜)』に対応させており、不整合が生じる。アップル・コンピュータ等のJIS X 0221準拠のShift_JIS⇔Unicode変換テーブルをもつ処理系と、Windowsとの間でUnicodeデータをやり取りする場合、文字化けを起こすことになる。そこでWinodws以外のOS上で動くアプリケーションの中には、CP932という名前でMicrosoft仕様のShift_JISコード体系を別途用意して対応しているケースが多い[8]。
- ところで、なぜMicrosoftは『波線＝0x2141(〜)』を『FULLWIDTH TILDE＝全角チルダ＝U+FF5E(～)』に割り当てたのかというと、Unicodeの規格書におけるWAVE DASHの例示字形が、ふつうに使われている形、すなわち左からまず上に上がってから下に下がる形「／＼／」ではなく、左からまず下に下がってから上に上がる形「＼／＼」に定められたためではないかと思われる。ちなみにWindows Vista搭載のメイリオ、MSゴシック、MS明朝などの主要なフォントではWAVE DASHの字形は「／＼／」に改められている。
[編集] 一覧
[編集] 関連項目
[編集] 外部リンク
- 公式サイト
- DecodeUnicode - Unicode WIKI, 50.000 gifs
[編集] 脚注
- ↑ 現在、BMP面で規定されている領域のみの文字集合。この文字集合の範囲は、ISO/IEC 10646におけるUCS-2で定義される範囲と同一。
- ↑ ISO/IEC 10646におけるUCS-4は32ビットの文字集合であり、これとは別物。
- ↑ 例えば、CP51932とeucJP-MSのように既存文字コード同士でUnicodeとの対応が一部違う場合には文字化けが発生する等がある。
- ↑ もともと8ビットを基本とするUTF-8ではBOMを付与する必要はないが、UTF-8であることを示すフラグとしてファイル先頭に0xEF,0xBB,0xBFの3バイトが付与されることがある。Windowsのメモ帳では標準でBOMが付与される。
- ↑ ここでいうBOMはバイトオーダーを表すものではなく、UTF-16における「真の意味でのBOM」と類似する存在であるがゆえに慣用的にこう呼ばれているに過ぎない。
- ↑ BOMとは、8ビットを基本とするシステムでバイトオーダーを識別するためのフラグであり、ファイルの先頭に付与される。値は0xFEFF。システムが読み込んだ先頭2バイトがU+FFFEならリトルエンディアン、0xFEFFならビッグエンディアンとして後に続く文書を処理する。
RFC 2781 ではBOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Windowsのメモ帳では標準でBOMが付与されるようになっている。 - ↑ Shift_JIS等、Unicodeにて規定されるもの以外のエンコーディングを利用する場合であっても、JIS X 0213に対応するフォントやアプリケーションが必要なことは言うまでも無い。
- ↑ この副次効果により、Windows以外のシステムにおいてもシフトJISにて、NEC特殊文字やIBM拡張文字を扱うことが出来るようになる。
