Related Topics:
Unicode
Unicode(ユニコード)とは、コンピュータ上で多言語の文字を一つの文字コードで取り扱うために1980年代に提唱された文字コードである。ゼロックス社が提唱し、マイクロソフト、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られ、1991年にISOでもISO/IEC 10646の一部として標準化された。
世界の文字を共通の文字コードにしようということで作られ、NT系のMicrosoft Windows、Mac OS X、LinuxやJava言語などで基本的な文字コードとして利用されている。他の文字コード(符号化方式)との変換の整合性などでいくつかの問題も残る。
概要
もともと16ビット(基本多言語面)のみの文字集合を想定していたが、不足することがわかったため現在では拡張されている。
符号化方式として、
UTF-8、
UTF-16などがある。ISO/IEC 10646とは別の組織で標準化されているため、厳密には違うものであるが、互いに同じ内容になるよう標準化が進められている。Unicodeの1つのエンコード方式であるUTF-16では 65,536 - 2,048 + 65,536 * 16 = 約1,112,064文字が利用可能。
日本語ではJIS X 0208とJIS X 0212、Unicode 3.1でJIS X 0213の範囲の文字にほぼ対応。既存の文字コードとの相互変換も考慮されており、Unicode内で同じ文字として統合されている文字でも他の文字コードで区別されている場合には互換領域がとられ、Unicodeと他の文字コードとを変換しても文字化けが発生しないようになっている。ただし、CP51932とEUC-JP-MSのように既存文字コード同士でUnicodeとの対応が一部違う場合には文字化けなどが発生することもある。
基本多言語面(BMP)と呼ばれる16ビットで表現できる部分(プレーン)の標準化を終え、残りの16面(補助プレーン)の文字を選定中である。
- 0面 BMP U+xxxx
- 基本多言語面(Basic Multilingual Plane) - アルファベット、漢字など
- 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) - 外字
エンコード
UnicodeのUTFはUnicode Translation Formatの略。
- UTF-1
- 初期に提案されていた、8ビットコードによる方式。ほとんど利用されることなくUTF-8にとって代わられた。
- UTF-5
- 国際化ドメイン名での利用を想定し、0~9、A~Vの32文字でエンコードする方式。利用されていない。
- UTF-7
- 7ビットコードを組み合わせて文字を指定する方式。電子メールなどの7ビット文字しか利用できない場合を想定してつくられている。
- UTF-8 (UTF-2、UTF-FSS)
- 可変長の8ビットコードによりエンコードする方式。ASCIIと上位互換である、文字の境界が明確である、エンコード・デコードに際して乗除算などのコストの高い処理が必要ないなどの特長を持ち、もっとも一般的に利用されている。
- BOM(Byte Order Mark)がついているものをUTF-8、ついていないものをUTF-8Nとして区別することもある。
- UTF-16
- BMP面を16ビット、その他をサロゲートペアという仕組みを使い32ビットで指定する文字コード。Windows XPなどの近年のOSの内部コードには、この形式が使われている。UCS-2ともBMP面の範囲で互換性がある。
- ビッグエンディアンのものをUTF-16BE、リトルエンディアンのものをUTF-16BEとして区別することもある。
- UTF-32 (Unicode 3.1以降)
- Unicodeの全コードを単一長のコードとして32ビットで指定するコード。実際に使われるのは21ビット(Unicodeの空間がU+10FFFFまでであるため)。Unicodeの範囲内では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に関しては同名の規格が実際に検討されていたが、ドラフト段階で破棄されているため重複にはならないものと思われる。)
歴史
日本語環境でのUnicodeの諸問題
- YEN SIGN問題
- JIS X 0201における半角¥記号(0x5C)をUnicodeのマッピングに合わせるとYEN SIGN(U+00A5)にマップされる。しかし、0x5CはASCIIではバックスラッシュに相当し、C言語などのエスケープシーケンスに使われる事から、この文字のコードを変更すると、コンパイルが通らない、動作に不具合が生じるなどの問題が起きる。そのためUnicodeを利用するアプリケーションは0x007F以下のコードに関しては移動させないと言う暗黙のルールができている。
- そうなると、Unicode環境では半角¥がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの0x5Cの位置には¥記号の字形を当ててしまうことで対処している(Windowsの場合)。これによって、それまでの文字コードを使用していたときと同じ感覚で¥を用いることができる。
- この問題は日本語環境に限った事ではなく、諸外国でもASCIIでバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、大韓民国ではウォン記号である。
- WAVE DASH - FULLWIDTH TILDE問題
- Microsoft Windowsが、WAVE DASH(波線 / 波ダッシュ Shift_JIS 0x8160)を、本来割り当てるべきU+301C「〜」ではなく、FULLWIDTH TILDE(全角チルダ)のU+FF5E「~」に割り当てたことから生じる問題。「~」(FULLWIDTH TILDE) が環境によっては文字化けを起こす。アプリケーションでは、CP932と言うShift_JISのサブセットを作って対応しているケースが多い。
- おそらくこの問題は、Unicodeの規格書におけるWAVE DASHの例示字形が、ふつうに使われている形、すなわち左からまず上に上がってから下に下がる形「/\/」ではなく、左からまず下に下がってから上に上がる形「\/\」に定められたためではないかと思われる。Windowsの一般的なフォントでU+301Cを表示すると、この後者の形が表示される。一方、Mac OSではWAVE DASHを本来のU+301Cに割り当てるかわり、U+301CでもFULLWIDTH TILDEと同じ前者の曲線が表示される。
一覧
関連
外部リンク
Unicode
Unicode | Уникод | ইউনিকোড | Unicode | Unikod | Unicode | Unicode | Unicode | Unicode | Unicode | Unicode | Unikodo | Unicode | Unicode | Unicode | Unicode | Unicode | יוניקוד | यूनिकोड | Unicode | Unicode | Unicode | Unicode | უნიკოდი | ಯುನಿಕೋಡ್ | 유니코드 | यूनिकोड | Unicode | Unicode | Unikods | युनिकोड | Unicode | Unicode | Unicode | Unicode | Unicode | Unicode | Юникод | Unikod | Unicode | Unicode | Уникод | Unicode | யுனிகோடு | ยูนิโคด | Unicode | Юнікод | Unicode | Unicôde | Unicode | Thong-iōng-bé