文字コード講座は 14 レッスンの対話形式チュートリアルで、開発中に何度も現れるのにほとんど誰もはっきり説明してくれない疑問に答えます。漢字 1 文字は結局何バイトなのか。なぜ "😀".length は 2 なのか。Base64 の末尾の = は何のためか。文字化けはファイルが壊れたのか、それとも救えるのか。各レッスンには自由に書き換えられるテストテキストと、いくつかのビューが用意されます。各文字のビット、バイト、Unicode コードポイント、UTF-8 のバイト単位の分解、Base64 の 6 ビット分割、URL パーセントエンコード、そして「別の符号化で読むと何が見えるか」です。目標はある数を読み取る、ある 16 進数文字列を書く、条件を満たす文字を入力することで、判定がその場で付きます。

講座の順序は文字コードの歴史そのものです。ビットとバイト → ASCII の 128 の取り決め → Unicode が各文字に番号を振る → UTF-8 が番号を 1 から 4 バイトへ変える → UTF-16 と JavaScript の文字列長 → Base64 がバイトをプレーンテキストへ運ぶ → URL エンコード → 最後の 2 レッスンは文字化けに特化し、それがどう生じるのか、浣犲ソ からどうやって 你好 を逆算するのかを扱います。

学習時間は約 40 分。フロントエンドとバックエンドの開発者、データ処理に携わる人、そして文字化け、Base64、絵文字の長さに悩まされたことのあるすべての人に向いています。必要なのは 2 進数が数えられることだけです。

1. 01目標とテストテキストを見る各レッスンの上部が目標です。テストテキストの欄にはそのレッスンのサンプルがあらかじめ入っており、好きな内容に変えられます。すべてのビューはすぐに再計算されます。
2. 02ビューを読むそのレッスンに関係するビューが展開されます。「ビット」ビューは各文字を 8 ビットずつ表示します。「コードポイント」ビューは U+ 番号と UTF-16 コード単位を並べます。「UTF-8 分解」は各バイトをプレフィックスビットとペイロードビットに分けて色分けします。「Base64 分割」は 3 バイト → 4 文字の並びで示します。「URL エンコード」はどの文字が %XX になったかを示します。「別の符号化で読む」は同じバイト列を GBK、Latin-1、UTF-16 として読んだ姿を表示します。
3. 03解答するほとんどのレッスンは答えの欄に数値、16 進数、文字列を入力します。少数のレッスンはテストテキスト自体を条件を満たす内容に変える必要があります（例:「ちょうど 1 つの 3 バイト文字」）。1 つのレッスンは選択式です。
4. 04判定結果バーが合否、またはどこが違うかをその場で示します。16 進数の答えは大文字小文字と空白を区別しません。
5. 05ヒント・答え・進捗「ヒント」は考え方を示し、「答えを見る」は参考解答を表示して入力できます。進捗はこのブラウザーに保存され、?lesson=n で特定のレッスンへ直接移動できます。

第 6 レッスン「UTF-8 の 2 バイト」は café をサンプルに、é の 2 バイトを書かせます。

第 14 レッスン「文字化けの逆算」は GBK として読まれた文字化け 浣犲ソ を示し、テストテキストから元の文を探させます。

文字   コードポイント  2 進のコードポイント  UTF-8 テンプレート      バイト
c      U+0063    1100011             0xxxxxxx                63
a      U+0061    1100001             0xxxxxxx                61
f      U+0066    1100110             0xxxxxxx                66
é      U+00E9    000 1110 1001       110xxxxx 10xxxxxx       C3 A9
                 → 11 ビットのペイロード 00011 101001 をテンプレートへ → 11000011 10101001
答え   C3 A9   ✓

テストテキスト  中文      UTF-8 バイト  E4 B8 AD E6 96 87    GBK で読む → 涓枃
テストテキスト  你好      UTF-8 バイト  E4 BD A0 E5 A5 BD    GBK で読む → 浣犲ソ   ← 問題と一致
答え            你好   ✓

第 1 レッスン: ビットとバイト

計算機にあるのは 0 と 1 だけです。1 ビット（bit）は 1 つのスイッチで、8 ビットで 1 バイト（byte）になり、$2^8 = 256$ 通りの値を表せます。位の重みを足し合わせると 2 進数が 10 進数になります。01000001 = 64 + 1 = 65。すべての文字は最終的にバイト列であり、「文字コード」とはどの数がどの文字を表すかを定めた表です。表が違えば符号化も違います。

第 2–3 レッスン: ASCII

1963 年の ASCII は 7 ビットで 128 文字を定義しました。0–31 は改行、タブ、ベルなどの制御文字、48–57 は数字の 0–9、65–90 は大文字、97–122 は小文字です。並び方はでたらめではありません。大文字と小文字は 32 だけ違い（2 進数の 6 ビット目）、c | 0x20 で大文字を小文字にできます。数字の文字は 48 を引くと数値になります。16 進数はバイトを読むときの慣用表記で、2 桁がちょうど 1 バイトです。0x48 0x69 = Hi。ASCII が使ったのは 7 ビットだけで、8 ビット目は空いていました。後に各国がこの 1 ビットをそれぞれ埋め（Latin-1、GBK、Shift_JIS……）、互換性がなくなり、これが文字化けの歴史的な根源になりました。

第 4 レッスン: Unicode のコードポイント

Unicode は世界中の文字に統一的な番号を振ります。これをコードポイント（code point）と呼び、U+ に 16 進数を付けて書きます。A は U+0041、中 は U+4E2D、😀 は U+1F600 です。範囲は U+0000 から U+10FFFF までで 17 の「面」に分かれ、よく使う文字はほぼ第 0 基本面（U+0000–U+FFFF）に、絵文字と珍しい漢字は追加面にあります。重要なのは、コードポイントは番号にすぎないという点です。それをバイトにする方法は UTF-8、UTF-16、UTF-32 といった「符号化形式」が決めます。「Unicode」は符号化の名前ではなく、utf-8 のほうが符号化です。

第 5–8 レッスン: UTF-8 の可変長テンプレート

UTF-8（RFC 3629）は 1 つのコードポイントを 1–4 バイトで表し、規則はすべて先頭バイトのプレフィックスに書かれています。

コードポイントの 2 進数をペイロードのビット数まで左に 0 で埋め、x に順に当てはめるとバイトが得られます。é = U+00E9 = 11101001 を 11 ビットに埋めると 00011 101001 になり、2 バイトのテンプレートに入れると 11000011 10101001 = C3 A9 です。

この設計には 3 つの利点があります。ASCII のテキストは UTF-8 で符号化しても1 バイトも変わらない（完全な下位互換）。どの後続バイトも 10 で始まるので、バイト列の途中のどこからでも次の文字の開始位置を見つけられます（自己同期。1 バイト欠けても全体がずれません）。長さの違う符号化が重ならないため、00 のようなゼロバイトは常に U+0000 だけを表します（C 文字列として安全）。代償は漢字が 1 文字 3 バイトになり GBK の 2 バイトより 50% 増えることですが、英字、約物、コードは影響を受けないため、UTF-8 は 98% を超える Web ページの符号化になりました。

第 7、8 レッスンでは 3 バイト文字と 4 バイト文字を自分で入力します。後者は今もよくある落とし穴を明らかにします。MySQL の utf8 文字セットは実際には 3 バイトまでしか対応しておらず、絵文字を保存するとエラーか切り捨てになり、utf8mb4 を使う必要があります。

第 9 レッスン: UTF-16 と .length

JavaScript、Java、C#、Windows API の文字列は内部的に UTF-16 を使い、各コード単位（code unit）は 16 ビットです。基本面の文字はコード単位 1 つ、追加面のコードポイントは 2 つのコード単位に分かれ、これをサロゲートペア（surrogate pair）と呼びます（範囲は D800–DBFF と DC00–DFFF）。そのため "😀".length === 2 となり、"😀".split("") は無意味な半分ずつに切り、str[0] は上位サロゲートを返します。実際の文字数で数えるなら [...str].length（コードポイント単位の反復）、利用者が感じる「1 文字」単位（組み合わせ絵文字や濁点などを含む）で数えるなら Intl.Segmenter を使います。

第 10–11 レッスン: Base64

Base64（RFC 4648）は暗号化ではなく、任意のバイトを 64 個の印字可能な ASCII 文字（A–Z a–z 0–9 + /）へ変換する運搬方法です。テキストしか受け取らない場所——メールの添付、JSON のフィールド、data: URL、JWT——にバイナリを詰め込むためです。やり方は、3 バイト = 24 ビットを 6 ビットずつ 4 つに切り（$2^6 = 64$）、それぞれを表で引いて 1 文字にします。Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u。このためサイズは元の 4/3 に膨らみます。

バイト数が 3 の倍数でない場合、最後の組が足りません。1 バイト足りなければ = を 1 つ、2 バイト足りなければ = を 2 つ補い、出力長が常に 4 の倍数になるようにします。A は 1 バイト 8 ビットを 0 で 12 ビットまで埋め、010000 01(0000) に切って QQ となり、== が付きます。URL-safe 版は + / を - _ に置き換え（URL 内でエスケープされないように）、= を省略することが多く、復号時は長さに応じて補います。

第 12 レッスン: URL パーセントエンコード

URL の中でそのまま置ける ASCII 文字はごく一部です（RFC 3986 §2）。空白、&、=、?、/ のような構文上の意味を持つ予約文字、およびすべての非 ASCII 文字は、% + バイトの 16 進数で書く必要があります。つまり URL エンコードはまず UTF-8、次にバイトごとに % を付ける処理です。中 → E4 B8 AD → %E4%B8%AD となり、漢字 1 文字が 9 文字に変わります。JavaScript では encodeURIComponent がもっとも徹底して符号化し（/ ? & = も符号化します）、パラメーター値に入れるのに向いています。encodeURI は構造文字を残すのでアドレス全体に向きます。フォーム送信の application/x-www-form-urlencoded はさらに空白を + と書きますが、これは HTML フォームの歴史的な取り決めで、RFC 3986 の一部ではありません。

第 13–14 レッスン: 文字化けはどこから来て、どう救うか

文字化けはデータの破損ではなく、書くときに符号化 A、読むときに符号化 B を使った結果です。UTF-8 の 中 は E4 B8 AD です。

• Windows-1252 / Latin-1（1 バイト 1 文字）として読むと、3 バイトが 中 という 3 つの西ヨーロッパの文字になります。アクセント記号付きの文字列は「UTF-8 を西欧の符号化として読んだ」印です。
• GBK（2 バイト 1 漢字）として読むと、E4 B8 が漢字 涓 になり、残りの AD は半分だけになります。「奇妙な漢字 + 半分の文字」は「UTF-8 を GBK として読んだ」印で、浣犲ソ や 涓枃 はこの類です。
• 逆に GBK のテキストを UTF-8 として読むと、不正なバイト列のところで置換文字 �（U+FFFD）が大量に現れます。

元のバイトさえ失われていなければ、正しい符号化で読み直せば文字は元どおりになります。したがって文字化けを直す第一原則は、元のファイルを残し、変換を繰り返さないことです。変換のたびに不正なバイトが ? や � に置き換わり、それこそが本当の情報の消失になります。第 14 レッスンでは逆向きの作業をします。文字化けした 浣犲ソ を GBK としてバイト E4 BD A0 E5 A5 BD に戻し、それを UTF-8 として読んで 你好 を取り出します。現代的なやり方は、HTTP ヘッダー、HTML の <meta charset>、データベース接続、ファイル保存ダイアログでUTF-8 を統一して宣言し、取り違えが起きる隙を作らないことです。

BOM とバイト順

UTF-16 にはビッグエンディアンとリトルエンディアンの 2 つのバイト順があり、ファイルの先頭にバイト順マーク BOM（FE FF または FF FE）を置くことがよくあります。UTF-8 にバイト順の問題はありませんが、Windows のメモ帳がかつて UTF-8 の BOM EF BB BF を既定で書き込んだため、シェルスクリプトの 1 行目がエラーになったり、CSV の最初の列名の前に見えない文字が入ったりしました。講座の UTF-8 分解ビューで先頭にこの 3 バイトがあれば、出所が分かります。

符号化

ASCII、UTF-8、UTF-16、Base64、URL エンコードを詳しく扱います。GBK と Windows-1252 は文字化けのデモ専用で、ブラウザーの TextDecoder に依存します。GB18030、Big5、Shift_JIS の内部構造は扱いません。

Unicode の発展事項

正規化（NFC/NFD）、結合文字列、双方向テキスト、書記素クラスタの境界アルゴリズムは扱いません。絵文字の肌色修飾と ZWJ の組み合わせはヒントで触れるだけです。

Base64

標準と URL-safe の 2 つの字母表のみを扱います。Base32、Base16、MIME の 76 文字ごとの改行規則は扱いません。

判定方法

16 進数の答えは大文字小文字と空白を区別しません。「文字を入力する」タイプのレッスンは UTF-8 のバイト数と文字数で判定し、条件を満たす文字ならどれでも許します。

やらないこと

一括変換ツールではありません（実データを処理するなら「Base64 変換」「URLツール」を使ってください）。ファイルの符号化を検出したり、アップロードされたファイルを修復したりもしません。

• 「Unicode は符号化の一種」: Unicode は文字集合（番号表）で、UTF-8 / UTF-16 が符号化です。Windows のメモ帳の「Unicode で保存」は実際には UTF-16 LE です。
• 「漢字は 1 文字 2 バイト」: GBK では 2、UTF-8 では 3、UTF-16 では基本面が 2 で、拡張 B 面の珍しい字は 4 です。まず「どの符号化か」を問いましょう。
• 「Base64 は暗号化」: 誰でも復号できます。表現を変えているだけなので、機密性が必要なら本物の暗号化を使ってください。
• 「文字化けしたらファイルが壊れた」: ほとんどの文字化けは読み方が違うだけで、符号化を変えて開き直せば直ります。本当に文字が失われるのは「変換」を繰り返したときです。
• 「length は文字数」: JavaScript では UTF-16 のコード単位数で、絵文字や一部の珍しい字は 2 と数えます。データベースの VARCHAR(n) の n も、製品によってバイト数だったり文字数だったりします。
• 「URL に日本語をそのまま書けばよい」: ブラウザーのアドレスバーは代わりに符号化して表示しますが、リクエストを組み立てるときは encodeURIComponent が必要です。そうしないと &、#、空白が構造を壊します。

講座はすべてブラウザー内で動作します。テストテキストの符号化・復号、Base64、URL エンコードはページ内の TextEncoder / TextDecoder と純粋な関数で行われ、どのサーバーにも送信されません。クリア状況は端末の localStorage に保存されます。

• F. Yergeau、RFC 3629、UTF-8, a transformation format of ISO 10646（2003）——4 つのバイトテンプレート、自己同期性、正しい並びの定義。講座の第 5–8 レッスンの根拠: https://www.rfc-editor.org/rfc/rfc3629（参照日：2026-09-09）
• S. Josefsson、RFC 4648、The Base16, Base32, and Base64 Data Encodings（2006）——Base64 の字母表、パディング規則、URL-safe 版。§10 のテストベクターは講座の単体テストから直接参照しています: https://www.rfc-editor.org/rfc/rfc4648（参照日：2026-09-09）
• T. Berners-Lee ほか、RFC 3986、Uniform Resource Identifier (URI): Generic Syntax、§2.1 Percent-Encoding と §2.2 予約文字: https://www.rfc-editor.org/rfc/rfc3986#section-2.1（参照日：2026-09-09）
• The Unicode Consortium、The Unicode Standard、Core Specification、Chapter 2 General Structure（コードポイント、面、符号化形式、サロゲートペア）: https://www.unicode.org/versions/latest/（参照日：2026-09-09）
• WHATWG、Encoding Standard——ブラウザーの TextDecoder が対応する符号化とその復号アルゴリズム。講座の文字化けデモが使う GBK / windows-1252 デコーダーの規範: https://encoding.spec.whatwg.org/（参照日：2026-09-09）
• Joel Spolsky、The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（2003）——「プレーンテキストなど存在しない」という古典的入門: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/（参照日：2026-09-09）