文字コード (character encoding) は、コンピュータが文字を扱うための根幹技術です。人間が読む「A」や「あ」を、コンピュータが処理できる数値に変換する規則を定めています。この変換規則がなければ、テキストの保存も送信も表示もできません。

文字コードは 2 つの層に分けて理解すると明快です。第一層は「文字集合」(character set) で、どの文字を扱うかを定義します。ASCII は 128 文字、JIS X 0208 は 6,879 文字 (漢字 6,355 字と非漢字 524 字)、Unicode は 15 万字以上 (2025 年 9 月に公開された 17.0 で 159,801 文字) をカバーします。第二層は「符号化方式」(encoding scheme) で、文字集合の各文字をどのようなバイト列で表現するかを定めます。同じ Unicode という文字集合に対して、UTF-8、UTF-16、UTF-32 という異なる符号化方式が存在するのはこのためです。文字化けの原因を切り分けるときは、「その文字が文字集合に無い」のか「符号化方式の解釈を間違えている」のかで対処が変わるため、この 2 層を分けて考えると原因に早く届きます。

日本語の文字コードには複雑な歴史があります。1978 年に JIS C 6226 (後の JIS X 0208) が制定され、制定当時の収録字数は 6,802 字で、その後 1983 年・1990 年・1997 年の改正を経て現在の字数になりました。これを基に Shift_JIS (PC 向けに策定され「MS 漢字コード」とも呼ばれる)、EUC-JP (UNIX 系で普及)、ISO-2022-JP (電子メール用) が生まれました。3 つの符号化方式が同じ文字集合を異なるバイト列で表現するため、相互変換が文字化けの原因になりました。

現在は Unicode + UTF-8 への統一が進んでいます。UTF-8 は ASCII と完全な後方互換性を持ち、英語テキストは 1 バイト/文字、日本語は 3 バイト/文字で表現します。この可変長設計により、ASCII 圏のシステムとの互換性を保ちながら世界中の文字を扱えます。W3Techs の利用状況調査では、文字エンコーディングが判明している Web サイトのうち 2026 年 8 月時点で 99.0% が UTF-8 を使用しています。新規に作るシステムで UTF-8 以外を選ぶ理由は、既存システムとの入出力を Shift_JIS や EUC-JP に合わせなければならない場合にほぼ限られます。

文字数カウントにおいて文字コードの理解は必須です。同じ「あ」でも UTF-8 では 3 バイト、Shift_JIS では 2 バイト、UTF-32 では 4 バイトです。「文字数」と「バイト数」が一致するのは ASCII の範囲内だけであり、日本語の文字を含むテキストでは両者が一致しません。データベースの VARCHAR(255) が「255 文字」なのか「255 バイト」なのかは製品と設定によって変わるため、桁数を決める前にどちらの単位で数えるかを確かめておきます。バイト単位で数える設定に日本語を入れると、255 バイトでは 85 文字前後しか入らず、超えた分は保存時に切り詰められるか登録が失敗します。

実務上の注意点として、レガシーシステムとの連携では Shift_JIS や EUC-JP への変換が必要になる場面がまだあります。この際、Unicode にあって Shift_JIS にない文字 (絵文字、CJK 統合漢字拡張の漢字、人名に使われる異体字など) は変換できず、「?」や「〓」(ゲタ記号) に置き換わります。文字コード変換は情報の損失を伴う可能性がある不可逆な操作です。変換をシステムに組み込むときは、置き換えが起きた文字をエラーとして検出するか、代替表記の対応表をあらかじめ決めておくと、気付かないまま氏名や住所が化けた状態で保存される事故を防げます。