Кодировка по умолчанию зависела от окружения (локаль ОС): одна сборка вела себя по-разному на машине разработчика и на сервере, данные молча портились. С Java 18 по умолчанию UTF-8 (JEP 400), но явная кодировка остаётся хорошей практикой.
А ещё -Dfile.encoding=COMPAT вернёт старое поведение
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Исторически кодировка по умолчанию определялась локалью операционной системы, поэтому одна и та же сборка вела себя по-разному на машине разработчика и на сервере, а данные молча портились. Начиная с Java 18 кодировкой по умолчанию для файлового ввода-вывода стал UTF-8 независимо от локали, что убрало основную часть проблемы, — но полагаться на умолчание всё равно не стоит: код может выполняться на более старой версии, а явное указание документирует намерение. Правильная привычка — всегда передавать Charset: либо через перегрузку конструктора, либо через Files.newBufferedReader и Files.readString, которые используют UTF-8 по контракту. Отдельно стоит помнить, что кодировка влияет и на длину строки в байтах, что важно при валидации ограничений.
Один верный вариант. Подумайте, потом откройте ответ.
Байтовые и символьные потоки, кодировки и Charset, буферизация и системные вызовы, декоратор-паттерн и современный файловый API.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto