こんにちは、阿久梨絵です！
「UTF-8にしておけば大丈夫」
「 文字コード なんて気にしなくてもいい」
そう思っていた矢先、突然の文字化け。メールが読めない、CSVが開けない、Webページが「アニメーション」になってしまう…。
文字コードは、“読めること”を支える技術の土台です。この記事では、現場で役立つ「文字コードの鉄則」を5つに絞って、やさしく解説いたします。
以下表記上、半角<は、全角＜とします。
① 保存時に文字コードを明示する
ファイルを保存する際には、文字コードを明示的に指定することが基本です。
「自動判定」に頼ってしまうと、環境によってShift_JISになったり、BOM付きUTF-8になったりして、文字化けの原因になります。
おすすめの設定
・Webページ：UTF-8（BOMなし）＋ ＜meta charset=”UTF-8″>
・CSVファイル：UTF-8（BOMあり）で保存し、Excelとの互換性を確保
・テキストファイル：UTF-8固定で保存
② 送受信時はContent-Typeヘッダーを確認する
メールやAPIなどで文字を送信する場合は、Content-Typeヘッダーで文字コードを明示することが重要です。
Content-Type: text/plain; charset=UTF-8
この指定がないと、受信側が「Shift_JISかな？」「ISO-8859-1かも？」と誤解してしまい、文字化けが発生する可能性があります。
補足
・HTMLメールの場合は Content-Type: text/html; charset=UTF-8
・JSON APIの場合は Content-Type: application/json; charset=UTF-8
・サーバー側で明示的に設定することで、受信側の誤判定を防げます。
③ Excelで開くCSVは“罠”が多い
CSVファイルをUTF-8で保存しても、ExcelがShift_JISで開こうとして文字化けすることがあります。
対策方法
・UTF-8（BOM付き）で保存する
・Excelで「データのインポート」機能を使って開く
・Webアプリ側でExcel形式（.xlsx）で出力する
④ データベースの文字コード設定を忘れない
データベースでは、テーブル単位・カラム単位で文字コードを設定する必要があります。
UTF-8で保存したつもりでも、DBの設定がLatin1になっていると「?」や空白になってしまいます。
確認ポイント
・MySQL：CHARACTER SET utf8mb4
・PostgreSQL：ENCODING ‘UTF8’
・SQLite：UTF-8固定（ただし入力元の文字コードに注意）
⑤ ログ・エラーメッセージも文字コードに注意する
ログ出力やエラーメッセージも、文字コードが合っていないと読めなくなります。
特に日本語を含む場合は、UTF-8で統一しておくと安心です。
例
・サーバーログ：UTF-8で出力
・CLIツール：端末の文字コードと合わせる（Windows環境ではShift_JISの可能性も）
まとめ
文字コード は、普段は意識されにくい技術ですが、“読める安心”を支える根幹の仕組みです。
ちょっとした設定ミスが、ユーザーの不安や誤解につながることもあります。
特にメールやAPIなど、人やシステムをまたぐ場面では、Content-Typeヘッダーでの明示が欠かせません。
現場では、「文字コードなんて気にしなくていい」と思わずに、意図的に・丁寧に扱うことが、信頼される情報設計につながります。
「読めること」は、技術者としてのやさしさの証でもありますね。
阿久梨絵でした！
