Unicode（ユニコード）とは、符号化文字集合や文字符号化方式などを定めた、文字コードの業界規格である。文字集合（文字セット）が単一の大規模文字セットであること（「Uni」という名はそれに由来する）などが特徴である。1980年代に、Starワークステーションの日本語化 (J-Star) などを行ったゼロックス社が提唱し、マイクロソフト、アップル、IBM、サン・マイクロシステムズ、ヒューレット・パッカード、ジャストシステムなどが参加するユニコードコンソーシアムにより作られた。1993年に、国際標準との一致が図られ、DIS 10646の当初案から大幅に変更されて、Unicodeと概ね互換のISO/IEC 10646が制定された。Unicode は世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られ、Unix、Windows、OS X、Plan 9、Javaなどで利用されている。Unicodeでは、文字集合中の文字をあらわす符号位置（コードポイント、符号点を参照）に、「Unicodeスカラ値」という非負整数値が割り振られている。Unicodeスカラ値は "U+" の後に十六進法でその値を続けることで表す。BMP（Basic Multilingual Plane, 基本多言語面）内の符号位置は U+0000 〜 U+FFFF の4桁で表すことができ、SMP（Supplementary Multilingual Plane, 追加多言語面もしくは補助多言語面）以降は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など、対応が違うために文字化けを起こすことがある。Unicodeに収録されている文字については、下に記載した#一覧の「コード順分類一覧」を参照。Unicodeでは文字符号化方式を「文字符号化スキーム」(Character Encoding Scheme) と言う。以下はエイプリルフールに公開されたジョークRFCである (RFC 4042)。UTF-9に関しては同名の規格が実際に検討されていた（ただし内容は大きく異なる）が、ドラフト段階で破棄されているため重複にはならない。以下はドラフト段階で破棄された規格案。1980年代の当初の構想では、Unicodeは16ビット固定長で、2 = 65,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の領域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 の範囲である。サロゲートのエンコーディングは、デコードは、となる。厳密には正確ではないが、UTF-16はUCS-2をサロゲートペアで拡張したようなものであると言える。またUnicodeは（現在のところ）UCS-4のうち、サロゲートペアで表現可能な空間のみを使うものとし（異体字セレクタなどは空間を別の軸の向きに広げるものとされている）ISO/IEC 10646もUnicodeに追随するような形で改訂されている。サロゲートペアによって拡張された符号位置は、UTF-32ではそのまま表現できる。UTF-8では、通常4オクテット（Fx xx xx xx）を使って表現される。UTF-16ではサロゲートペアを使って表現する。UTF-8を使っているが4オクテット以上のオクテット列を扱えない場合に、サロゲートペアをそのままUTF-8で表現したような表現が使われることがあり、CESU-8と言う（詳しくはUTF-8#サロゲートペアの扱いを参照）。サロゲートペア (Surrogate Pair) の日本語訳は代用対とされている。現在、拡張領域には次のように文字が割り当てられている。日本では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は、後にユニコードと呼ばれるようになる、世界中の文字を統一して扱える文字コードを開発していた。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の一本化が図られることになった。また中国および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となり、以後ユニコードとISO/IEC 10646とは歩調を合わせて改訂されていくことになる。ユニコードのバージョンは、メジャーバージョン (the major version)、マイナーバージョン (the minor version)、アップデートバージョン (the update version) の3つの部分から構成され、ピリオドでつなげて表示される。但しマイナーバージョン及びアップデートバージョンについては0の場合には省略して表示されることもある。メジャーバージョンはレパートリーの追加のような重要な変更が行われたときに改定される。ユニコードのドキュメントは書籍形態と電子版ドキュメント形態の両方で公表され、どちらもユニコードについての正式なドキュメントであるとされている。新たなバージョンがリリースされたときは新たなドキュメントが公表されるが、書籍として刊行されるのはメジャーバージョンが改定された場合および重要なマイナーバージョンの改定があった場合のみである。書籍版のバージョン1.0は、2巻に分けて刊行され、統合漢字部分を除いた第1巻は1991年10月に、統合漢字部分の第2巻は1992年6月に刊行された。そのため第1巻のみのものをUnicode 1.0.0、第2巻を含めたものをUnicode 1.0.1と呼ぶことがある。ユニコードのそれぞれのバージョン番号とその制定年月日、収録文字数他の特徴は以下の通りである。ユニコードのバージョンには、上記のような「ユニコードの規格全体に付けられたバージョン」の他に「ユニコードを構成する個々の要素の規格に付けられたバージョン」が存在する。これに該当するものとしては、ユニコードを構成する各面ごとに付けられたバージョンや、ユニコードに収録されないこととされたスクリプトのリスト (NOR = Not The Roadmap) に付けられたバージョン、規格の一部を構成するUnicode Technical Note（Unicode技術ノート）、Unicode Technical Report（Unicode技術報告）、Unicode Technical Standard（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に日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている。Shift_JIS では JIS X 0201 における円記号 "¥" が 0x5C に置かれている。これを Unicode のマッピングに合わせると YEN SIGN (U+00A5) にマップされる。しかし、0x5C は ASCII ではバックスラッシュ " に相当し、C言語などでエスケープ文字として使われる事から、この文字のコードを変更すると問題が起きる。極端な例として、0x5C が円記号とエスケープ文字の両方の目的で使われているケース（たとえば codice_2 など）も考えられる。そのため、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, "～") に割り当てたため不整合が生じる。この結果、OS X 等の JIS X 0221 準拠の Shift_JIS ⇔ Unicode 変換テーブルをもつ処理系と Windows との間で Unicode データをやり取りする場合、文字化けを起こすことになる。そこで Windows 以外の OS 上で動くアプリケーションの中には、CP932 という名前でマイクロソフト仕様の Shift_JIS コード体系を別途用意して対応しているケースが多い。この原因とされている Unicode 仕様書の例示字形の問題に関しては、波ダッシュ#Unicodeに関連する問題を参照すること。また、マイクロソフトは同様に、と割り当てており、これらの変換時にも問題が起こる。このうちセント・ポンド・否定については、IBMのメインフレームではShift_JISを拡張してこれらの半角版をコードポイント 0xFD-0xFF に割り当て、別途JIS X 0208からマップされた位置に全角版を収録していたため、WindowsをIBMメインフレームの端末として用いるケースを想定したといわれているなお、Windows Vista や Microsoft Office 2007 に付属する IME パッドの文字一覧における JIS X 0213 の面区点の表示は、上記の文字についても JIS で規定されているものと同じマッピングを使用している。「日本語での通用名称」がJIS X 0221:2007に例示されているブロックについてはそれに準拠し、Wikipedia内の記事で用いられている名称がそれと異なる場合はその名称も併記した。*印はJIS X 0221:2007制定以降に追加されたブロック。

出典:wikipedia