Wikipediaサービス終了のお知らせUnicode▼人気記事ランキング��概要Unicode(ユニコード)は、符号化文字集合や文字符号化方式などを定めた、文字コードの業界規格である。文字集合(文字セット)が単一の大規模文字セットであること(「Uni」という名はそれに由来する)などが特徴である。行ったゼロックス社が提唱し、マイクロソフト、アップル、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られた。10646とUnicode規格は同じ文字コード表になるように協調して策定されている[1]。1]、Javaなどで利用されている。Unicode以前の文字コードとの相互運用性もある程度考慮されており、歴史上・実用上の識別が求められる場合には互換領域がとられ、元のコード→Unicode→元のコードというような変換(ラウンドトリップ変換)において、元通りに戻るよう配慮されている文字もある。0208の範囲内であればトラブルは少ないが、複数の文字集合が混在したり、Shift_JISの実態であるCP932やEUC-JPの亜種であるCP51932とeucJP-MSなど、対応が違うために文字化けを起こすことがある。Unicode文字符号化モデル[編集]文字コードは、Unicode文字符号化モデル[3]によると以下の4段階に分けられる。(CCS):抽象文字集合を非負整数に対応させたもの。抽象文字は複数の符号化文字に対応されることもある[5]。コンピュータ中に実際にデータとして文字を表現することを可能にする。文字符号化方式(CES):符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係する。その後バイト列を、gzipなどで圧縮したり、7ビット伝送路に通すためBase64、Quoted-printableなどで変換することがあるが、これらは文字コードの範囲外である。10FFFF16で111万4112符号位置がある[6]。2]が割り当てられ、65個を制御文字に使い、13万7468符号位置(12%)を私用文字として確保している。2048文字分をUTF-16のための代用符号位置に使用しており、加えて66の特別な符号位置は使われない。残りの83万6536符号位置(75%)は未使用である[7]。文字を特定する場合にはUnicode符号位置や一意につけられた名前が使われる。後に十六進法で符号位置を4桁から6桁続けることで表す。符号空間のうち代用符号位置を除く符号位置をUnicodeスカラ値という[8]。収録されている文字は、各国で標準として規定されている文字集合や実際に使用されている文字を持ち寄り、委員会により取捨選択されている。収録において、元の各文字集合内で分離されている文字は尊重するが、異なる文字集合に同一の文字が収録されているとみなされるものは、同じ符号位置に割り当てる方針を取っている。各規格の漢字を統合(英語版)しCJK統合漢字としたことは大きな議論となった。[編集]Unicodeでは文字符号化形式としてUTF-8、UTF-16、UTF-32の3種類が定められている。1符号単位は8ビットである。1符号単位は16ビットである。基本多言語面の文字を符号単位一つで、その他の文字をサロゲートペア(代用対)という仕組みを使い符号単位二つで表現する。1符号単位は32ビットである。Unicodeの符号空間がU+10FFFFまでであるため、実際に使われるのは21ビットまでである。文字符号化方式[編集]Unicodeでは文字符号化方式としてUTF-8、UTF-16、UTF-16BE、UTF-16LE、UTF-32、UTF-32BE、UTF-32LEの7種類が定められている。それぞれの符号化形式に対応する符号化方式は表の通り。文字符号化形式との違いは、文字符号化形式がプログラム内部で文字を扱う場合に符号なし整数として文字を表現する方法なのに対し、文字符号化方式は入出力時にバイト列として表現する方法である。UTF-8は符号単位が8ビットであるため区別する意味はない。BF(U+FEFFのUTF-8での表現)の3バイトが付与されることがある。UTF-8のBOMはバイト順を表すものではなく、UTF-16符号化方式等における「真の意味でのBOM」と同じコードポイントを利用しているがゆえに慣用的にこう呼ばれているに過ぎない。UTF-8でのBOMの使用は非推奨[9]。BOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Windowsのメモ帳で作成した「Unicodeテキスト」はBOMが付与されるようになっている。ビッグエンディアンの符号化方式をUTF-16BE、リトルエンディアンの符号化方式をUTF-16LEとして区別することもある。プロトコルもしくはアプリケーションの設定などの手段で符号化方式にUTF-16BEやUTF-16LEを指定している場合にはBOMを付与することは許容されない。Windows上の文書における「Unicodeテキスト」は特に明記のない場合、リトルエンディアンのUTF-16符号化方式のことを指す。TCP/IPネットワークでは、プロトコルヘッダやMIME等の手段で符号化方式が指定されずBOMも付与されない場合、ビッグエンディアンとして扱うと決められている。単純な符号化方式であるが、テキストファイルなどではファイルのサイズが大きくなる(すべてBMPの文字からなる文章の場合はUTF-16符号化方式の2倍、すべてASCII文字の場合はASCII/UTF-8の4倍のサイズとなる)ため、ストレージ用として使われることは稀である。符号化方式には対応していない。フリーウェア・シェアウェアのテキストエディタのうち多数の符号化方式に対応しているものでも、この符号化方式には対応していないものが存在する。すべてのUnicode文字を処理する場合には、すべての文字を単一の符号単位で表現したほうが処理に適するため、内部の処理ではUTF-32符号化形式(あるいはUCS-4)で扱うこともある。32ビット整数型である。UTF-16符号化方式などと同様にUTF-32符号化方式にもBOMがあり、データストリームの先頭に付される。FFならビッグエンディアンになる。UTF-16のリトルエンディアンとUTF-32のリトルエンディアンは最初の2バイトが等しいため、4バイトまで読んで判断する必要がある。UTF-9に関しては同名の規格が実際に検討されていた(ただし、内容は大きく異なる)が、ドラフト段階で破棄されているため重複にはならない。可変長の9ビット符号単位で表現する符号化方式。1バイトが8ビット(オクテット)ではなく9ビット(ノネット)であるような環境での利用を想定している。UTF-8と比較した場合、Latin-1領域が1バイト、CJK統合漢字領域が2バイトで表現できる特長があり、データ量が少なくなる。ワード長が9の倍数のコンピュータ(PDP-10やACOS-6など)であれば計算コストも低い。��UTF-18Unicode符号位置を単一の18ビット符号単位で表現する符号化方式。UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた4つの面(BMP、U+1xxxx、U+2xxxx、U+Exxxx)を余った2ビットで識別するため、代用符号位置は使わない。以下はドラフト段階で破棄された規格案。ドメイン名にはPunycodeが採用されたため、利用されていない。可変長(1-5バイト)の8ビット符号単位で表現する文字符号化形式または文字符号化方式。ISO-8859-1に対して一部互換である。UTF-8が普及しつつあり、それと比べて欠点がいくつかあったため、破棄された。個の符号位置に必要な全ての文字を収録する、というもくろみであった。1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。ベトナム、シンガポールの追加漢字約1万5千字、古ハングル約5千字、未登録言語の文字などである。2.0の時点で既に、文字集合の空間を16ビットから広げることが決まった。95のAPI)をなるべくそのままにしたまま、広げられた空間にある符号位置を表現する方法として、サロゲートペアが定義された。1,048,576文字を表す。U+10FFFF)の文字をこれで表すこととした。111万2,064文字分の空間が確保されたことになる。Unicodeの符号空間が10FFFF16まで(サロゲート領域を除いて111万2064文字)とされているのはUTF-16が表現可能な限界だからである。範囲を16ビットユニットのペア(2つ)で表現する集合で、最初の16ビットユニットを前半サロゲートもしくはハイサロゲート、二番目を後半サロゲートもしくはローサロゲートと称する。サロゲートペアはUTF-16でのみ使われ[10]、UTF-8、UTF-32ではすべての符号位置を符号化できるためこのような特別な処理は必要ない。0xDC00);となる。(下の棒が長い「吉」。エンコードを考えてみる。これを上位10ビット値と下位10ビット値に分割する。ハイ(高位)サロゲートを形成するために上位ビットに0xD800を加える。ロー(下位)サロゲートを形成するために下位ビットに0xDC00を加える。DF(UTF-16LEでの符号化バイト列)次の表は、この文字変換と他をまとめたものである。色は、コードポイントからのビットがUTF-16バイトにどのように分配されるかを示した。UTF-16エンコーディングプロセスによって追加された追加ビットは黒で示されている。面[編集]一つの面は6万5536個の符号位置がある。0213への対応を完了したのは2002年である)。0213収録文字をUnicodeで完全にサポートするには、追加漢字面をサポートしたOS、フォント、アプリケーションが必要となる。0213に対応するフォントやアプリケーションが必要である。常用漢字の2010年改定で追加された字のうち「𠮟」はU+20B9Fで、追加漢字面に含まれる。そのため、改定後の常用漢字完全サポートを謳う場合、Unicodeに対応していて更にこの拡張領域にも対応している必要があると言える。代用されることが多い。設置し、作業を始めていた。1980年代後半にはこの作業グループにおいてさまざまな提案が検討されている。10646第1版)では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。呼ばれるグループを別途設置し、そこで引き続き検討することにした。Collinsは、後にユニコードと呼ばれるようになる、世界中の文字を統一して扱える文字コードを開発していた。ここではその基本方針として、2オクテット(16ビット)固定長で全ての文字を扱えることを目指しており、そのために日本・中国・韓国の漢字を統一することで2万弱の漢字コードを入れ、さらに将来の拡張用に、3万程度の漢字の空き領域が別に用意されていた。Draftに賛同する企業によって、ユニコードコンソーシアムが設立された。10646とUnicodeの一本化が図られることになった。10646とUnicodeの一本化が図られることになった。Unicode用の統合漢字コード表を作成することになった。CJK-JRGの会合は第1回が7月22日から24日にかけて東京で、第2回の会合が9月17日から19日にかけて北京で、第3回が11月25日から29日にかけて香港で開催された。第1版として完成した。Vol.2が出版された。1992年、CJK統合漢字URO第二版が完成し、これを取り込んだ(ただし、UROには若干の間違いが発見されており、それらの修正が行われている。10646第2版が、5月30日の国際投票で可決された。Plane」が制定される。10646とは歩調を合わせて改訂されていくことになる。3つの部分から構成され、ピリオドでつなげて表示される[12]。マイナーバージョン及びアップデートバージョンについては0の場合には省略して表示されることもある。メジャーバージョンはレパートリーの追加のような重要な変更が行われたときに改定される。ユニコードのドキュメントは書籍形態と電子版ドキュメント形態の両方で公表され、どちらもユニコードについての正式なドキュメントであるとされている。新たなバージョンがリリースされたときは新たなドキュメントが公表されるが、書籍として刊行されるのはメジャーバージョンが改定された場合および重要なマイナーバージョンの改定があった場合のみである。書籍版のバージョン1.0は、2巻に分けて刊行され、統合漢字部分を除いた第1巻は1991年10月に、統合漢字部分の第2巻は1992年6月に刊行された。1.0.1と呼ぶことがある。特徴は以下の通りである。構成要素のバージョン[編集]ユニコードのバージョンには、上記のような「ユニコードの規格全体に付けられたバージョン」の他に「ユニコードを構成する個々の要素の規格に付けられたバージョン」が存在する。Standard(Unicode技術標準)のバージョンなどが存在する。Unicodeの諸問題[編集]バージョンごとの非互換性[編集]Unicodeは同一のコードでもバージョンが変わったとき完全に異なった文字を定義し直したことがある。2.0での「ハングルの大移動」である。1.1までで定義されていたハングルの領域を破棄し、新しいハングルの領域を別の位置に設定し、破棄された領域には別の文字の領域を割り当てることとなった。4.0で六十四卦が割り当てられた。2.0以降でCJK統合漢字拡張Aを記述した文書には互換性がない[293]。JCS委員長の芝野耕司はUnicodeに日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている[294]。