Unicodeの文字集合の符号空間は0 - 10FFFF16で111万4,112の符号位置がある[7]。Unicode 12.1（2019年5月7日公表）では13万7,929個 (12%) の文字[注釈 3]が割り当てられ、65個を制御文字に使い、13万7,468符号位置 (12%) を私用文字として確保している。また、2,048文字分をUTF-16のための代用符号位置に使用しており、加えて66の特別な符号位置は使われない。残りの83万6,536符号位置 (75%) は未使用である[8]。
文字を特定する場合にはUnicode符号位置や一意につけられた名前が使われる。例えば、アルファベット小文字の「a」はU+0061 (LATIN SMALL LETTER A)、八分音符「♪」はU+266A (EIGHTH NOTE) である。Unicode符号位置を文章中などに記す場合は "U+" の後に十六進法で符号位置を4桁から6桁続けることで表す。また、符号空間のうち代用符号位置を除く符号位置をUnicodeスカラ値という[9]。
収録されている文字は、各国で標準として規定されている文字集合や実際に使用されている文字を持ち寄り、委員会により取捨選択されている。日本の文字については当初よりJIS X 0201、JIS X 0208、JIS X 0212を、Unicode 3.1からはJIS X 0213の内容も収録している。
また収録において、元の各文字集合内で分離されている文字は尊重するが、異なる文字集合に同一の文字が収録されているとみなされるものは、同じ符号位置に割り当てる方針を取っている。この際に集合が膨大であるという理由で、漢字について、中国、日本、韓国の各規格の漢字を統合しCJK統合漢字としたことは大きな議論となった。
現在では独自創作の絵文字の追加等、当初の目的である「各国・各社の文字コードの統合」から外れた動きも進んでいる。
Unicodeに収録されている文字については、「ブロックの一覧」を参照。
文字符号化形式この項目には、一部のコンピュータや閲覧ソフトで表示できない文字（「AΩ語」の次の文字は笑顔を示す顔文字）が含まれています（詳細）。
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ビットまでである。
各文字符号化形式の符号化例000102030405060708090A0B0C0D0E0F 文字符号化形式 Unicodeでは文字符号化方式としてUTF-8、UTF-16、UTF-16BE、UTF-16LE、UTF-32、UTF-32BE、UTF-32LEの7種類が定められている。それぞれの符号化形式に対応する符号化方式は表の通り。 文字符号化形式との違いは、文字符号化形式がプログラム内部で文字を扱う場合に符号なし整数として文字を表現する方法なのに対し、文字符号化方式は入出力時にバイト列として表現する方法である。UTF-8は符号単位が8ビットであるため区別する意味はない。 文字符号化方式
UTF-8AΩ語?
41CEA9E8AA9EF09F988A
UTF-16AΩ語?
004103A98A9ED83DDE0A
UTF-32AΩ語?
00000041000003A900008A9E0001F60A
文字符号化方式
(CEF)文字符号化方式
(CES)
UTF-8UTF-8
UTF-16UTF-16
UTF-16BE
UTF-16LE
UTF-32UTF-32
UTF-32BE
UTF-32LE
(CES)エンディアンBOMの付与
UTF-8N/A可
UTF-16ビッグ/リトル可
UTF-16BEビッグエンディアン不可
UTF-16LEリトルエンディアン不可
UTF-32ビッグ/リトル可
UTF-32BEビッグエンディアン不可
UTF-32LEリトルエンディアン不可
UTF-8
詳細は「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の使用は非推奨[10]。
UTF-16
詳細は「UTF-16」を参照UTF-16符号化方式では、通常はファイルの先頭にバイト順マーク (BOM) が付与される。BOMとは、通信やファイルの読み書き等、8ビット単位の処理でバイト順を識別するための印であり、データストリームの先頭に付与される。値はU+FEFF。システムが読み込んだ先頭2バイトが FF FEならリトルエンディアン、FE FFならビッグエンディアンとして後に続く文書を処理する。.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation.cs-ja1 q,.mw-parser-output .citation.cs-ja2 q{quotes:"「""」""『""』"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free a,.mw-parser-output .citation .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited a,.mw-parser-output .id-lock-registration a,.mw-parser-output .citation .cs1-lock-limited a,.mw-parser-output .citation .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/d/d6/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription a,.mw-parser-output .citation .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/a/aa/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("//upload.wikimedia.org/wikipedia/commons/4/4c/Wikisource-logo.svg")right 0.1em center/12px no-repeat}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:#d33}.mw-parser-output .cs1-visible-error{color:#d33}.mw-parser-output .cs1-maint{display:none;color:#3a3;margin-left:0.3em}.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}RFC 2781
UTF-32
詳細は「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Ω語?
41CEA9E8AA9EF09F988A
UTF-16BEAΩ語?
004103A98A9ED83DDE0A
UTF-16LEAΩ語?
4100A9039E8A3DD80ADE
UTF-32BEAΩ語?
00000041000003A900008A9E0001F60A
UTF-32LEAΩ語?
41000000A90300009E8A00000AF60100
その他
UTF-7
詳細は「UTF-7」を参照UTF-16で表したUnicodeをBase64で変換して表す符号化方式。ただし、ASCIIのアルファベット範囲等についてはBase64に変換しない等、特殊な符号化方式を行う。RFC 2152で定められており、Unicode規格及びUnicodeの関連規格には含まれない。かつてのSMTP等のように、7ビット単位でしかデータを扱えない通信方式を利用する場合を想定して作られている。ステートフルエンコーディングであり、運用上問題が多いため、現在ではこの方式は推奨されていない。Unicode文字を7ビット単位伝送通信にどうしても通さなければならない場合は、替わりにUTF-8をQuoted-printableあるいはBase64で変換するなどの方式が好ましい。
以下はエイプリルフールに公開されたジョークRFCである (RFC 4042)。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ビットで識別するため、代用符号位置は使わない。