Второй фрагмент кода с явной кодировкой правильно кроссплатформенный.
Убедитесь, что с содержимым все в порядке. Юникод:
String content="\u200F\u05D0\u05D1\u05D2\u05D3\u05D4\u200E"; // "אבגדהו"
Я использовал u-кодировку, поэтому источником java является ASCII, и, следовательно, кодировка java-компилятора и кодировка редактора должны ошибочно отличаться, не могут вызвать
поврежденные строки.
Предполагая, что content является строкой:
if (!content.isEmpty()) {
content = "\uFEFF" + content; // Add a BOM char in front for Windows
Path p = Paths.get(path);
Files.write(p, Collections.singletonList(content), StandardCharsets.UTF_8);
}
Записывает файл UTF-8, который вызовет наименьшее количество проблем, если только внутри Израиля, где можно предположить кодировку для конкретной страны, windows-1255.
Я добавил символ спецификации в качестве первого символа файла, чтобы Windows могла легко идентифицировать файл не как однобайтовую кодировку ANSI, а как UTF-8 Unicode.
Тогда возникает проблема представления текста на иврите. Там должен быть адекватный шрифт.
Вы можете написать HTML-файл:
<code>content = "<!DOCTYPE html><html lang="he">"
+ "<head><meta charset=\"utf-8\"></head>"
+ "<body><pre>"
+ content.replace("&", "&")
.replace("<", "<")
.replace(">", ">")
+ " ";
Я нахожу это лучше, чем написание спецификации.
Последнее, что нужно добавить: символы LTR ('\ u200E') и RTL (справа налево, '\ u200F'), но я так понимаю, это не создает проблем.
Всегда так, что в каком-то месте используется перегруженный метод, где кодировка отсутствует, по умолчанию используется текущая кодировка платформы.
У
new InputStreamReader(..., StandardCharsets.UTF_8))
и тому подобное.