Как правильно хранить и получать интернационализированные строки в файлах свойств? - PullRequest
Новая
       25

Как правильно хранить и получать интернационализированные строки в файлах свойств?

2 голосов
/ 11 октября 2008

Я экспериментирую с интернационализацией, создавая программу Hello World, которая использует файлы свойств + ResourceBundle для получения различных строк.

В частности, у меня есть файл "messages_en_US.properties", в котором хранится "hello.world = Hello World!", Который, конечно, прекрасно работает.

Затем у меня есть файл "messages_ja_JP.properties", с которым я пробовал всевозможные вещи, но он всегда отображается как некий тип искаженной строки при выводе на консоль или в Swing. Очевидно, что проблема заключается в чтении содержимого в строку Java, поскольку строка Java на японском языке, напечатанная непосредственно в источнике, может печататься нормально.

Вещи, которые я пробовал:

  • Файл .properties в кодировке UTF-8 со строкой японского языка как есть для значения. Что-то, что я прочитал, указывает, что Java ожидает, что файл свойств будет в собственной кодировке системы ...? Это не сработало в любом случае.
  • Файл с кодировкой по умолчанию (ISO-8859-1) и значением, хранящимся в качестве экранированного Unicode, созданного программой native2ascii, включенной в Java. Пробовал с исходным файлом в различных японских кодировках ... SHIFT-JIS, EUC-JP, ISO-2022-JP.

Edit:

Я на самом деле понял это, когда набирал, но решил, что все равно опубликую и отвечу, если это кому-нибудь поможет.

Ответы [ 3 ]

2 голосов
/ 11 октября 2008

Я понял, что native2ascii предполагал (удивительно), что он конвертирует из кодировки моей операционной системы по умолчанию каждый раз, и поэтому не генерирует правильную экранированную строку Unicode.

Запуск native2ascii с опцией «-encoding encoding_name », где encoding_name - это имя кодировки исходного файла (в данном случае SHIFT-JIS), что дает правильный результат, и все работает хорошо.

Ant также имеет задачу native2ascii, которая запускает native2ascii для набора входных файлов и отправляет выходные файлы куда угодно, поэтому я смог добавить конструктор, который делает это в Eclipse, чтобы в моей исходной папке были строки в исходном виде кодирование для удобного редактирования и построения автоматически помещает преобразованные файлы с одинаковыми именами в выходную папку.

1 голос
/ 12 октября 2008

Начиная с JDK 1.6, в свойствах есть метод load () , который принимает Reader. Это означает, что вы можете сохранить все файлы свойств как UTF-8 и читать их все напрямую, передавая InputStreamReader в load (). Я думаю, что это самое элегантное решение, но оно требует, чтобы ваше приложение работало в среде исполнения Java 6.

Исторически load () принимала только InputStream, и поток был декодирован как ISO-8859-1. Не кодировка системы по умолчанию, всегда ISO-8859-1. Это важно, потому что это делает возможным определенный взлом. Скажем, ваш файл свойств хранится как UTF-8. После извлечения свойства вы можете перекодировать его как ISO-8859-1 и снова декодировать как UTF-8, например так: 

String realProp = new String(prop.getBytes("ISO-8859-1"), "UTF-8");

Это уродливо и хрупко, но это работает. Но я думаю, что лучшее решение, по крайней мере, на ближайшие несколько лет, это то, которое вы нашли: массовое преобразование файлов с помощью native2ascii с помощью инструмента сборки, такого как Ant.

0 голосов
/ 12 октября 2008

Альтернативный способ обработки файлов свойств: http://www.unipad.org/main/

Это редактор, который может читать / записывать файлы в \ u Unicode escape-формате, это формат, который создает native2ascii.

Не знаю, насколько хорошо он работает с японским, я использовал его для венгерского.

...