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