Ударения в имени файла с использованием Java в Solaris

Question

У меня проблема с тем, что я не могу написать файлы с акцентами в имени файла в Solaris.

С учетом следующего кода

public static void main(String[] args) {
    System.out.println("Charset = "+ Charset.defaultCharset().toString());
    System.out.println("testéörtkuoë");
    FileWriter fw = null;
    try {
        fw  = new FileWriter("testéörtkuoë");
        fw.write("testéörtkuoëéörtkuoë");
        fw.close();

Я получаю следующий вывод

Charset = ISO-8859-1
test??rtkuo?

и я получаю файл с именем «test ?? rtkuo?»

Основываясь на информации, найденной в StackOverflow, я попытался вызвать приложение Java, добавив при запуске «-Dfile.encoding = UTF-8». Это возвращает следующий вывод

Charset = UTF-8
testéörtkuoë

Но имя файла все еще "test ?? rtkuo?"

Любая помощь очень ценится.

Stef

Answer 1

Все эти символы присутствуют в ISO-8859-1 . Я подозреваю, что часть проблемы заключается в том, что редактор кода сохраняет файлы в кодировке, отличной от той, которую использует ваша операционная система.

Если редактор использует ISO-8859-1, я ожидаю, что он закодирует ëéö как:

eb e9 f6

Если редактор использует UTF-8, я ожидаю, что он закодирует ëéö как:

c3ab c3a9 c3b6

Другие кодировки будут давать другие значения.

Исходный файл был бы более переносимым, если бы вы использовали escape-последовательности Unicode . По крайней мере, убедитесь, что ваш компилятор использует ту же кодировку, что и редактор.

Примеры:

ë    \u00EB
é    \u00E9
ö    \u00F6

Вы можете посмотреть эти значения с помощью Unicode-диаграмм .

Изменение кодировки файла по умолчанию с помощью -Dfile.encoding = UTF-8 может иметь непредвиденные последствия для взаимодействия JVM с системой.

Здесь есть параллели с проблемами, которые вы можете встретить в Windows .

Я не могу воспроизвести проблему напрямую - моя версия OpenSolaris использует UTF-8 в качестве кодировки по умолчанию.

Answer 2

Если вы попытаетесь перечислить имена файлов с помощью java io apis, что вы увидите? Они правильно закодированы? Мне любопытно, действительно ли проблема заключается в кодировании имен файлов или в инструментах, которые вы используете для их проверки.

Answer 3

Java использует кодировку операционной системы по умолчанию при чтении и записи файлов. Теперь никогда не следует полагаться на это. Рекомендуется указывать кодировку явно.

В Java вы можете использовать для чтения и записи следующее:

Чтение:

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(inputPath),"UTF-8"));

Запись:

PrintWriter pw = new PrintWriter(new BufferedWriter(new OutputStreamWriter(new FileOutputStream(outputPath), "UTF-8")));

Answer 4

У меня похожая проблема. В отличие от этого примера, программе не удалось вывести список файлов, правильно используя sysout.println, хотя ls показывал правильные значения.

Как описано в документации, переменная окружения file.encoding не должна использоваться для определения кодировки, и в этом случае JVM игнорирует ее

Симптом:

1. Я не могу набрать акценты в оболочке.
2. ls показывал правильные значения
3. File.list() печатал неверные значения
4. среда file.encoding не влияла на вывод
5. среда user.(language|country) не влияла на вывод

Решение:

Хотя переменная окружения LC_* была установлена ​​в оболочке со значениями, унаследованными от / etc / defaut / init, как указано в команде set, языковой стандарт отображал разные значения.

$ set | grep LC
LC_ALL=pt_BR.ISO8859-1
LC_COLLATE=pt_BR.ISO8859-1
LC_CTYPE=pt_BR.ISO8859-1
LC_MESSAGES=C
LC_MONETARY=pt_BR.ISO8859-1
LC_NUMERIC=pt_BR.ISO8859-1
LC_TIME=pt_BR.ISO8859-1

$ locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

Решением был простой экспорт LANG. Эта переменная окружения действительно влияет на jvm

LANG=pt_BR.ISO8859-1
export LANG

Answer 5

Что происходит, когда вы делаете:

ls > testéörtkuoë

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