Проблемы несовпадения кодировок, типичные ошибки

1. Симптомы ошибок

В идеальном мире программисты всегда знают, в какой кодировке записан файл, и правильно указывают её при чтении. Но реальность — это мир, где файлы гуляют между Windows, Linux, серверами, редакторами, и каждый по-своему трактует байты. В результате мы сталкиваемся с такими симптомами:

• «Краказябры» — вместо ожидаемого текста видим странные символы, вопросительные знаки, квадратики или набор букв, который не похож ни на один язык мира.
• Потеря символов — часть текста исчезает или заменяется на ?.
• Исключения — например, MalformedInputException, когда Java не может «переварить» байты в выбранной кодировке.
• Ошибки при парсинге — программа не может правильно обработать файл, потому что ключевые слова или структуры повреждены из-за искажения текста.

Вот классический пример «кракозябр» при чтении кириллического файла в неправильной кодировке:

Ожидали:  Привет, мир!
Получили: Привет, мир

Это не новый язык, а результат того, что байты были интерпретированы не тем «словарём», что нужен.

2. Почему возникают ошибки: корень зла

Файл записан в одной кодировке, а читается в другой

Допустим, кто-то сохранил файл в Windows-1251, а вы открываете его в UTF-8. Java честно пытается расшифровать байты по правилам UTF-8, но получается бессмыслица, потому что значения байтов не совпадают с ожидаемыми.

Использование системной кодировки «по умолчанию»

Если вы не указываете кодировку явно, Java использует системную — ту, что установлена на вашем компьютере. На Windows с русской локалью это может быть Windows-1251, на Linux — UTF-8, на Mac — тоже UTF-8. Файл, который отлично открывается у вас, может стать нечитаемым у коллеги с другой ОС.

Использование устаревших конструкторов

В старых версиях Java (и в некоторых учебниках) часто встречаются такие конструкции c FileReader/FileWriter, которые используют системную кодировку и не дают вам контроля — это ловушка и источник «кракозябр».

FileReader reader = new FileReader("file.txt");
FileWriter writer = new FileWriter("file.txt");

Наличие или отсутствие BOM (Byte Order Mark)

Некоторые кодировки (например, UTF-8 с BOM или UTF-16) добавляют в начало файла специальные байты, чтобы сигнализировать о своей природе. Если программа не ожидает BOM или наоборот — ждёт его, но не находит, могут возникнуть проблемы: либо первые символы файла будут искажены, либо файл не распознаётся вовсе.

3. Как проявляются ошибки: разбор на практике

Пример 1: Файл с кириллицей, записанный в Windows-1251, читается как UTF-8

import java.nio.file.*;
import java.nio.charset.*;

public class EncodingDemo {
    public static void main(String[] args) throws Exception {
        Path path = Paths.get("russian.txt");
        // Файл записан в Windows-1251, читаем как UTF-8 — будет кракозябра!
        try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
            System.out.println(reader.readLine());
        }
    }
}

В результате вместо «Привет, мир!» увидите набор странных символов.

Пример 2: Файл записан в UTF-8, читается как ISO-8859-1

try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.ISO_8859_1)) {
    System.out.println(reader.readLine());
}

Результат: Все не-ASCII-символы будут превращены в мусор или заменены на ?.

Пример 3: Исключение при чтении файла

Если байты не соответствуют правилам выбранной кодировки, Java может выбросить исключение:

Exception in thread "main" java.nio.charset.MalformedInputException: Input length = 1
    at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
    ...

Это значит, что Java встретила байт, который не может быть корректно интерпретирован в выбранной кодировке.

4. Диагностика: как понять, что не так с кодировкой

Проверяйте кодировку файла

• В редакторах типа Notepad++, VS Code или Sublime Text обычно можно посмотреть или сменить кодировку файла (обычно в нижней панели).
• В Linux командой можно получить подсказку о кодировке (но не всегда на 100% точно):

file имя_файла.txt

Проверяйте системную кодировку Java

Выведите в консоль значение свойства file.encoding:

System.out.println(System.getProperty("file.encoding"));

Используйте тестовые данные

Создайте небольшой файл с разными символами (кириллические, латинские, спецсимволы, эмодзи), попробуйте прочитать его с разными кодировками и посмотрите, когда результат совпадает с ожиданиями.

Всегда явно указывайте кодировку

Как только вы видите в коде чтение/запись файла без указания кодировки — это повод насторожиться. Например, используйте Files.newBufferedReader(..., StandardCharsets.UTF_8) вместо «умолчаний».

5. Best practices: как не попасть в ловушку

Правило №1:
ВСЕГДА явно указывайте кодировку при работе с файлами, особенно если файл будет использоваться на разных компьютерах, в разных ОС или отправляться по сети.

Правило №2:
Используйте современные, «говорящие» кодировки — в первую очередь UTF-8 (StandardCharsets.UTF_8). Только если есть особые требования (например, интеграция со старой системой), используйте другие кодировки.

Правило №3:
Избегайте классов FileReader и FileWriter (они не позволяют указать кодировку), вместо них используйте InputStreamReader, OutputStreamWriter или методы из Files с явным Charset.

Правило №4:
Проверяйте результат! Открывайте записанные файлы в редакторах с поддержкой разных кодировок, чтобы убедиться, что текст выглядит корректно.

6. Особенности и нюансы: BOM, XML, JSON и другие «весёлые» случаи

BOM (Byte Order Mark): иногда файл в UTF-8 начинается с «невидимых» байтов (EF BB BF). Большинство современных программ их игнорируют, но некоторые могут показать «кракозябру» в начале строки или не принять файл (например, старые парсеры XML/JSON).

XML/HTML: иногда в начале файла есть строка вроде <?xml version="1.0" encoding="UTF-8"?>. Она сообщает программе, в какой кодировке ожидать байты. Но если фактическая кодировка не совпадает с объявленной — снова «кракозябры».

JSON: по стандарту должен быть в UTF-8, но если файл создан в Windows-1251, парсер выдаст ошибку или искажённые данные.