文字コードとエンコーディングの基礎
「文字化けした！」というときは、文字コードとエンコーディングを整理すると原因が見えてきます。ここではUTF-8/UTF-16/BOMの違いと、CSVなどでハマりやすいポイントをコンパクトにまとめます。
まず押さえるポイント
文字コードは「文字→数値」の対応表、エンコーディングは「数値→バイト列」の詰め方です。
文字コードとエンコーディング
- UTF-8/UTF-16はUnicodeをバイト列にする方法（可変長の詰め方）が異なる。
- UTF-8はASCII互換で、英数字は1バイトのまま。多言語混在でも扱いやすくWebの標準。
- UTF-16は1つのUnicodeスカラー値を2バイトまたは4バイトで表す。ASCIIのAはUTF-8で1バイト、UTF-16で2バイト。U+3042はそれぞれ3バイトと2バイト。サイズの大小は文章によって変わる（BOMを除く）。
BOM (Byte Order Mark)
- UTF-8のBOMは0xEF 0xBB 0xBF。なくてもよいが、一部ツールはBOMありを前提にすることがある。
- UTF-16のBOMはバイト順を示す。UTF-16LE/UTF-16BEのようにバイト順を明示する方式では、BOMは必須ではない。利用する形式や受信側の仕様に従う。
- BOMを付けてよいかは形式次第。ネットワークで交換するJSONには、RFC 8259により送信側はBOMを付けてはならない。
文字化けの典型パターン
「保存したのと読む側のエンコーディングがズレる」と文字化けします。
よくある原因
- 保存はUTF-8だが、読み手がSJIS/CP932前提で開く（Excelの既定設定など）。
- BOM付きUTF-8を想定していないツールでBOMをデータ扱いしてしまう。
- HTTPレスポンスでContent-Type charsetが誤っている（例: Shift_JISと宣言してUTF-8を返す）。
対処のコツ
- まず元ファイルを保存し、上書きせずに正しい文字コードを指定して開き直す。文字化け状態で保存して文字が置き換わっていると、元に戻せない場合がある。
- 保存側と読み込み側の文字コードをそろえる。変換先で表せない文字を黙って置換しないよう、変換エラーも確認する。
- HTMLではHTTPの文字コード宣言と実際のバイト列をそろえる。JSONのapplication/jsonにはcharsetパラメーターが定義されていないので、すべての形式に同じ宣言を付けるわけではない。
CSVで注意すること
CSVはツールごとの既定エンコーディングがバラバラです。
エンコーディングの落とし穴
- Excelの既定は環境依存（日本語版はCP932が多い）。UTF-8 CSVを開くと文字化けすることがある。
- Microsoftの案内では、UTF-8のCSVはBOM付きなら通常の方法で開ける。BOMなしの場合はデータ取り込みでUTF-8を指定する方法がある。画面の名称は版によって異なる。
- UNIX系ツールやデータ処理基盤はUTF-8前提が多い。BOMなしが扱いやすい。
おすすめの運用
- 内部処理はUTF-8（BOMなし）を基本にする。
- Excel利用者向けに配布する場合はBOM付きUTF-8を用意するか、開き方（データ取り込み）を明記する。
- CSVには汎用的な文字コード宣言欄がないため、添付説明やAPI仕様で明示する。BOMがあっても、区切り文字や列の型まで分かるわけではない。
文字数と関連資料
文字・コードポイント・バイト数は同じではありません。結合文字や絵文字では、見た目の1文字が複数のコードポイントになる場合もあります。