ITパスポート試験 用語辞典

ITパスポート試験合格コース
シラ外
ゆにこーど
Unicode
世界の主要な言語で使われている文字を共通の文字集合で表現することを目指した文字コード体系で、1文字を2バイト以上で表現する。
↓ 用語データを見る
分野:
分野:テクノロジ系
中分類:基礎理論
小分類:情報に関する理論
出題歴:
H25年春期問78 
重要度:
(Wikipedia Unicodeより)

Unicode(ユニコード)とは、符号化文字集合や文字符号化方式などを定めた、文字コードの業界規格である。文字集合(文字セット)が単一の大規模文字セットであること(「Uni」という名はそれに由来する)などが特徴である。

1980年代に、Starワークステーションの日本語化 (J-Star) などを行ったゼロックス社が提唱し、マイクロソフト、、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られた。1993年に、国際標準との一致が図られ、DIS 10646の当初案から大幅に変更されて、Unicodeと概ね互換のISO/IEC 10646が制定された。

概要

Unicode は世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られ、Unix、Windows、Mac OS X、Plan 9、Javaなどで利用されている。

Unicodeでは、文字集合中の文字をあらわす符号位置(コードポイント、符号点を参照)に、「Unicodeスカラ値」という非負整数値が割り振られている。Unicodeスカラ値は "U+" の後に十六進法でその値を続けることで表す。BMP内の符号位置は U+0000 〜 U+FFFF の4桁で表すことができ、SMP以降は5桁または6桁を必要とする。

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

また収録において、元の各文字集合内で分離されている文字は尊重するが、異なる文字集合に同一の文字が収録されているとみなされるものは、同じ符号位置に割り当てる方針を取っている。この際に集合が膨大であるという理由で、漢字について、中国、日本、韓国の各規格のしCJK統合漢字としたことは大きな議論となった。

Unicodeでは文字符号化方式も標準化したため、従来見られたShift JISとEUC-JPとの間の混乱のようなものは回避されている。

Unicode以前の文字コードとの相互運用性もある程度考慮されており、歴史上・実用上の識別が求められる場合には互換領域がとられ、元のコード→Unicode→元のコードというような変換(ラウンドトリップ変換)において、元通りに戻るよう配慮されている文字もある。しかし、正規のJIS X 0208の範囲内であればトラブルは少ないが、複数の文字集合が混在したり、Shift JISの実態であるCP932やEUC-JPの亜種であるCP51932とeucJP-MSなど、対応が違うために文字化けを起こすことがある。

文字符号化スキーム

ISO/IEC 10646#文字符号化方式
Unicodeでは文字符号化方式を「文字符号化スキーム」(Character Encoding Scheme) と言う。
UTF-7

UTF-7

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

UTF-8

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

UTF-16

BMP文字を16ビット符号単位一つで、その他の文字をサロゲートペア(代用対)という仕組みを使い16ビット符号単位二つで表現する文字符号化形式及び文字符号化スキーム。Windows XPなどの近年のOSの内部では、UTF-16符号化形式が使われている。UCS-2ともBMPの範囲で互換性がある。
UTF-16符号化スキームでは、通常はファイルの先頭にバイト順マーク (BOM) が付与される。BOMとは、通信やファイルの読み書き等、8ビット単位の処理でバイト順を識別するための印であり、データストリームの先頭に付与される。値はU+FEFF。システムが読み込んだ先頭2バイトが0xFF, 0xFEならリトルエンディアン、0xFE, 0xFFならビッグエンディアンとして後に続く文書を処理する。
RFC 2781 ではBOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Windowsのメモ帳で作成した「Unicodeテキスト」はBOMが付与されるようになっている。ビッグエンディアンの符号化スキームをUTF-16BE、リトルエンディアンの符号化スキームをUTF-16LEとして区別することもある。プロトコル若しくはアプリケーションの設定などの手段で符号化スキームにUTF-16BEUTF-16LEを指定している場合にはBOMを付与することは許容されない(ZERO WIDTH NON-BREAKING SPACEとして扱う)。Windows上の文書における「Unicodeテキスト」は特に明記のない場合、リトルエンディアンのUTF-16符号化スキームのことを指す。TCP/IPネットワークではプロトコルヘッダやMIME等の手段で符号化スキームが指定されずBOMも付与されない場合、ビッグエンディアンに決められている(→ エンディアン)。
UTF-32

UTF-32

Unicodeのすべての符号位置を単一長の符号単位として32ビットで表現する文字符号化形式及び文字符号化スキーム。実際に使われるのは21ビット(Unicodeの符号空間がU+10FFFFまでであるため)。この21ビットの範囲内ではUCS-4と互換性がある。UTF-32符号化スキームでもUTF-16符号化スキームと同じく、ビッグエンディアンとリトルエンディアンが存在し、それぞれUTF-32BEUTF-32LEと呼ばれる。プロトコル若しくはアプリケーションの設定などの手段で符号化スキームにUTF-32BEUTF-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である (RFC 4042)。UTF-9に関しては同名の規格が実際に検討されていたが、ドラフト段階で破棄されているため重複にはならない。

UTF-9
可変長の9ビット符号単位で表現する符号化方式。1バイトが8ビット(オクテット)ではなく9ビット(ノネット)であるような環境での利用を想定している。UTF-8と比較した場合、Latin-1領域が1バイト、CJK統合漢字領域が2バイトで表現できる特長があり、データ量が少なくなる。ワード長が9の倍数のコンピュータ(PDP-10やACOS-6など)であれば計算コストも低い。
UTF-18
Unicode符号位置を単一の18ビット符号単位で表現する符号化方式。UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた4つの面を余った2ビットで識別するため、代用符号位置は使わない。

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

UTF-5
国際化ドメイン名での利用を想定し、0-9、A-Vの32文字で表現する文字符号化スキーム。国際化ドメイン名にはPunycodeが採用されたため、利用されていない。
UTF-9
可変長コード(1-5バイト)の8ビット符号単位で表現する文字符号化形式または文字符号化スキーム。ISO-8859-1に対して一部互換である。しかし、UTF-8が普及しつつあり、それと比べて欠点がいくつかあったため、破棄された。

拡張領域

サロゲートペア

1980年代の当初の構想では、Unicodeは16ビット固定長で、216 = 65,536 個の符号位置に必要な全ての文字を収録する、というもくろみであった。しかし、Unicode 1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。その内容は中国、日本、台湾、ベトナム、シンガポールの追加漢字約1万5千字、古ハングル約5千字、未登録言語の文字等々である。このようにしてUnicodeの、16ビットの枠内に全世界の文字を収録するという計画は早々に破綻し、1996年のUnicode 2.0の時点で既に、文字集合の空間を16ビットから広げることが決まった。この時、それまでの16ビットを前提としたシステム(たとえばJavaのchar型)をなるべくそのままに、広げられた空間にある符号位置を表現する方法として、サロゲートペアが定義された。

サロゲートペアは16ビットUnicodeの領域1024文字分を2つ使い(前半 U+D800 〜 U+DBFF、後半 U+DC00 〜 U+DFFF)、各々1個ずつからなるペアで1024 × 1024 = 1,048,576文字を表す。これは丁度16面ぶんであり、第1面〜第16面(U+10000 〜 U+10FFFF)の文字をこれで表すこととした。加えて第0面(基本多言語面)も使用可能なので、Unicodeには合計で 1,048,576 + 65,536 - 2,048 = 111万2,064文字ぶんの空間が確保されたことになる。

サロゲートはUnicodeの符号位置の U+10000..U+10FFFF の範囲を16ビットユニットのペア(2つ)で表現する集合で、最初の16ビットユニットは high surrogate で、二番目は low surrogate となる。high surrogates は U+D800..U+DBFF の範囲、low surrogates は U+DC00..U+DFFF の範囲である。

サロゲートのエンコーディングは、

        $hi = ($uni - 0x10000) / 0x400 + 0xD800;
        $lo = ($uni - 0x10000) % 0x400 + 0xDC00;

デコードは、
        $uni = 0x10000 + ($hi - 0xD800) * 0x400 + ($lo - 0xDC00);

厳密には正確ではないが、UTF-16はUCS-2をサロゲートペアで拡張したようなものであると言える。またUnicodeは(現在のところ)UCS-4のうち、サロゲートペアで表現可能な空間のみを使うものとし(異体字セレクタなどは空間を別の軸の向きに広げるものとされている)ISO/IEC 10646もUnicodeに追随するような形で改訂されている。

サロゲートペアによって拡張された符号位置は、UTF-32ではそのまま表現できる。UTF-8では、通常4オクテット使って表現される。UTF-16ではサロゲートペアを使って表現する。UTF-8を使っているが4オクテット以上のオクテット列を扱えない、といった場合に、サロゲートペアをそのままUTF-8で表現したような表現が使われることがあり、CESU-8と言う(詳しくはUTF-8#サロゲートペアの扱いを参照)。

サロゲートペア (Surrogate Pair) の日本語訳は代用対とされている。

拡張領域に含まれる文字

現在第1面はSupplementary Multilingual Plane(SMPと略される。追加多言語面。主に古代文字が収録されている)、第2面はSupplementary Ideographic Plane(SIP、追加漢字面。漢字専用領域)、第14面はSupplementary Special-purpose Plane(SSP、追加特殊用途面。制御コード専用領域)、第15面および第16面は私用面(BMPのU+E000-U+F8FFの領域の拡張)と決められている。また、第3面はTertiary Ideographic Plane(直訳すると第三の漢字面)で、2009年3月現在では1字も収録されていないが、古代漢字や甲骨文字が収録される予定である。

第4面-第13面は未使用で将来どのような目的で使用するのかすら決まっていない。

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

常用漢字の2010年改定で追加された字のうち「𠮟」はU+20B9Fで追加漢字面に含まれる。そのため、改定後の常用漢字完全サポートを謳う場合、Unicodeに対応していて更にこの拡張領域にも対応している必要があると言える。ただ、現状ではこの字はJIS X 0208にも含まれていて、基本多言語面に含まれる異体字の「叱」(U+53F1) で代用されることが多い。

出題例

世界の主要な言語で使われている文字を一つの文字コード体系で取り扱うための規格はどれか。

[出典]ITパスポート 平成25年春期 問78

  • ASCII
  • EUC
  • SJIS(シフトJIS)
  • Unicode
正解 

「情報に関する理論」の用語

「基礎理論」の他の分野

「テクノロジ系」の他のカテゴリ

このページのWikipediaよりの記事は、ウィキペディアの「Unicode」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。


Pagetop