乱立する日本語文字コードについて，簡単に調査した． 詳しくは“文字コードの話”と“文字コード問題を考える”が参考になる．
ひとくちに「文字コード」と言っても，実際には「文字セット」と「それをエンコーディングして使う方法」を分けて考える必要がある．
まず代表的な文字セットについて概観する．
ASCIIは，1962年に制定された7bitの文字コード（全部で128字分のスペース）． 最初の32字は制御コードに割り振られ，空白（0x20），94字のキャラクタ，制御文字DELで構成される．
その後，一部の文字を変更することで他国語もサポートするためのに制定されたのが，ISO 646． ISO 646の日本語版では，以下のような変更をASCIIコードに加えている（文字化けの起源？）．
| 0x5C | ＼（バックスラッシュ） | ￥（円記号） |
| 0x7E | ～（チルダ） | ￣（オーバーラン） |
ISO 646を拡張した8bit文字コード（全部で256字のスペース）． 新たな128字分のスペース（制御文字32字＋96字）に各国語の文字を入れる． 数ある拡張の中で，通称「Latin-1」と呼ばれるISO 8859-1が最もポピュラー．
日本語版ISO 8859と呼べるJIS X 0201では，新たなスペースにカタカナが割り振られた（1969年）．
94区×94点=8836字分のスペースを定義しているため，区点コードと呼ばれている． 第一水準漢字と第二水準漢字，ならびにギリシャアルファベットや罫線素片など，6879字（漢字は6349字）を収録． 1978年に制定された「旧JIS」と，1983年に改訂された「新JIS」ではいくつかの変更点があり，混乱を生じている． その後，1990年，1997年の改訂を経て現在に至っている． 現在の97JISでは，第一水準2965，第二水準3390（3384から6つ増えた）の6355漢字を中心に合計6879字．
2001年10月現在，“表外漢字字体表”（常用漢字表に含まれない（表外の）漢字字体について，印刷標準字体と簡易慣用字体を制定したもの）とJIS X 0208の例示字体の間で整合をとる作業が進められている．
区点コードによる5801字の補助漢字を1990年に制定． 第二水準に入らなかった，人名や旧漢字が含まれる． 後述するUnicodeで採用され，現在のWindowsマシンには標準でサポートされている． 例えば，「森鴎外」を「森鷗外」と正しく表記するためには，補助漢字が必要になる（IE6+英語版Windows2000で表示を確認）．
第三水準1249字と第四水準2436字の合計3685字を中心とした4344字で，97JISを拡張する目的で2000年に制定された． JIS X 0212と重複する漢字が多数含まれているため，以下のように少々複雑な状況を生み出している． “文字の海、ビットの舟”に情報あり．
| 0212 ∩ 0213 | 補助漢字と重複しているため，UnicodeベースのWindowsNT/2000/XPで扱える． |
| 0212 ∩ 0213 | 第三水準・第四水準に含まれる漢字であるが，UnicodeベースのWindowsNT/2000/XPでは扱いにくい．ただし，中国語や韓国語の漢字として別途Unicodeに登録されていれば，結果として使える． |
| 0212 ∩ 0213 | 第三水準にも第四水準にも含まれない漢字であるが，補助漢字としてUnicodeベースのWindowsNT/2000/XPで扱える． |
実はJIS X 0213では，既存のエンコーディング技術との整合性がよく考慮されており，後述するShift_JISやEUCでも扱えるようになっている． 2面×94区×94点の構成で，第1面には，0208の隙間を埋める形で0213の漢字が1908字収録され，第2面に残りの2436字が収録されている． 2×94×94を満タンにしていないのは，Shift_JISとEUCで問題の起きる領域を回避した結果である． しかし，既存のエンコーディング法との対応がとれても，コンピュータ内部での処理がUnicodeに統一されつつある現状では，Unicodeで扱えなければ不便なままである． いずれは正式にUnicodeに取り込まれるとしても，既に取り込まれているJIS X 0212との重複や，中国語・韓国語との関係など，あまりすっきりしない構成になる可能性が高い．
上記は，7bit，8bit，94×94という狭いスペースに文字を埋め込むアプローチであり，メモリが貴重だった頃の発想という位置付けもできる． これに対して，膨大なスペースを定義して大量の文字情報をまとめて扱おうとするアプローチが流行っている．
1993年に制定されたISO 10646（日本では1995年にJIS X 0221として制定）では，万国文字集合としてUCS-4（Universal multi-octet Character Set）とUCS-2を定義している． UCS-4は，31bit（約4byte）で128群×256面×256区×256点というスペースを定義している． 一部の予約領域（群0x00の面0xE0～0xFF，群0x66～0x7F）を除くと，合計約16億字を扱うことが可能となる． 97JIS+2000JISで合計1万字程度であるが，UCS-4では約16億字を扱うことができる．
群0x00面0x00をBMP（Basic Multilingual Plane：基本多言語面）と呼び，これを2byte（16bit：最大65536字）で表したのがUCS-2である． ISO 8859-1（Latin-1）互換であり，漢字では中国・日本・韓国（CJK)の漢字を統合した約21000字が含まれている． 日本語は，JIS X 0208とJIS X 0212（補助漢字）が基になっている（JIS X 0213は後からできた規格なので入っていない）． いわゆる“Unicode”は「UCS-2とほぼ同じもの」と説明されている．
文字鏡研究会の成果として，日本・中国・台湾・韓国・ベトナムの漢字10万字をはじめ，梵字・甲骨文字など12万字が収録されている． “文字鏡WEB”に情報あり．
日本学術振興会（G）と東大（T）による研究成果として，漢字66700字を扱える． “東京大学他国語処理研究会”や“オープンテキスト”に情報あり．
GT書体フォントや大漢和辞典収録文字などを含めて，合計17万字を扱える． 文字セットではなくて立派なOS． “超漢字ウェブサイト”に情報あり．
上記の文字セットを，実際にコンピュータで扱うためにエンコーディングする方法を概観する．
ISO 2022は，7bitもしくは8bitの狭いスペースを切り替えて使うことにより，より多くの文字を取り扱うための規格．
| 0x00～0x1F | C0領域 | 制御文字32字 |
| 0x20～0x7F | GL領域 | 図形文字96字 |
| 0x80～0x9F | C1領域 | 制御文字32字（8bitの場合） |
| 0xA0～0xFF | GR領域 | 図形文字96字（8bitの場合） |
以上のように領域分けして，GLやGRに入れる文字を切り替える． 空白（0x20），DEL（0x7F）を半固定的と考えれば，94文字分の切り替えになる． 例えばJIS X 0208の場合は，94区×94点なのでGLの文字2つ（2byte）で表すことになる． 切り替えは，G0，G1，G2，G4の4つの中間バッファをGLやGRに呼び出す形で行う． この呼び出しには，次の切り替え指令があるまで固定する“ロッキングシフト”と一文字だけ切り替える“シングルシフト”の2種類が用意されている． 各バッファに対応する文字セットは“エスケープシーケンス”で指示をする．
インターネットで，日本語のメイルやネットニュースに使われているコード体系．
G0をGLに固定的に呼び出す． G0にはJIS X 0201のASCII文字を対応させ，適宜JIS X 0208，0212，0213などの漢字セットをG0に対応させる． 8bitの場合，JIS X 0201のカタカナはG1に対応させてGRに呼び出す（7bitの場合は，G0に対応させるか，G1に対応させてGLに呼び出す）． シングルシフトを使わず，呼び出しはすべてロッキングシフトに限定されている． すなわち，中間バッファとGLの関係は固定的で，中間バッファと文字セットの対応を変更することで切り替えを実現する方式である．
その特徴は，7bitの通信路にも対応していることであり，これがE-Mailでの標準エンコーディング法として採用されている理由である． エスケープシーケンスを利用するため，コンピュータの内部コードとしては扱い難い（ASCII文字に相当するコードが出てきても，現在のモードを確認しないと文字の種類が分からない）．
Extended UNIX Codeの名の通り，UNIXの日本語環境でよく使われるコード体系．
G0にASCII，G1にJIX X 0208漢字（隙間を縫うようにJIS X 0213も），G2にJIS X 0201カタカナ，G3にJIS X 0212補助漢字（隙間を縫うようにJIS X 0213も）を固定的に対応させる（したがってエスケープシーケンスを用いない）． G0をGLにG1をGRに呼び出しておき，G2とG3はシングルシフトで使用する． すなわち，中間バッファと文字セットの対応は固定的で，呼び出し（しかもシングルシフト）で切り替えを実現する方式である．
半角カタカナが，補助漢字と同じレベルの扱いを受けているため，サポートされていない場合が多い． インターネットで半角カタカナの使用を嫌う理由はここにある． ロッキングシフトを許しておらず，各文字の最初の1byteを見れば文字種を特定できる（modeless, stateless）ため，扱いやすい．
Microsoftとアスキーが定めたコード体系． Windows95/98/Meでは，コンピュータ内部でもShift_JISのまま処理をしている．
8bit時代のJIS X 0201（ASCIIと半角カタカナ）をそのまま継承することで，互換性を保ったまま漢字時代へと導いた． 漢字は2byteで表すが，隙間を縫うように第1バイト（0x81～0x9F，0xE0～0xFC：ASCIIや半角カタカナを回避），第2バイト（0x40～0x7E，0x80～0xFC；区切り文字や制御文字を回避）を組み合わせる．
EUCと同じく，エスケープシーケンスを用いない，各文字の1byte目で文字種を特定できるという特徴がある． また，隙間を縫った結果として，日本語非対応のシステムでも何とか通過できることが多い． 日本語処理の黎明期に漢字処理をスムーズに実現した功績は大きいが，拡張性がなさが致命的で，今後の国際化・多言語処理の流れには対応できない．
i-modeでもShift_JISが用いられているが，外字領域に独自の絵文字をマッピングしてしまっているという問題がある．
UCSを安全に伝送するためにエンコーディングする． ASCIIは1byteで送り，それ以外を制御文字を避けながら数byteで表す．
UCS-2/4の1文字を1～6byteの可変長バイト列で表す． ただし，非ASCII文字はGR相当のコード（0xA0～0xFF）を用いる． UTF-FSS（File System Safe）という別名は，ファイル名に使ってもパス名の区切り文字（UNIXではスラッシュ，Windowsではバックスラッシュ）と誤認されないところから来ている．
先頭にBOM（Byte Order Mark）を入れるUTF-8に対して，入れない場合を“UTF-8N”と呼ぶ． WebページはUTF-8Nで作る方が安全だが，エディタの多くはBOMを含めるため，少々混乱している．
7bitの通信路にも対応するための特殊な規格．
UCS-2で21000の漢字が使えることは，これまでの状況に比較すると便利にはなっているが，将来的に各国の文化を尊重し，網羅的に文字を追加していくには2byte（65536字）ではあまりに心細い． そこで“サロゲートペア”という拡張が図られている． 具体的には，0xD800～0xDBFFの1024字分のスペースと，0xDC00～0xDFFFの1024字分のスペースを組み合わせて（2byte+2byteの4byte文字として扱って），合計約100万字分のスペースを捻出している． この100万字は，UCS-4における群0x00の面0x01～0x10に相当するものとされている．
UTF-8は，ASCII文字にUCS-2を埋め込むエンコーディング法であるのに対して，UTF-16はUCS-2の中にUCS-4の一部を埋め込むエンコーディング法であると捉えることができる．
これにより「文字数が足りない」という問題は大幅に改善されているが，真の“万国文字集合”を謳うには，各言語の構造的な問題への取り組みが課題として残されている．
拡張性という意味でShift_JISの未来は暗い． 一般ユーザにとっては，Unicodeが今後のベースになってくる可能性が高い． しかし，MicrosoftがWindowsNT/2000/XPで推進するUnicodeに対する最大の抵抗勢力は，言ってみればこれまたMicrosoftのShift_JISであると言える（莫大なテキスト資源を残しており，i-modeでも採用された）． 逆に，JavaなどはUnicode支援の立場である．
一方，超漢字など大きな文字セットを扱う環境は，やっと試して議論できる状況が整ってきたところである． 今後，さらに深い議論に発展し，コンピュータの世界を変えていって欲しい．
とりあえずWebページで使う文字コードは，現状ではShift_JISにしておくのが安全だろう． 最も多くの人に閲覧してもらうことができる． UTF-8Nでは，漢字が3byteで表されるため，2byteで表してくれるShift_JISより効率が悪いのも確かである． しかし，使える字体が多いという魅力と，今から将来の暗いテキスト資源を作るのが好きになれないという，個人的な嗜好でUTF-8Nを選んでしまうのであった…．
