文字コードとエンコーディングの基礎
「文字化けした！」というときは、文字コードとエンコーディングを整理すると原因が見えてきます。ここではUTF-8/UTF-16/BOMの違いと、CSVなどでハマりやすいポイントをコンパクトにまとめます。
まず押さえるポイント 🌐
文字コードは「文字→数値」の対応表、エンコーディングは「数値→バイト列」の詰め方です。
文字コードとエンコーディング
- UTF-8/UTF-16はUnicodeをバイト列にする方法（可変長の詰め方）が異なる。
- UTF-8はASCII互換で、英数字は1バイトのまま。多言語混在でも扱いやすくWebの標準。
- UTF-16は2バイト（サロゲートペアで4バイト）。UTF-8よりサイズが大きくなるケースが多い。
BOM (Byte Order Mark)
- UTF-8のBOMは0xEF 0xBB 0xBF。なくてもよいが、一部ツールはBOMありを前提にすることがある。
- UTF-16ではエンディアン（Big/Little）を示すためBOMが実質必須。
- シェルスクリプトや設定ファイルでBOMがあると誤動作することがあるので注意。
文字化けの典型パターン 🔄
「保存したのと読む側のエンコーディングがズレる」と文字化けします。
よくある原因
- 保存はUTF-8だが、読み手がSJIS/CP932前提で開く（Excelの既定設定など）。
- BOM付きUTF-8を想定していないツールでBOMをデータ扱いしてしまう。
- HTTPレスポンスでContent-Type charsetが誤っている（例: Shift_JISと宣言してUTF-8を返す）。
対処のコツ
- 保存も読み込みもUTF-8で揃える（BOMなしが無難）。
- どうしてもSJIS系が必要な場合は明示して変換し、読み手の設定も案内する。
- HTTPならContent-Typeとcharsetを正しく付ける。HTMLならを入れる。
CSVでハマりやすいところ 📄
CSVはツールごとの既定エンコーディングがバラバラです。
エンコーディングの落とし穴
- Excelの既定は環境依存（日本語版はCP932が多い）。UTF-8 CSVを開くと文字化けすることがある。
- 最近のExcelはBOM付きUTF-8を自動判定するが、BOMなしは判定されないことが多い。
- UNIX系ツールやデータ処理基盤はUTF-8前提が多い。BOMなしが扱いやすい。
おすすめの運用
- 内部処理はUTF-8（BOMなし）を基本にする。
- Excel利用者向けに配布する場合はBOM付きUTF-8を用意するか、開き方（データ取り込み）を明記する。
- ファイルにcharsetを含められないため、添付する説明やAPIドキュメントで明示する。