UTF-8 は Unicode を実装するための可変長文字エンコーディングです。RFC 3629 (2003 年 11 月・Internet Standard STD 63) で、U+0000 から U+10FFFF までの文字を 1〜4 バイトの列で符号化する方式として定義されています。ASCII (英数字・記号) と完全な互換性を保ちながら、Unicode に収録された文字を表現できます。W3Techs の利用状況調査では、文字エンコーディングが判明している Web サイトのうち 2026 年 8 月時点で 99.0% が UTF-8 を使用しており、Web における事実上の標準文字コードです。

UTF-8 のバイト数は文字の種類によって異なります。ASCII (U+0000〜U+007F) は 1 バイト、ラテン文字の拡張やキリル文字 (U+0080〜U+07FF) は 2 バイト、日本語・中国語・韓国語の漢字やひらがな・カタカナ (U+0800〜U+FFFF) は 3 バイト、絵文字や CJK 統合漢字拡張の漢字 (U+10000〜U+10FFFF) は 4 バイトです。なお UTF-16 のサロゲート用に予約された U+D800〜U+DFFF は、UTF-8 では符号化できません。この可変長設計により、英語テキストは ASCII と同じサイズで格納でき、多言語テキストも無駄なく表現できます。

UTF-8 が Web 標準として普及した理由は複数あります。ASCII 互換性があるため、既存の ASCII ベースのプロトコル (HTTP、SMTP、URL) やツールがそのまま動作します。バイトオーダー (エンディアン) の問題がなく、BOM (バイトオーダーマーク) が不要です。また、バイト列の途中からでも文字境界を特定できる自己同期性を持ち、データの破損に強い設計になっています。実務で引っかかりやすいのは、BOM 付きで保存されたファイルが混ざるケースです。先頭に見えない 3 バイト (16 進で EF BB BF) が入るため、設定ファイルや JSON の解釈に失敗する、CSV の 1 列目の見出し名が一致しない、といった症状が出ます。

HTML では <meta charset="UTF-8"> で文字コードを宣言します。この宣言がないと、ブラウザが文字コードを誤判定して文字化けの原因になります。HTTP レスポンスヘッダーの Content-Type: text/html; charset=utf-8 でも指定でき、両方に書いておくとファイルを単体で開いたときにも宣言が効きます。ここでの判断基準は優先順位です。ヘッダーの指定はブラウザの判定で meta より先に採用されるため、両者が食い違っている場合は meta タグをいくら直しても表示は変わりません。文字化けを追うときは、まずヘッダーが何を返しているかを確認します。

データベースでは UTF-8 の扱いに注意が必要です。MySQL の utf8 は 3 バイトまでしか扱えない utf8mb3 の別名で、2026 年 8 月時点の 8.4 系リファレンスではこの別名も utf8mb3 自体も非推奨とされ、将来のメジャーリリースで削除される見込みと案内されています。推奨は utf8mb4 です。3 バイト止まりの文字セットでは絵文字や「𠀋」のような拡張領域の漢字を格納できず、登録時にエラーになるか文字が失われます。人名の異体字や絵文字を含む投稿を受け付ける設計なら、稼働後に変換するより初期設定で utf8mb4 を選ぶほうが安全です。PostgreSQL の UTF8 は最初から 4 バイトに対応しています。

文字数カウントとの関連では、UTF-8 のバイト数と文字数の違いを理解することが重要です。「こんにちは」は 5 文字ですが、UTF-8 では 15 バイト (3 バイト × 5 文字) です。絵文字が 1 個混ざれば、文字数は 1 しか増えないのにバイト数は 4 増えます。データベースのカラムサイズやファイルサイズ、API のリクエスト上限はバイト数で指定されることが多いため、文字数だけを見て設計すると上限をまたいだ時点で初めて弾かれます。日本語で書かれた文章は文字数の 3 倍前後がバイト数になると見積もり、絵文字や拡張漢字を含む場合はさらに余裕を持たせておくと、投稿や保存の失敗を避けられます。