【Java】「文字化け」の悲劇を繰り返さない。ファイルのエンコーディング誤認を防ぐ鉄則

1. 導入：開いた瞬間の「」にさようなら

UTF-8だと思って読み込んだファイルが、実はWindows標準のShift-JISだった……。 コンソールやログに並ぶ「（豆腐）」や、意味不明な漢字の羅列。誰しも一度は経験する絶望的な瞬間です。

Javaでファイル処理を行う際、もっとも大切なのは「推測」ではなく「指定」すること。今回は、文字コードの誤認を防ぐための確実な方法を探求します。

2. なぜ「誤認」が起きるのか？

Javaの古い書き方（FileReader など）では、**「実行環境のデフォルト文字コード」**が勝手に使われてしまいます。

• Windowsで実行: MS932 (SJIS系) で読もうとする

• Linuxで実行: UTF-8 で読もうとする

同じプログラムなのに、動かす場所によって「文字化けしたりしなかったり」するのは、この「OS依存のデフォルト設定」が原因です。

3. 誤認を防ぐための「3つの鉄則」

① 推測せず、明示的に指定する（Java 11以降の推奨）

Java 11から導入された Files.readString や Files.lines を使い、必ず StandardCharsets を指定します。これが最も安全で簡潔な方法です。

【正解のコード：UTF-8で読み込む】

Java

Path path = Paths.get("data.txt");
try {
    // どんなOSで動いても、必ずUTF-8で読み込む
    String content = Files.readString(path, StandardCharsets.UTF_8);
    System.out.println(content);
} catch (IOException e) {
    e.printStackTrace();
}

② ファイルの「正体」を見破る方法

どうしても文字コードが不明なファイルが来る場合は、外部ライブラリ（ICU4Jなど）を使って「文字コードの判定」を行うこともできますが、まずは**「ファイルのヘッダ（BOM）」**を確認する癖をつけるのが第一歩です。

③ 失敗例：昔ながらの危うい書き方

Java

// 危険！実行OSのデフォルトに依存してしまう
BufferedReader br = new BufferedReader(new FileReader("data.txt"));

この書き方は、「昨日のWindowsでは動いたのに、今日のサーバー（Linux）では壊れた」という悲劇を生みます。

4. 納得ポイント：バイト配列から考える

文字コードの正体は、結局のところ**「バイト配列をどう解釈するかというルール」**です。

• UTF-8: 「あ」は E3 81 82 (3バイト)

• SJIS: 「あ」は 82 A0 (2バイト)

読み込み側が「ルール（文字コード）」を間違えれば、バイトの区切り位置がズレ、全く別の文字や「不明な文字」として表示されるのは当然の結果です。 「ファイルを開く前に、ルールを取り決めておく」。これがファイル処理における唯一の正解なのだと心から納得しました。

5. まとめ

今回、文字コードの問題を整理したことで、コンピュータが「文字」という曖昧なものを、いかに厳密な「バイト」のルールで扱っているかを再確認できました。