Unicode
文字コードは、Unicode文字符号化モデルによると以下の4段階に分けられる:
また、符号空間のうち代用符号位置を除く符号位置をUnicodeスカラ値という。
収録されている文字は、各国で標準として規定されている文字集合や実際に使用されている文字を持ち寄り、委員会により取捨選択されている。日本の文字については当初よりJIS X 0201、JIS X 0208、JIS X 0212を、Unicode 3.1からはJIS X 0213の内容も収録している。
また収録において、元の各文字集合内で分離されている文字は尊重するが、異なる文字集合に同一の文字が収録されているとみなされるものは、同じ符号位置に割り当てる方針を取っている。この際に集合が膨大であるという理由で、漢字について、中国、日本、韓国の各規格の漢字を統合しCJK統合漢字としたことは大きな議論となった。
現在では独自創作の絵文字の追加等、当初の目的である「各国・各社の文字コードの統合」から外れた動きも進んでいる。
Unicodeに収録されている文字については、「ブロックの一覧」を参照。
Unicodeは世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られ、Unix、Windows、macOS、Plan 9などの様々なオペレーティングシステムでサポートされている。Javaや.NETのようなプログラミング環境でも標準的にサポートされている。現代の文字だけでなく古代の文字や歴史的な文字、数学記号、絵文字なども含む。
Unicode以前の文字コードとの相互運用性もある程度考慮されており、歴史上・実用上の識別が求められる場合には互換領域がとられ、元のコード→Unicode→元のコードというような変換(ラウンドトリップ変換)において、元通りに戻るよう配慮されている文字もある。しかし、正規のJIS X 0208の範囲内であればトラブルは少ないが、複数の文字集合が混在していたり、文字集合の亜種ごとにマッピング(対応づけ)が異なる文字(機種依存文字)を含んでいたりする場合、変換テーブルによるマッピングが不可逆変換となり文字化けを起こすことがある。
そうなると、Unicode 環境では円記号がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの 0x5C の位置には円記号の字形を当ててしまうことで対処している。これによって、日本語環境での表示上は 0x5C の位置で円記号を用いることができる。
この問題は日本語環境に限ったことではない。もともと ISO 646 上では、0x5C を含む数種の文字は自由領域(バリアント)として各国での定義を認めていた。そのため、日本語以外でも ASCII でバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、韓国では通貨のウォン記号 (WON SIGN, U+20A9, "₩")、デンマークやノルウェーではストローク付きO (LATIN CAPITAL LETTER O WITH STROKE, U+00D8, "Ø") などである。(後者は後の時代には、0x5C はバックスラッシュのままとし、ISO 8859 シリーズを用いることが一般化した。)