Unicode

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

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

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

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

 Unicode文字符号化モデル 
文字コードは、Unicode文字符号化モデルによると以下の4段階に分けられる：
  ()  符号化の対象とする順序のない文字の集合。
  ()  抽象文字集合を非負整数に対応させたもの。この非負整数の範囲を符号空間、各値を符号位置 (コードポイント) といい、抽象文字は対応後、符号化文字となる。抽象文字は複数の符号化文字に対応されることもある。
  ()  符号化文字集合の非負整数を符号単位列に変換する方法。文字符号化形式はコンピュータ中に実際にデータとして文字を表現することを可能にする。
  ()  符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係する。

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

 文字集合 

Unicodeの文字集合の符号空間は0 - 10FFFF16で111万4,112の符号位置がある。Unicode 16.0（2024年9月10日公表）では15万4,998個1 (13.9%) の文字が割り当てられ、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ビットまでである。

+ 各文字符号化形式の符号化例000102030405060708090A0B0C0D0E0FUTF-8AΩ語😊41CEA9E8AA9EF09F988AUTF-16AΩ語😊004103A98A9ED83DDE0AUTF-32AΩ語😊00000041000003A900008A9E0001F60A

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

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

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

文字符号化方式(CES)エンディアンBOMの付与UTF-8UTF-16ビッグ/リトルUTF-16BEビッグエンディアンUTF-16LEリトルエンディアンUTF-32ビッグ/リトルUTF-32BEビッグエンディアンUTF-32LEリトルエンディアン

 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ならビッグエンディアンとして後に続く文書を処理する。
 では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-8AΩ語😊41CEA9E8AA9EF09F988AUTF-16BEAΩ語😊004103A98A9ED83DDE0AUTF-16LEAΩ語😊4100A9039E8A3DD80ADEUTF-32BEAΩ語😊00000041000003A900008A9E0001F60AUTF-32LEAΩ語😊41000000A90300009E8A00000AF60100

 その他 
 UTF-7

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

以下はエイプリルフールに公開されたジョーク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ビット固定長で、216 = 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の符号空間が10FFFF16まで（サロゲート領域を除いて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ではすべての符号位置を符号化できるためこのような特別な処理は必要ない。

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


デコーディングは、

である。

 コード変換例「𠮷」U+20BB7 のエンコードを考えてみる。
  から
  を引くと、結果は
  となる。
 これを上位10ビット値と下位10ビット値に分割する。

 ハイ（上位）サロゲートを形成するために上位ビットに を加える。

 ロー（下位）サロゲートを形成するために下位ビットに  を加える。

 結果
  (UTF-16 符号単位列)
 (UTF-16BEでの符号化バイト列)
 (UTF-16LEでの符号化バイト列)

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

文字（符号位置） 符号位置(2進数) UTF-16符号単位列(2進数) UTF-16符号単位列 UTF-16BE符号化バイト列 UTF-16LE符号化バイト列$  U+0024€  U+20AC𠮷  U+20BB71101 10 1101 11   最大値  U+10FFFF1101 10 1101 11   

 面 
一つの面は6万5536個の符号位置がある。
面符号位置英語での名称略称日本語での名称収録されている主な文字第0面U+0000 - U+FFFFBasic Multilingual PlaneBMP基本多言語面基本的な文字。第1面U+10000 - U+1FFFFSupplementary Multilingual PlaneSMP追加多言語面古代文字や記号・絵文字類など。第2面U+20000 - U+2FFFFSupplementary Ideographic PlaneSIP追加漢字面漢字専用領域。第3面U+30000 - U+3FFFFTertiary Ideographic PlaneTIP第三漢字面追加漢字面に入りきらなかった漢字。また、将来的には古代漢字や甲骨文字などが収録される予定。第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+EFFFFSupplementary Special-purpose PlaneSSP追加特殊用途面制御コード専用領域。第15面U+F0000 - U+FFFFFPrivate Use PlanePUP私用面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年改定で追加された字のうち「」は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.07,161初期バージョン、16ビットの文字コードJIS X 02011992年6月Unicode 1.0.128,359CJK統合漢字を導入JIS X 0208、JIS X 02121993年6月Unicode 1.1.034,233ISO/IEC 10646-1:1993にあわせ変更1993年7月Unicode 1.1.5  1996年7月Unicode 2.0.038,950ISO/IEC 10646-1:1993の追補Amd.1からAmd.7に対応。ハングルの大移動を行いUnicode1.xとの互換性を失う (Amd.5)、サロゲートペア（代用対）を導入し追加面を可能にして収容可能な文字を大幅に増やす、21ビット領域に拡張 (Amd.1)1998年5月Unicode 2.1.038,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.049,259ISO/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.094,205ISO/IEC 10646-2:2001に対応。BMP以外の拡張。CJK統合漢字拡張Bで漢字42711字を追加JIS X 0213の一部（地名や人名などに用いられる漢字）2001年8月Unicode 3.1.1  2002年3月Unicode 3.2.095,221ISO/IEC 10646-1:2000の追補Amd.1に対応JIS X 0213（正式対応）2003年4月Unicode 4.0.096,447ISO/IEC 10646:2003に対応2004年5月Unicode 4.0.1  2005年3月31日Unicode 4.1.097,720ISO/IEC 10646:2003の追補Amd.1に対応2006年7月14日Unicode 5.0.099,089ISO/IEC 10646:2003の追補Amd.2とシンド語（Amd.3に含まれる）に対応2008年4月4日Unicode 5.1.0100,713ISO/IEC 10646:2003の追補Amd.3とAmd.4に対応。異体字セレクタを漢字に対して使い始める麻雀牌、割り算の筆算（長除法）の記号、電話機の星印、Adobe-Japan1-6の漢字字形2009年10月1日Unicode 5.2.0107,361ISO/IEC 10646:2003の追補Amd.6までに対応ARIB外字Unicode 6.0.0109,449ISO/IEC 10646:2010携帯電話の絵文字2012年1月31日Unicode 6.1.0110,181ISO/IEC 10646:20122012年9月26日Unicode 6.2.0110,182新トルコリラの通貨記号の追加など2013年9月30日Unicode 6.3.0110,1872014年6月16日Unicode 7.0.0113,021ISO/IEC 10646:2012の追補Amd.1とAmd.2に対応。ルーブル、アゼルバイジャン・マナトの通貨記号、北米・中国・インド・アフリカの言語のための歴史的なスクリプトの追加。約250字の絵文字の追加。2015年6月17日Unicode 8.0.0120,737ISO/IEC 10646:2014の追補Amd.1に対応。U+301C WAVE DASHの修正（後述）2016年6月21日Unicode 9.0.0128,172ISO/IEC 10646:2014の追補Amd.2に対応。91個の絵文字の追加、4KTV放送用シンボル19個の追加2017年6月20日136,690ISO/IEC 10646:2017変体仮名285文字追加2018年6月5日137,374ISO/IEC 10646:2017の追補Amd.1に対応2019年3月5日Unicode 12.0.0 137,928ISO/IEC 10646:2017の追補Amd.1とAmd.2に対応小文字の「ゐ」「ゑ」「を」「ヰ」「ヱ」「ヲ」「ン」追加2019年5月7日Unicode 12.1.0 137,929 「㋿」（日本の元号「令和」の合字）追加2020年3月10日Unicode 13.0.0 143,859ISO/IEC 10646:20202021年9月22日Unicode 14.0.0 144,697ISO/IEC 10646:2021わ行う、ワ行う、ヤ行イ、ヤ行エを追加2022年9月13日Unicode 15.0.0 149,186ISO/IEC 10646:20222023年9月12日Unicode 15.1.0 149,813ISO/IEC 10646:20232024年9月10日Unicode 16.0.0 154,998ISO/IEC 10646:2024

 構成要素のバージョン 

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

日付全体BMPSMPSIPTIPSSPNOR1991年10月1.0.01992年6月1.0.11993年6月1.1.01993年7月1.1.51996年7月2.0.01998年5月2.1.01998年5月2.1.21998年8月2.1.51998年10月2.1.81999年4月2.1.91999年9月3.0.02000年8月3.0.12001年3月3.1.02001年8月3.1.12001年10月10日3.03.03.01.02001年10月12日3.12001年10月27日3.12001年11月27日3.02002年1月22日3.23.12002年1月29日3.32002年2月5日3.42002年3月3.2.02002年4月3日3.22002年4月4日3.52002年6月7日3.63.32002年6月23日3.72002年10月2日3.82002年10月28日3.92002年11月11日3.12002年12月3日3.103.4

3.52002年12月11日3.112003年3月12日3.123.62003年3月15日3.72003年4月4.0.02003年4月16日4.04.04.04.04.02003年5月4日4.12003年5月16日4.12003年6月18日4.24.12003年7月15日4.12003年8月19日4.32003年9月11日4.44.22003年9月20日4.52003年10月22日4.62003年10月31日4.32003年12月23日4.74.42004年5月4.0.12004年5月27日4.52004年6月24日4.84.62004年7月3日4.72004年12月1日4.12005年1月27日4.22005年1月28日4.94.82005年3月31日4.1.04.104.92005年5月27日4.10[4.22005年6月10日4.114.112005年6月27日4.124.124.34.24.32005年8月1日4.134.132005年9月6日4.142005年9月14日4.152005年9月17日4.142005年9月19日4.162005年12月8日4.152006年1月11日4.174.162006年4月17日4.184.174.42006年4月28日4.42006年7月14日5.0.02006年9月21日5.05.05.05.05.02006年9月29日5.0.15.0.12007年3月14日5.0.12007年4月11日5.0.25.0.22007年5月5日5.0.35.0.32007年7月24日5.0.45.0.45.0.12007年8月22日5.0.52007年8月29日5.0.52008年1月15日5.0.62008年1月31日5.0.62008年2月14日5.0.75.0.72008年4月4日5.1.05.1.05.1.05.1.05.1.05.1.02008年4月25日5.1.15.1.15.1.05.1.12008年8月12日5.1.25.1.22008年8月19日5.1.32008年10月17日5.1.45.1.35.1.12009年2月4日5.1.55.1.42009年2月26日5.1.12009年4月22日5.1.22009年4月24日5.1.52009年10月1日5.2.05.2.05.2.05.2.05.2.05.2.05.2.02009年11月18日5.2.12010年2月5日5.2.12010年2月10日5.2.22010年2月23日5.2.32010年4月23日5.2.25.2.42010年5月12日5.2.52010年6月24日5.2.62010年7月27日5.2.72010年10月11日6.0.06.0.06.0.06.0.06.0.06.0.06.0.02010年12月6日6.0.12011年1月9日6.0.22011年1月14日6.0.12011年1月27日6.0.26.0.36.0.16.0.16.0.16.0.12011年3月18日6.0.42011年5月24日6.0.52011年6月23日6.0.36.0.62011年8月1日6.0.72011年8月15日6.0.82011年8月24日6.0.92011年11月15日6.0.102011年11月29日6.0.112011年12月19日6.0.22012年1月6日6.0.122012年1月31日6.1.02012年2月1日6.1.06.1.06.1.06.1.06.1.06.1.02012年2月15日6.1.12012年5月4日6.1.22012年7月30日6.1.32012年8月27日6.1.42012年9月13日6.1.16.1.52012年9月26日6.2.02012年9月27日6.2.06.2.06.2.06.2.06.2.06.2.02012年10月16日6.2.16.2.12012年12月2日6.2.26.2.22013年3月19日6.2.32013年5月4日6.2.42013年5月23日6.2.52013年7月24日6.2.62013年9月30日6.3.02013年10月28日6.3.06.3.06.3.06.3.06.3.06.3.02014年2月19日6.3.16.3.12014年6月16日7.0.02014年8月7日7.0.07.0.07.0.07.0.07.0.07.0.02014年9月18日7.0.17.0.17.0.12014年10月24日7.0.27.0.27.0.12015年3月26日7.0.27.0.32015年6月3日7.0.37.0.42015年6月17日8.0.02015年6月26日8.0.08.0.08.0.08.0.08.0.08.0.02015年8月17日8.0.12016年1月21日8.0.18.0.28.0.12016年2月3日8.0.38.0.12016年5月3日8.0.22016年6月10日8.0.42016年6月21日9.0.02016年6月23日9.0.09.0.09.0.09.0.09.0.09.0.02017年1月12日9.0.12017年5月24日9.0.12017年6月6日9.0.22017年6月20日10.0.02017年6月21日10.0.010.0.010.0.010.0.010.0.02017年6月29日10.0.02017年12月27日10.0.12018年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を記述した文書には互換性がない。JCS委員長の芝野耕司はUnicodeに日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている。

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

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

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

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

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

 波ダッシュ・全角チルダ問題 
JIS X 0221 規定の JIS X 0208 と JIS X 0221 の対応表では、波ダッシュは WAVE DASH (U+301C, "") に対応させている。

しかし、マイクロソフトは Windows の Shift_JIS と Unicode の変換テーブルを作成する際に、JIS X 0208 において 1 区 33 点に割り当てられている波ダッシュ "" を、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  ダッシュ(全角)   (U+2014) EM DASH   (U+2015) HORIZONTAL BAR  ダッシュ (記号) 1-33 0x8160  波ダッシュ   (U+301C) WAVE DASH   (U+FF5E) FULLWIDTH TILDE  波ダッシュ、全角チルダ 1-34 0x8161  双柱   (U+2016) DOUBLE VERTICAL LINE   (U+2225) PARALLEL TO  双柱、平行記号 1-61 0x817c  負符号、減算記号   (U+2212) MINUS SIGN   (U+FF0D) FULLWIDTH HYPHEN-MINUS  マイナス記号、ハイフンマイナス 1-81 0x8191  セント記号   (U+00A2) CENT SIGN   (U+FFE0) FULLWIDTH CENT SIGN  セント (通貨) 1-82 0x8192  ポンド記号   (U+00A3) POUND SIGN   (U+FFE1) FULLWIDTH POUND SIGN  £ 2-44 0x81ca  否定   (U+00AC) NOT SIGN   (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 で規定されているものと同じマッピングを使用している。

 ブロックの一覧 

 索引0000-0FFF
1000-1FFF
2000-2FFF
3000-3FFF
4000-4FFF
5000-5FFF
6000-6FFF
7000-7FFF
8000-8FFF
9000-9FFF
A000-AFFF
B000-BFFF
C000-CFFF
D000-DFFF
E000-EFFF
F000-FFFF10000-10FFF
11000-11FFF
12000-12FFF
13000-13FFF
14000-14FFF
15000-15FFF
16000-16FFF
17000-17FFF
18000-18FFF
19000-19FFF
1A000-1AFFF
1B000-1BFFF
1C000-1CFFF
1D000-1DFFF
1E000-1EFFF
1F000-1FFFF20000-20FFF
21000-21FFF
22000-22FFF
23000-23FFF
24000-24FFF
25000-25FFF
26000-26FFF
27000-27FFF
28000-28FFF
29000-29FFF
2A000-2AFFF
2B000-2BFFF
2C000-2CFFF
2D000-2DFFF
2E000-2EFFF
2F000-2FFFF30000-30FFF
31000-31FFF
32000-32FFF
33000-33FFF
34000-34FFF
35000-35FFF
36000-36FFF
37000-37FFF
38000-38FFF
39000-39FFF
3A000-3AFFF
3B000-3BFFF
3C000-3CFFF
3D000-3DFFF
3E000-3EFFF
3F000-3FFFFE0000-E0FFF

 脚注 

 注釈 

 出典 

 参考文献 
用語の日本語表記は原則として次にならった。

 - 付属：CD-ROM。
 - 付属：CD-ROM。
 - 付属：CD-ROM。
 - 原タイトル：Unicode: a primer。

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

 外部リンク 
 The Unicode Consortium 
 DecodeUnicode 
 BabelMap - Unicode Character Map for Windows

*