Unicode

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

従来、各国の標準化団体あるいは各コンピュータメーカーによって独自に開発されていた個々の文字コードの間には互換性がなかった。ISO/IEC 2022のように複数の文字コードを共存させる方法も考案されたが、例えば日本語の漢字と中国語の漢字のように、文字が重複する短所がある。一方Unicodeは、微細な差異はあっても本質的に同じ文字であれば一つの番号を当てる方針で各国・各社の文字コードの統合を図った規格である。1980年代に、Starワークステーションの日本語化（J-Star）などを行ったゼロックスが提唱し、マイクロソフト、Apple、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られた。国際規格のISO/IEC 10646とUnicode規格は同じ文字コード表になるように協調して策定されている。

概要

Unicodeは世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られ、Unix、Windows、macOS、Plan 9テンプレート:Efnなどの様々なオペレーティングシステムでサポートされている。Javaや.NETのようなプログラミング環境でも標準的にサポートされている。現代の文字だけでなく古代の文字や歴史的な文字、数学記号、絵文字なども含む。

Unicode以前の文字コードとの相互運用性もある程度考慮されており、歴史上・実用上の識別が求められる場合には互換領域がとられ、元のコード→Unicode→元のコードというような変換（ラウンドトリップ変換）において、元通りに戻るよう配慮されている文字もある。しかし、正規のJIS X 0208の範囲内であればトラブルは少ないが、複数の文字集合が混在していたり、文字集合の亜種ごとにマッピング（対応づけ）が異なる文字（機種依存文字）を含んでいたりする場合テンプレート:Efn、変換テーブルによるマッピングが不可逆変換となり文字化けを起こすことがある。

Unicode文字符号化モデル

文字コードは、Unicode文字符号化モデルによると以下の4段階に分けられる：

テンプレート:Visible anchor (テンプレート:Abbr)

符号化の対象とする順序のない文字の集合。

テンプレート:Visible anchor (テンプレート:Abbr)

抽象文字集合を非負整数に対応させたもの。この非負整数の範囲を符号空間、各値を符号位置 (コードポイント) といい、抽象文字は対応後、符号化文字となる。抽象文字は複数の符号化文字に対応されることもある。

テンプレート:Visible anchor (テンプレート:Abbr)

符号化文字集合の非負整数を符号単位列に変換する方法。文字符号化形式はコンピュータ中に実際にデータとして文字を表現することを可能にする。

テンプレート:Visible anchor (テンプレート:Abbr)

符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係する。

その後、バイト列を、gzipなどで圧縮したり、7ビット伝送路に通すためにBase64やQuoted-printableなどで変換したりすることがあるが、これらは文字コードの管轄範囲外である。

文字集合

テンプレート:下付き文字 Unicodeの文字集合の符号空間は0 - 10FFFF₁₆で111万4,112の符号位置がある。Unicode 16.0（2024年9月10日公表）では15万4,998個1 (13.9%) の文字テンプレート:Efnが割り当てられ、65個を制御文字に使い、15万4,537符号位置 (13.8%) を私用文字として確保している。また、2,048文字分をUTF-16のための代用符号位置に使用しており、加えて66の特別な符号位置は使われない。残りの80万2,463符号位置 (72%) は未使用である。

文字を特定する場合にはUnicode符号位置や一意につけられた名前が使われる。例えば、アルファベット小文字の「a」はU+0061 (LATIN SMALL LETTER A)、八分音符「♪」はU+266A (EIGHTH NOTE) である。Unicode符号位置を文章中などに記す場合は "U+" の後に十六進法で符号位置を4桁から6桁続けることで表す。また、符号空間のうち代用符号位置を除く符号位置をUnicodeスカラ値という。

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

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

現在では独自創作の絵文字の追加等、当初の目的である「各国・各社の文字コードの統合」から外れた動きも進んでいる。

Unicodeに収録されている文字については、「ブロックの一覧」を参照。

文字符号化形式

テンプレート:特殊文字 Unicodeでは文字符号化形式としてUTF-8、UTF-16、UTF-32の3種類が定められている。

UTF-8は1符号化文字を1〜4符号単位で表す可変幅文字符号化形式で、1符号単位は8ビットである。

UTF-16は1符号化文字を1〜2符号単位で表す可変幅文字符号化形式で、1符号単位は16ビットである。基本多言語面の文字を符号単位一つで、その他の文字をサロゲートペア（代用対）という仕組みを使い符号単位二つで表現する。

UTF-32は1符号化文字を1符号単位で表す固定幅文字符号化形式で、1符号単位は32ビットである。ただし、Unicodeの符号空間がU+10FFFFまでであるため、実際に使われるのは21ビットまでである。

各文字符号化形式の符号化例

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
UTF-8	A	Ω		語			😊
	41	CE	A9	E8	AA	9E	F0	9F	98	8A
UTF-16	A		Ω		語		😊
	0041		03A9		8A9E		D83D		DE0A
UTF-32	A				Ω				語				😊
	00000041				000003A9				00008A9E				0001F60A

文字符号化方式

文字符号化形式 (CEF)	文字符号化方式 (CES)
UTF-8	UTF-8
UTF-16	UTF-16
	UTF-16BE
	UTF-16LE
UTF-32	UTF-32
	UTF-32BE
	UTF-32LE

Unicodeでは文字符号化方式としてUTF-8、UTF-16、UTF-16BE、UTF-16LE、UTF-32、UTF-32BE、UTF-32LEの7種類が定められている。それぞれの符号化形式に対応する符号化方式は表の通り。

文字符号化形式との違いは、文字符号化形式がプログラム内部で文字を扱う場合に符号なし整数として文字を表現する方法なのに対し、文字符号化方式は入出力時にバイト列として表現する方法である。UTF-8は符号単位が8ビットであるため区別する意味はない。

文字符号化方式 (CES)	エンディアン	BOMの付与
UTF-8	テンプレート:N/a	テンプレート:Yes2
UTF-16	ビッグ/リトル	テンプレート:Yes2
UTF-16BE	ビッグエンディアン	テンプレート:No2
UTF-16LE	リトルエンディアン	テンプレート:No2
UTF-32	ビッグ/リトル	テンプレート:Yes2
UTF-32BE	ビッグエンディアン	テンプレート:No2
UTF-32LE	リトルエンディアン	テンプレート:No2

UTF-8

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

なお、UTF-8はもともと8ビットを符号単位とするためバイト順マーク（BOM；後述）は必要ないが、UTF-8であることが識別できるよう、データストリームの先頭に EF BB BF（U+FEFFのUTF-8での表現）の3バイトが付与されることがある。UTF-8のBOMはバイト順を表すものではなく、UTF-16符号化方式等における「真の意味でのBOM」と同じコードポイントを利用しているがゆえに慣用的にこう呼ばれているに過ぎない。UTF-8でのBOMの使用は非推奨。

UTF-16

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

テンプレート:IETF RFC ではBOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Microsoft Windowsのメモ帳で作成した「Unicodeテキスト」はBOMが付与されるようになっている。ビッグエンディアンの符号化方式をUTF-16BE、リトルエンディアンの符号化方式をUTF-16LEとして区別することもある。プロトコルもしくはアプリケーションの設定などの手段で符号化方式にUTF-16BEやUTF-16LEを指定している場合にはBOMを付与することは許容されない。Windows上の文書における「Unicodeテキスト」は特に明記のない場合、リトルエンディアンのUTF-16符号化方式のことを指す。TCP/IPネットワークでは、プロトコルヘッダやMIME等の手段で符号化方式が指定されずBOMも付与されない場合、ビッグエンディアンとして扱うと決められている。

UTF-32

UTF-32符号化方式でもUTF-16符号化方式と同じく、ビッグエンディアンとリトルエンディアンが存在し、それぞれUTF-32BE、UTF-32LEと呼ばれる。プロトコルもしくはアプリケーションの設定などの手段で符号化方式にUTF-32BEやUTF-32LEを指定している場合にはBOMを付与することは許容されない。

単純な符号化方式であるが、テキストファイルなどではファイルのサイズが大きくなる（すべてBMPの文字からなる文章の場合はUTF-16符号化方式の2倍、すべてASCII文字の場合はASCII/UTF-8の4倍のサイズとなる）ため、ストレージ用として使われることは稀である。そのためか、Microsoft Officeでの「エンコードされたテキストファイル」の読み書きでは、Office 2016 でもいまだに符号化方式には対応していない。フリーウェア・シェアウェアのテキストエディタのうち多数の符号化方式に対応しているものでも、この符号化方式には対応していないものが存在する。

ただし、すべてのUnicode文字を処理する場合には、すべての文字を単一の符号単位で表現したほうが処理に適するため、内部の処理ではUTF-32符号化形式（あるいはUCS-4）で扱うこともある。実例として、Linux 上のC言語環境では wchar_t は32ビット整数型である。

UTF-16符号化方式などと同様にUTF-32符号化方式にもBOMがあり、データストリームの先頭に付される。先頭の4バイトがFF FE 00 00ならリトルエンディアン、00 00 FE FFならビッグエンディアンになる。UTF-16のリトルエンディアンとUTF-32のリトルエンディアンは最初の2バイトが等しいため、4バイトまで読んで判断する必要がある。

各文字符号化方式の符号化例

UTF-8	A	Ω		語			😊
	41	CE	A9	E8	AA	9E	F0	9F	98	8A
UTF-16BE	A		Ω		語		😊
	00	41	03	A9	8A	9E	D8	3D	DE	0A
UTF-16LE	A		Ω		語		😊
	41	00	A9	03	9E	8A	3D	D8	0A	DE
UTF-32BE	A				Ω				語				😊
	00	00	00	41	00	00	03	A9	00	00	8A	9E	00	01	F6	0A
UTF-32LE	A				Ω				語				😊
	41	00	00	00	A9	03	00	00	9E	8A	00	00	0A	F6	01	00

その他

UTF-7

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

以下はエイプリルフールに公開されたジョークRFCである (テンプレート:IETF RFC)。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つの面（BMP、U+1xxxx、U+2xxxx、U+Exxxx）を余った2ビットで識別するため、代用符号位置は使わない。

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

UTF-5

国際化ドメイン名での利用を想定し、0-9、A-Vの32文字で表現する文字符号化方式。国際化ドメイン名にはPunycodeが採用されたため、利用されていない。

UTF-9

可変長（1-5バイト）の8ビット符号単位で表現する文字符号化形式または文字符号化方式。ISO-8859-1に対して一部互換である。しかし、UTF-8が普及しつつあり、それと比べて欠点がいくつかあったため、破棄された。

拡張領域

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

サロゲートペア

サロゲートペア（代用対）は16ビットUnicodeの領域1,024文字分を2つ使い（前半 U+D800 〜 U+DBFF、後半 U+DC00 〜 U+DFFF）、各々1個ずつからなるペアで1,024 × 1,024 = 1,048,576文字を表す。これはちょうど16面分であり、第1面〜第16面（U+010000 〜 U+10FFFF）の文字をこれで表すこととした。加えて第0面（基本多言語面）も使用可能なので、Unicodeには合計で 1,048,576 + 65,536 - 2,048 = 111万2,064文字分の空間が確保されたことになる。Unicodeの符号空間が10FFFF₁₆まで（サロゲート領域を除いて111万2,064文字）とされているのはUTF-16が表現可能な限界だからである。

サロゲートはUnicodeの符号位置の U+010000 〜 U+10FFFF の範囲を16ビットユニットのペア（2つ）で表現する集合で、最初の16ビットユニットを前半サロゲートもしくはハイサロゲート、二番目を後半サロゲートもしくはローサロゲートと称する。ハイサロゲートは U+D800 〜 U+DBFF の範囲、ローサロゲートは U+DC00 〜 U+DFFF の範囲である。

サロゲートペアはUTF-16でのみ使われ、UTF-8、UTF-32ではすべての符号位置を符号化できるためこのような特別な処理は必要ない。

コーディング

サロゲートのエンコーディングは、符号位置を $CP$、ハイサロゲートを $HSG$、ローサロゲートを $LSG$ とすると次の通りに計算する。

$HSG=\mathrm{f}\mathrm{l}\mathrm{o}\mathrm{o}\mathrm{r}\left(\frac{CP-10000_{16}}{400_{16}}\right)+{\mathrm{D}\mathrm{8}\mathrm{0}\mathrm{0}}_{16}$

$LSG=(CP-10000_{16})mod400_{16}+{\mathrm{D}\mathrm{C}\mathrm{0}\mathrm{0}}_{16}$

デコーディングは、

$CP=10000_{16}+(HSG-{\mathrm{D}\mathrm{8}\mathrm{0}\mathrm{0}}_{16})\times 400_{16}+(LSG-{\mathrm{D}\mathrm{C}\mathrm{0}\mathrm{0}}_{16})$

である。

コード変換例

「𠮷テンプレート:Efn」U+20BB7 のエンコードを考えてみる。

$0010000010{1110110111}_2({\mathrm{2}\mathrm{0}\mathrm{B}\mathrm{B}\mathrm{7}}_{16})$ から

$00010000000000000000_2(10000_{16})$ を引くと、結果は

$0001000010{1110110111}_2({\mathrm{1}\mathrm{0}\mathrm{B}\mathrm{B}\mathrm{7}}_{16})$ となる。

これを上位10ビット値と下位10ビット値に分割する。

${0001000010}_2({0042}_{16}),{1110110111}_2({\mathrm{0}\mathrm{3}\mathrm{B}\mathrm{7}}_{16})$

ハイ（上位）サロゲートを形成するために上位ビットに ${\mathrm{D}\mathrm{8}\mathrm{0}\mathrm{0}}_{16}$を加える。

${0001000010}_2({0042}_{16})+1101100000000000_2({\mathrm{D}\mathrm{8}\mathrm{0}\mathrm{0}}_{16})=110110{0001000010}_2({\mathrm{D}\mathrm{8}\mathrm{4}\mathrm{2}}_{16})$

ロー（下位）サロゲートを形成するために下位ビットに ${\mathrm{D}\mathrm{C}\mathrm{0}\mathrm{0}}_{16}$ を加える。

${1110110111}_2({\mathrm{0}\mathrm{3}\mathrm{B}\mathrm{7}}_{16})+1101110000000000_2({\mathrm{D}\mathrm{C}\mathrm{0}\mathrm{0}}_{16})=110111{1110110111}_2({\mathrm{D}\mathrm{F}\mathrm{B}\mathrm{7}}_{16})$

結果

${\mathrm{D}\mathrm{8}\mathrm{4}\mathrm{2}}_{16},{\mathrm{D}\mathrm{F}\mathrm{B}\mathrm{7}}_{16}$ (UTF-16 符号単位列)

${\mathrm{D}\mathrm{8}}_{16},{\mathrm{4}\mathrm{2}}_{16},{\mathrm{D}\mathrm{F}}_{16},{\mathrm{B}\mathrm{7}}_{16}$(UTF-16BEでの符号化バイト列)

${\mathrm{4}\mathrm{2}}_{16},{\mathrm{D}\mathrm{8}}_{16},{\mathrm{B}\mathrm{7}}_{16},{\mathrm{D}\mathrm{F}}_{16}$(UTF-16LEでの符号化バイト列)

次の表は、この文字変換と他をまとめたものである。 色は、コードポイントからのビットがUTF-16バイトにどのように分配されるかを示した。 なお、UTF-16エンコーディングプロセスによって追加された追加ビットは黒で示されている。

文字 （符号位置）		符号位置(2進数)	UTF-16 符号単位列(2進数)	UTF-16 符号単位列	UTF-16BE 符号化バイト列	UTF-16LE 符号化バイト列
$	U+0024	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color
€テンプレート:Efn	U+20AC	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color	テンプレート:Font color
𠮷テンプレート:Efn	U+20BB7	テンプレート:Font colorテンプレート:Font color	1101 10テンプレート:Font color 1101 11テンプレート:Font color	テンプレート:Font color テンプレート:Font color	テンプレート:Font color テンプレート:Font color	テンプレート:Font color テンプレート:Font color
最大値	U+10FFFF	テンプレート:Font colorテンプレート:Font color	1101 10テンプレート:Font color 1101 11テンプレート:Font color	テンプレート:Font color テンプレート:Font color	テンプレート:Font color テンプレート:Font color	テンプレート:Font color テンプレート:Font color

面

一つの面は6万5536個の符号位置がある。

面	符号位置	英語での名称	略称	日本語での名称	収録されている主な文字
第0面	U+0000 - U+FFFF	Basic Multilingual Plane	BMP	基本多言語面	基本的な文字。
第1面	U+10000 - U+1FFFF	Supplementary Multilingual Plane	SMP	追加多言語面	古代文字や記号・絵文字類など。
第2面	U+20000 - U+2FFFF	Supplementary Ideographic Plane	SIP	追加漢字面	漢字専用領域。
第3面	U+30000 - U+3FFFF	Tertiary Ideographic Plane	TIP	第三漢字面	追加漢字面に入りきらなかった漢字。また、将来的には古代漢字や甲骨文字などが収録される予定テンプレート:Efn。
第4面	U+40000 - U+4FFFF	未使用（将来どのような目的で使用するのかすら決まっていない）。
第5面	U+50000 - U+5FFFF
第6面	U+60000 - U+6FFFF
第7面	U+70000 - U+7FFFF
第8面	U+80000 - U+8FFFF
第9面	U+90000 - U+9FFFF
第10面	U+A0000 - U+AFFFF
第11面	U+B0000 - U+BFFFF
第12面	U+C0000 - U+CFFFF
第13面	U+D0000 - U+DFFFF
第14面	U+E0000 - U+EFFFF	Supplementary Special-purpose Plane	SSP	追加特殊用途面	制御コード専用領域。
第15面	U+F0000 - U+FFFFF	Private Use Plane	PUP	私用面	BMPの U+E000 - U+F8FF の領域の拡張。
第16面	U+100000 - U+10FFFF

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

常用漢字の2010年改定で追加された字のうち「テンプレート:JIS2004フォント」はU+20B9Fで、追加漢字面に含まれる。そのため、改定後の常用漢字完全サポートを謳う場合、Unicodeに対応していて更にこの拡張領域にも対応している必要があると言える。ただ、現状ではこの字は、JIS X 0208に含まれる（＝当然、Unicode策定当初からBMPに収録されている）異体字の「叱」(U+53F1) で代用されることが多い。

歴史

1984年、ISOの文字コード規格委員会 (ISO/TC 97/SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える文字コード規格 (ISO 10646) を作成することを決定し、専門の作業グループ (ISO/TC 97/SC 2/WG 2) を設置し、作業を始めていた。1980年代後半にはこの作業グループにおいてさまざまな提案が検討されている。1990年になって出来あがったISO/TC 97/SC 2/WG 2作成のISO 10646の初版ドラフト（DIS 10646#DIS 10646第1版）では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、今後の漢字コードの方針を決めるため、WG 2は CJK-JRG (Joint Research Group) と呼ばれるグループを別途設置し、そこで引き続き検討することにした。

このような公的機関の動きとは別に、1987年頃からXeroxのJoe BeckerとLee Collinsは、後にUnicodeと呼ばれるようになる、世界中の文字を統一して扱える文字コードを開発していた。1989年9月には「Unicode Draft 1」が発表された。ここではその基本方針として、2オクテット（16ビット）固定長で全ての文字を扱えることを目指しており、そのために日本・中国・韓国の漢字を統一することで2万弱の漢字コードを入れ、さらに将来の拡張用に、3万程度の漢字の空き領域が別に用意されていた。このドラフトは少しずつ改良を加えられながら1990年4月にUnicode Draft 2、同年12月Unicode Final Draftとなった。さらに1991年1月にはこのUnicode Final Draftに賛同する企業によって、ユニコードコンソーシアムが設立された。

1991年6月、ISO/IEC 10646による4オクテット固定長コードを主体としたドラフト「DIS 10646第1版」は、2オクテット固定長コードであるUnicodeとの一本化を求める各国により否決され、ISO 10646とUnicodeの一本化が図られることになった。また中国およびユニコードコンソーシアムの要請により、CJK-JRGにおいて、ISO 10646とUnicodeの一本化が図られることになった。CJK-JRGは各国の漢字コードに基づき独自の統合規準を定め、ISO 10646 / Unicode用の統合漢字コード表を作成することになった。CJK-JRGの会合は第1回が7月22日から24日にかけて東京で、第2回の会合が9月17日から19日にかけて北京で、第3回が11月25日から29日にかけて香港で開催された。これらの討議の結果、1991年末になって「ISO 10646＝Unicode」用の統合漢字コード表が Unified Repertoire and Ordering (URO) の第1版として完成した。

Unicodeの最初に印刷されたドキュメントであるUnicode 1.0は、統合漢字表の完成に先行して漢字部分を除いたUnicode 1.0, Vol.1が1991年10月に出版され、後に1992年になって漢字部分だけのUnicode 1.0, Vol.2が出版された。

1992年、CJK統合漢字URO第二版が完成し、これを取り込んだ（ただし、UROには若干の間違いが発見されており、それらの修正が行われている。）DIS 10646第2版が、5月30日の国際投票で可決された。

1993年5月1日 「ISO/IEC 10646-1: 1993 Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and basic Multilingual Plane」が制定される。同年翌6月にUnicode 1.0は ISO/IEC 10646-1:1993にあわせた変更を行いUnicode 1.1となり、以後UnicodeとISO/IEC 10646とは歩調を合わせて改訂されていくことになる。

Unicodeのバージョン

Unicodeのバージョンは、メジャーバージョン (the major version)、マイナーバージョン (the minor version)、アップデートバージョン (the update version) の3つの部分から構成され、ピリオドでつなげて表示される。ただし、マイナーバージョン及びアップデートバージョンについては0の場合には省略して表示されることもある。メジャーバージョンはレパートリーの追加のような重要な変更が行われたときに改定される。Unicodeのドキュメントは書籍形態と電子版ドキュメント形態の両方で公表され、どちらもUnicodeについての正式なドキュメントであるとされている。新たなバージョンがリリースされたときは新たなドキュメントが公表されるが、書籍として刊行されるのはメジャーバージョンが改定された場合および重要なマイナーバージョンの改定があった場合のみである。書籍版のバージョン1.0は、2巻に分けて刊行され、統合漢字部分を除いた第1巻は1991年10月に、統合漢字部分の第2巻は1992年6月に刊行された。そのため第1巻のみのものをUnicode 1.0.0、第2巻を含めたものをUnicode 1.0.1と呼ぶことがある。

各バージョンとその特徴

Unicodeのそれぞれのバージョン番号とその制定年月日、収録文字数他の特徴は以下の通りである。

制定年月日	バージョン番号	収録文字数	概要	日本語における主要な追加文字
1991年10月	Unicode 1.0.0	7,161	初期バージョン、16ビットの文字コード	JIS X 0201
1992年6月	Unicode 1.0.1	28,359	CJK統合漢字を導入	JIS X 0208、JIS X 0212
1993年6月	Unicode 1.1.0	34,233	ISO/IEC 10646-1:1993にあわせ変更
1993年7月	Unicode 1.1.5
1996年7月	Unicode 2.0.0	38,950	ISO/IEC 10646-1:1993の追補Amd.1からAmd.7に対応。ハングルの大移動を行いUnicode1.xとの互換性を失う (Amd.5)、サロゲートペア（代用対）を導入し追加面を可能にして収容可能な文字を大幅に増やす、21ビット領域に拡張 (Amd.1)
1998年5月	Unicode 2.1.0	38,952	ユーロ記号と正誤表を追加
1998年5月	Unicode 2.1.2
1998年8月	Unicode 2.1.5
1998年10月	Unicode 2.1.8
1999年4月	Unicode 2.1.9
1999年9月	Unicode 3.0.0	49,259	ISO/IEC 10646-1:2000が発行されるまでの追補Amd.8からAmd.31の文字すべてに対応。CJK統合漢字拡張Aで漢字6582字を追加 (Amd.17)	JIS X 0213の一部（地名や人名などに用いられる漢字）
2000年8月	Unicode 3.0.1
2001年3月	Unicode 3.1.0	94,205	ISO/IEC 10646-2:2001に対応。BMP以外の拡張。CJK統合漢字拡張Bで漢字42711字を追加	JIS X 0213の一部（地名や人名などに用いられる漢字）
2001年8月	Unicode 3.1.1
2002年3月	Unicode 3.2.0	95,221	ISO/IEC 10646-1:2000の追補Amd.1に対応	JIS X 0213（正式対応）
2003年4月	Unicode 4.0.0	96,447	ISO/IEC 10646:2003に対応
2004年5月	Unicode 4.0.1
2005年3月31日	Unicode 4.1.0	97,720	ISO/IEC 10646:2003の追補Amd.1に対応
2006年7月14日	Unicode 5.0.0	99,089	ISO/IEC 10646:2003の追補Amd.2とシンド語（Amd.3に含まれる）に対応
2008年4月4日	Unicode 5.1.0	100,713	ISO/IEC 10646:2003の追補Amd.3とAmd.4に対応。異体字セレクタを漢字に対して使い始める	麻雀牌、割り算の筆算（長除法）の記号、電話機の星印、Adobe-Japan1-6の漢字字形
2009年10月1日	Unicode 5.2.0	107,361	ISO/IEC 10646:2003の追補Amd.6までに対応	ARIB外字
テンプレート:Nowrap	Unicode 6.0.0	109,449	ISO/IEC 10646:2010	携帯電話の絵文字
2012年1月31日	Unicode 6.1.0	110,181	ISO/IEC 10646:2012
2012年9月26日	Unicode 6.2.0	110,182	新トルコリラの通貨記号の追加など
2013年9月30日	Unicode 6.3.0	110,187
2014年6月16日	Unicode 7.0.0	113,021	ISO/IEC 10646:2012の追補Amd.1とAmd.2に対応。ルーブル、アゼルバイジャン・マナトの通貨記号、北米・中国・インド・アフリカの言語のための歴史的なスクリプトの追加。	約250字の絵文字の追加。
2015年6月17日	Unicode 8.0.0	120,737	ISO/IEC 10646:2014の追補Amd.1に対応。	U+301C WAVE DASHの修正（後述）
2016年6月21日	Unicode 9.0.0	128,172	ISO/IEC 10646:2014の追補Amd.2に対応。	91個の絵文字の追加、4KTV放送用シンボル19個の追加
2017年6月20日	テンプレート:Anchorsテンプレート:Nowrap	136,690	ISO/IEC 10646:2017	変体仮名285文字追加
2018年6月5日	テンプレート:Nowrap	137,374	ISO/IEC 10646:2017の追補Amd.1に対応
2019年3月5日	Unicode 12.0.0	137,928	ISO/IEC 10646:2017の追補Amd.1とAmd.2に対応	小文字の「ゐ」「ゑ」「を」「ヰ」「ヱ」「ヲ」「ン」追加
2019年5月7日	Unicode 12.1.0	137,929		「㋿」（日本の元号「令和」の合字）追加
2020年3月10日	Unicode 13.0.0	143,859	ISO/IEC 10646:2020
2021年9月22日	Unicode 14.0.0	144,697	ISO/IEC 10646:2021	わ行う、ワ行う、ヤ行イ、ヤ行エを追加
2022年9月13日	Unicode 15.0.0	149,186	ISO/IEC 10646:2022
2023年9月12日	Unicode 15.1.0	149,813	ISO/IEC 10646:2023
2024年9月10日	Unicode 16.0.0	154,998	ISO/IEC 10646:2024

構成要素のバージョン

Unicodeのバージョンには、上記のような「Unicodeの規格全体に付けられたバージョン」の他に「Unicodeを構成する個々の要素の規格に付けられたバージョン」が存在する。これに該当するものとしては、Unicodeを構成する各面ごとに付けられたバージョンや、Unicodeに収録されないこととされたスクリプトのリスト (NOR = Not The Roadmap) に付けられたバージョン、規格の一部を構成するUnicode Technical Note（Unicode技術ノート）、Unicode Technical Report（Unicode技術報告）、Unicode Technical Standard（Unicode技術標準）のバージョンなどが存在する。

日付	全体	BMP	SMP	SIP	TIP	SSP	NOR
1991年10月	1.0.0
1992年6月	1.0.1
1993年6月	1.1.0
1993年7月	1.1.5
1996年7月	2.0.0
1998年5月	2.1.0
1998年5月	2.1.2
1998年8月	2.1.5
1998年10月	2.1.8
1999年4月	2.1.9
1999年9月	3.0.0
2000年8月	3.0.1
2001年3月	3.1.0
2001年8月	3.1.1
2001年10月10日		3.0	3.0	3.0			1.0
2001年10月12日			3.1
2001年10月27日		3.1
2001年11月27日						3.0
2002年1月22日		3.2				3.1
2002年1月29日		3.3
2002年2月5日		3.4
2002年3月	3.2.0
2002年4月3日			3.2
2002年4月4日		3.5
2002年6月7日		3.6	3.3
2002年6月23日		3.7
2002年10月2日		3.8
2002年10月28日		3.9
2002年11月11日				3.1
2002年12月3日		3.10	3.4 3.5
2002年12月11日		3.11
2003年3月12日		3.12	3.6
2003年3月15日			3.7
2003年4月	4.0.0
2003年4月16日		4.0	4.0	4.0		4.0	4.0
2003年5月4日		4.1
2003年5月16日				4.1
2003年6月18日		4.2	4.1
2003年7月15日						4.1
2003年8月19日		4.3
2003年9月11日		4.4	4.2
2003年9月20日		4.5
2003年10月22日		4.6
2003年10月31日			4.3
2003年12月23日		4.7	4.4
2004年5月	4.0.1
2004年5月27日			4.5
2004年6月24日		4.8	4.6
2004年7月3日			4.7
2004年12月1日							4.1
2005年1月27日				4.2
2005年1月28日		4.9	4.8
2005年3月31日	4.1.0	4.10	4.9
2005年5月27日			4.10				4.2
2005年6月10日		4.11	4.11
2005年6月27日		4.12	4.12	4.3		4.2	4.3
2005年8月1日		4.13	4.13
2005年9月6日		4.14
2005年9月14日		4.15
2005年9月17日			4.14
2005年9月19日		4.16
2005年12月8日			4.15
2006年1月11日		4.17	4.16
2006年4月17日		4.18	4.17	4.4
2006年4月28日							4.4
2006年7月14日	5.0.0
2006年9月21日		5.0	5.0	5.0		5.0	5.0
2006年9月29日		5.0.1		5.0.1
2007年3月14日			5.0.1
2007年4月11日		5.0.2	5.0.2
2007年5月5日		5.0.3	5.0.3
2007年7月24日		5.0.4	5.0.4				5.0.1
2007年8月22日		5.0.5
2007年8月29日			5.0.5
2008年1月15日			5.0.6
2008年1月31日		5.0.6
2008年2月14日		5.0.7	5.0.7
2008年4月4日	5.1.0	5.1.0	5.1.0	5.1.0		5.1.0	5.1.0
2008年4月25日		5.1.1	5.1.1		5.1.0		5.1.1
2008年8月12日		5.1.2	5.1.2
2008年8月19日		5.1.3
2008年10月17日		5.1.4	5.1.3		5.1.1
2009年2月4日		5.1.5	5.1.4
2009年2月26日				5.1.1
2009年4月22日				5.1.2
2009年4月24日			5.1.5
2009年10月1日	5.2.0	5.2.0	5.2.0	5.2.0	5.2.0	5.2.0	5.2.0
2009年11月18日		5.2.1
2010年2月5日			5.2.1
2010年2月10日			5.2.2
2010年2月23日			5.2.3
2010年4月23日		5.2.2	5.2.4
2010年5月12日			5.2.5
2010年6月24日			5.2.6
2010年7月27日			5.2.7
2010年10月11日	6.0.0	6.0.0	6.0.0	6.0.0	6.0.0	6.0.0	6.0.0
2010年12月6日			6.0.1
2011年1月9日			6.0.2
2011年1月14日		6.0.1
2011年1月27日		6.0.2	6.0.3	6.0.1	6.0.1	6.0.1	6.0.1
2011年3月18日			6.0.4
2011年5月24日			6.0.5
2011年6月23日		6.0.3	6.0.6
2011年8月1日			6.0.7
2011年8月15日			6.0.8
2011年8月24日			6.0.9
2011年11月15日			6.0.10
2011年11月29日			6.0.11
2011年12月19日							6.0.2
2012年1月6日			6.0.12
2012年1月31日	6.1.0
2012年2月1日		6.1.0	6.1.0	6.1.0	6.1.0	6.1.0	6.1.0
2012年2月15日			6.1.1
2012年5月4日			6.1.2
2012年7月30日			6.1.3
2012年8月27日			6.1.4
2012年9月13日		6.1.1	6.1.5
2012年9月26日	6.2.0
2012年9月27日		6.2.0	6.2.0	6.2.0	6.2.0	6.2.0	6.2.0
2012年10月16日			6.2.1	6.2.1
2012年12月2日			6.2.2	6.2.2
2013年3月19日			6.2.3
2013年5月4日			6.2.4
2013年5月23日			6.2.5
2013年7月24日			6.2.6
2013年9月30日	6.3.0
2013年10月28日		6.3.0	6.3.0	6.3.0	6.3.0	6.3.0	6.3.0
2014年2月19日		6.3.1	6.3.1
2014年6月16日	7.0.0
2014年8月7日		7.0.0	7.0.0	7.0.0	7.0.0	7.0.0	7.0.0
2014年9月18日		7.0.1	7.0.1	7.0.1
2014年10月24日			7.0.2	7.0.2	7.0.1
2015年3月26日		7.0.2	7.0.3
2015年6月3日		7.0.3	7.0.4
2015年6月17日	8.0.0
2015年6月26日		8.0.0	8.0.0	8.0.0	8.0.0	8.0.0	8.0.0
2015年8月17日			8.0.1
2016年1月21日		8.0.1	8.0.2		8.0.1
2016年2月3日			8.0.3	8.0.1
2016年5月3日		8.0.2
2016年6月10日			8.0.4
2016年6月21日	9.0.0
2016年6月23日		9.0.0	9.0.0	9.0.0	9.0.0	9.0.0	9.0.0
2017年1月12日			9.0.1
2017年5月24日		9.0.1
2017年6月6日			9.0.2
2017年6月20日	10.0.0
2017年6月21日		10.0.0		10.0.0	10.0.0	10.0.0	10.0.0
2017年6月29日			10.0.0
2017年12月27日					10.0.1
2018年1月10日			10.0.1				-

Unicodeの諸問題

バージョンごとの非互換性

Unicodeは同一のコードでもバージョンが変わったとき完全に異なった文字を定義し直したことがある。

そのうち最大のものがUnicode 2.0での「ハングルの大移動」である。これはUnicode 1.1までで定義されていたハングルの領域を破棄し、新しいハングルの領域を別の位置に設定し、破棄された領域には別の文字の領域を割り当てることとなった。その後、Unicode 3.0では、従来ハングルが割り当てられていた領域にCJK統合漢字拡張A、ついでUnicode 4.0で六十四卦が割り当てられた。このように、Unicode 1.1以前でハングルを記述した文書とUnicode 2.0以降でCJK統合漢字拡張Aを記述した文書には互換性がないテンプレート:Efn。JCS委員長の芝野耕司はUnicodeに日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている。

日本語環境でのUnicodeの諸問題

YEN SIGN 問題

Shift JIS では JIS X 0201 における（日本や中国の通貨の）円記号 "¥" が 0x5C に置かれている。これを Unicode のマッピングに合わせると YEN SIGN (U+00A5) にマップされる。しかし、0x5C は ASCII ではバックスラッシュ "テンプレート:Backslash" に相当し、C言語などでエスケープ文字として使われる事から、この文字のコードを変更すると問題が起きる。極端な例として、0x5C が円記号とエスケープ文字の両方の目的で使われているケース（たとえばC言語のprintf関数で printf("¥¥%d¥n", price); など）も考えられる。

そのため、Unicode を利用するアプリケーションでは、U+007F 以下のコードに関しては移動させないという暗黙のルールができている。

そうなると、Unicode 環境では円記号がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの 0x5C の位置には円記号の字形を当ててしまうことで対処している。これによって、日本語環境での表示上は 0x5C の位置で円記号を用いることができる。

この問題は日本語環境に限ったことではない。もともと ISO 646 上では、0x5C を含む数種の文字は自由領域（バリアント）として各国での定義を認めていた。そのため、日本語以外でも ASCII でバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、韓国では通貨のウォン記号 (WON SIGN, U+20A9, "テンプレート:Unicode")、デンマークやノルウェーではストローク付きO (LATIN CAPITAL LETTER O WITH STROKE, U+00D8, "テンプレート:Unicode") などである。（後者は後の時代には、0x5C はバックスラッシュのままとし、ISO 8859 シリーズを用いることが一般化した。）

波ダッシュ・全角チルダ問題

JIS X 0221 規定の JIS X 0208 と JIS X 0221 の対応表では、波ダッシュは WAVE DASH (U+301C, "テンプレート:JIS2004フォント") に対応させている。

しかし、マイクロソフトは Windows の Shift_JIS と Unicode の変換テーブルを作成する際に、JIS X 0208 において 1 区 33 点に割り当てられている波ダッシュ "テンプレート:JIS2004フォント" を、Unicode における全角チルダ (FULLWIDTH TILDE, U+FF5E, "～") に割り当てたため不整合が生じた。

この結果、macOS 等の JIS X 0221 準拠の Shift_JIS ⇔ Unicode 変換テーブルをもつ処理系と Windows との間で Unicode データをやり取りする場合、文字化けを起こすことになる。そこで Windows 以外の OS 上で動くアプリケーションの中には、CP932 という名前でマイクロソフト仕様の Shift_JIS コード体系を別途用意して対応しているケースが多い。この原因とされている Unicode 仕様書の例示字形の問題に関しては、波ダッシュ#Unicodeに関連する問題を参照すること。

マイクロソフト仕様に起因する問題

上記に加え、マイクロソフト仕様は変換時にも問題が起こる文字を以下に示す。

JIS X 0208 区点	Shift JIS	JIS X 0208 日本語通用名称	SJISでデコード	MS932でデコード (マイクロソフト仕様)	関連記事
1-29	0x815c	ダッシュ(全角)	テンプレート:Font (U+2014) EM DASH	テンプレート:Font (U+2015) HORIZONTAL BAR	ダッシュ (記号)
1-33	0x8160	波ダッシュ	テンプレート:Font (U+301C) WAVE DASH	テンプレート:Font (U+FF5E) FULLWIDTH TILDE	波ダッシュ、全角チルダ
1-34	0x8161	双柱	テンプレート:Font (U+2016) DOUBLE VERTICAL LINE	テンプレート:Font (U+2225) PARALLEL TO	双柱、平行記号
1-61	0x817c	負符号、減算記号	テンプレート:Font (U+2212) MINUS SIGN	テンプレート:Font (U+FF0D) FULLWIDTH HYPHEN-MINUS	マイナス記号、ハイフンマイナス
1-81	0x8191	セント記号	テンプレート:Font (U+00A2) CENT SIGN	テンプレート:Font (U+FFE0) FULLWIDTH CENT SIGN	セント (通貨)
1-82	0x8192	ポンド記号	テンプレート:Font (U+00A3) POUND SIGN	テンプレート:Font (U+FFE1) FULLWIDTH POUND SIGN	£
2-44	0x81ca	否定	テンプレート:Font (U+00AC) NOT SIGN	テンプレート:Font (U+FFE2) FULLWIDTH NOT SIGN	否定記号

このうちセント・ポンド・否定については、IBMのメインフレームではShift_JISを拡張してこれらの半角版をコードポイント 0xFD-0xFF に割り当て、別途JIS X 0208からマップされた位置に全角版を収録していたため、WindowsをIBMメインフレームの端末として用いるケースを想定したといわれているテンプレート:要出典。

なお、Windows Vista や Microsoft Office 2007 に付属する IME パッドの文字一覧における JIS X 0213 の面区点の表示は、上記の文字についても JIS で規定されているものと同じマッピングを使用しているテンプレート:要出典。

参考文献

• 用語の日本語表記は原則として次にならった。テンプレート:Cite web
• テンプレート:Cite book
• テンプレート:Cite book
  • テンプレート:Cite book
  • テンプレート:Cite book
  • テンプレート:Cite book - 付属：CD-ROM。
  • テンプレート:Cite book - 付属：CD-ROM。
  • テンプレート:Cite book - 付属：CD-ROM。
• テンプレート:Cite book - 原タイトル：Unicode: a primer。
• テンプレート:Cite book
• テンプレート:Cite book
• テンプレート:Cite book
• テンプレート:Cite book
• テンプレート:Cite book
• テンプレート:Cite book

関連項目

• ISO/IEC 10646
• OpenType
• Unicode一覧
• Unicode一覧表
• ブロック (Unicode)
• Unicode参照アルゴリズム
• 機種依存文字
• 国際化と地域化
• 中西亮
• 文字コード
• 異体字セレクタ

外部リンク

• The Unicode Consortium テンプレート:En icon
• DecodeUnicode テンプレート:En icon
• BabelMap - Unicode Character Map for Windows