Unicode
符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係する。
その後、バイト列を、gzipなどで圧縮したり、7ビット伝送路に通すためにBase64やQuoted-printableなどで変換したりすることがあるが、これらは文字コードの管轄範囲外である。
Unicode符号位置を単一の18ビット符号単位で表現する符号化方式。UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた4つの面(BMP、U+1xxxx、U+2xxxx、U+Exxxx)を余った2ビットで識別するため、代用符号位置は使わない。
以下はドラフト段階で破棄された規格案。
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のバージョンには、上記のような「Unicodeの規格全体に付けられたバージョン」の他に「Unicodeを構成する個々の要素の規格に付けられたバージョン」が存在する。これに該当するものとしては、Unicodeを構成する各面ごとに付けられたバージョンや、Unicodeに収録されないこととされたスクリプトのリスト (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に日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている。
符号化の対象とする順序のない文字の集合。