前のページ 1/8 次のページ

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

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

◆ 概要

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

元々16ビットの文字集合で全ての文字の網羅を目指して開発されたが、符号位置[外部リンク] Unicode Terminology English - Japanese, C, Unicode, inc.が圧倒的に足りず、Unicode 2.0以降では21ビットの文字集合として規定されている。現在のUnicodeの空間はU+0000〜U+10FFFFである。当初の16ビットの領域であるU+0000〜U+FFFFは、Unicode 2.0以降では基本多言語面 (BMP) と呼ばれ、ISO/IEC 10646においてUCS-2で定義される16ビットの範囲と同一である。一方、ISO/IEC 10646におけるUCS-4は31ビットの文字集合であり、21ビットのUnicodeとは別物である。

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

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

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

Unicodeの文字を表現する場合、"U+"にその文字の符号位置を表す16進数を続けた文字列を使って表す。BMPの場合は4桁、それ以上では必要に応じて5、6桁で表す。この符号位置を表す整数値をUnicodeスカラ値[外部リンク] Unicode Terminology English - Japanese, U, Unicode, inc.と言う。

◆ 文字集合

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

◆ エンコーディング(符号化方式)

; UTF-7

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

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

: 可変長(1〜4バイト)の8ビット符号単位で表現する文字符号化形式及び文字符号化スキーム。ASCIIに対して上位互換となっており、文字の境界が明確である、UTF-16符号化スキームやUTF-32符号化スキームとの変換・逆変換に際して乗除算などの負荷の高い処理が必要ないなどの特長を持ち、インターネットではもっとも一般的に利用されている。

:UTF-8符号化スキームについて、日本国内でのみバイト順マーク[外部リンク] Unicode Terminology English - Japanese, B, Unicode, inc. (BOM) がついているものをUTF-8、ついていないものをUTF-8Nとして区別することがあるが、国際的には認知されていない。もともと8ビットを符号単位とするUTF-8ではBOMを付与する必要はないが、UTF-8であることが識別できるようにデータストリームの先頭に EF BB BF (U+FEFFのUTF-8での表現) の3バイトが付与されることがある。Windowsのメモ帳で作成した「Unicodeテキスト」にはBOMが付与される。Internet Explorerでは、BOMのついていないUTF-8の文書を読み込むと(日本語版の場合)Shift_JISだと誤認する一方で、BOMがついていると有効なデータとして受け付けないアプリケーションも存在する。UTF-8のBOMはバイト順を表すものではなく、UTF-16符号化スキーム等における「真の意味でのBOM」と類似する存在であるがゆえに慣用的にこう呼ばれているに過ぎない。

; UTF-16

: BMP文字を16ビット符号単位一つで、その他の文字を(代用対[外部リンク] Unicode Terminology English - Japanese, S, Unicode, inc.)という仕組みを使い16ビット符号単位二つで表現する文字符号化形式及び文字符号化スキーム。Windows XPなどの近年のOSの内部では、UTF-16符号化形式が使われている。UCS-2ともBMPの範囲で互換性がある。

: UTF-16符号化スキームでは、通常はファイルの先頭にバイト順マーク (BOM) が付与される。BOMとは、通信やファイルの読み書き等、8ビット単位の処理でバイト順を識別するための印であり、データストリームの先頭に付与される。値はU+FEFF。システムが読み込んだ先頭2バイトが0xFF,0xFEならリトルエンディアン、0xFE,0xFFならビッグエンディアンとして後に続く文書を処理する。

前のページ 1/8 次のページ

・Unicode page1

・Unicode page2

・Unicode page3

・Unicode page4

・Unicode page5

・Unicode page6

・Unicode page7

・Unicode page8