Первая форма конструктора InputStreamReader, показанная в таблице 9.1 и использованная в листинге 9.5, преобразует из символьной кодировки, устанавливаемой платформой по умолчанию, в уникод. Если ваш файл ресурсов использует кодировку, отличную от кодировки, используемой платформой по умолчанию, вы должны использовать второй конструктор InputStreamReader, который принимает аргумент, указывающий- кодировку потока, считываемого вами.
Важным решением проектировки интернационализации и локализации является выбор символьной кодировки ваших файлов ресурсов. Значения строковых атрибутов локализованы и должны быть кодированы с помощью символьной кодировки, которая поддерживает язык локализации. Ключи атрибутов, однако, не локализуются, и они могут быть написаны с помощью ASCII. Варианты выбора кодировки должны учитывать следующее:
— ключи и значения атрибутов должны быть кодированы с помощью одной и той же символьной кодировки;
— все файлы ресурсов для всех региональных настроек должны использовать одну символьную кодировку.
Лучше всего использовать одну символьную кодировку для всего файла. В противном случае вам понадобится создать два символьных потока: один для анализа ключей атрибутов и второй для анализа значений. Подобная схема добавляет вашей обработке потоков ненужный уровень сложности.
Сходным образом, если вы используете другую символьную кодировку для ресурсов каждой региональной настройки, ваше приложение должно создавать свою символьную кодировку отдельно для каждой региональной настройки. Ему придется иметь некоторый способ определения кодировки файла ресурса для того, чтобы создать соответствующий символьный поток. Намного легче использовать одну символьную кодировку для всех региональных настроек.
Двумя практичными вариантами символьных кодировок являются последовательности переключения кодов UTF-8 и Unicode Java. UTF-8 — это код изменяющейся ширины, который поддерживает определения символьной кодировки ASCII. Он вмещает все символы всех языков. К несчастью, потоковые классы MIDP не имеют удобных методов, таких, как DatalnputStream.readUTFO J2SE, для считывания строк UTF. Итак, вам все равно придется выполнять анализ потока собственноручно. Другая сложность заключается в том, что теперь вам придется записывать ваши файлы ресурса в формате UTF-8. Поэтому вам нужны текстовые редакторы и другие инструменты, которые поддерживают создание файлов, кодированных в UTF-8.
Простейшее решение — использовать последовательности переключения кода Unicode Java для кодирования значений строковых атрибутов. Каждая последовательность переключения кода представляет собой уникальный символ уникода. У этого подхода есть два преимущества. Во-первых, вы можете записывать эти последовательности в файл как символы ASCII. Во-вторых, уникод поддерживает все языки. В листинге 9.4 используется ISO8859-1. Он адекватен для франкоязычных ресурсов, но в то же время он может не поддерживать корейский язык, например, тогда как уникод поддерживает. Вы можете использовать некоторые другие многобайтные кодировки, но затем вам придется положиться на редакторы методов ввода и другие инструменты для считывания и записи файла ресурса в этой кодировке.
Если вы используете другие многобайтные кодировки, вам придется учитывать проблемы совместимости и возможность отладки. Есть ли у вас инструменты — текстовые редакторы, редакторы методов ввода и так далее — для поддержки всех ваших региональных настроек? Есть ли у вас те же инструменты, что и у вашей команды по локализации или, по крайней мере, совместимые с ними? Кто будет следить за правильностью работы вашего приложения? Есть ли у них те же инструменты, что и у остальных? Все эти аспекты надо рассматривать при выборе метода кодировки.
Когда вы создали ваш объект InputStreamReader, который является символьно ориентированным потоком, вы можете извлекать символы из него с помощью методов read(). Они происходят из класса, стоящего над ними, java.io.Reader. Эти методы выдают char уникода. В таблице 9.1 перечислены методы класса Reader.
Таблица 9.1. Конструкторы и методы java.io.Reader
Название Конструктора и метода java.io. Reader — Элемент — Описание
InputStreamReader (InputStream is) — Конструктор — Создает поток, который преобразует из кодировки, устанавливаемой платформой по умолчанию, в уникод
InputStreamReader (InputStream is, String enc) — Конструктор — Преобразует из указанной кодировки в уникод
void closed — Метод — Закрывает поток
void mark(int readAheadLimit) — Метод — Устанавливает лимит опережающего считывания для метки
boolean markSupported() — Метод — Показывает, поддерживает ли данный поток разметку
int read() — Метод — Считывает один символ
int read (char [] cbuf, int off, int len) — Метод — Считывает количество «len» символов в части символьного массива, начиная от указанной сдвига
boolean ready() — Метод — Показывает, должно ли здесь считываться что-либо
void reset() — Метод — Переустанавливает поток в последнюю позицию метки
long skip (long n) — Метод — Пропускает указанное число символов
Единственной пропущенной задачей является анализ символов, которые вы считываете. К сожалению, MIDP не имеет удобных классов, таких, как класс StringTokenizer J2SE, который облегчает расстановку меток. Вы должны поэтому самостоятельно проанализировать локализованные ресурсы, один символ за раз, с помощью любой из двух форм перегрузки Reader.read(). Если вы использовали такой формат файла, как в листинге 9.4, самое меньшее, что вы должны сделать затем, это отделить поле ключа от поля значения для каждого атрибута, убрать пробелы и так далее. В листинге 9.5 весь код в строках 127–318 посвящен обработке потока.
Одним из существенных недостатков данного проектирования интернационализации является дополнительное кодирование, необходимое для создания. анализаторов потоков. Кроме того, что это включает дополнительную работу по разработке данного кода, ваше приложение также ограничивается средой исполнения. Файл ввода/вывода может отнять много рабочих ресурсов и выдать при этом только минимально приемлемую производительность. Это важно рассматривать при разработке приложений MIDP.
Кроме того, вам необходимо учитывать создание портативной библиотеки классов обработки ввода-вывода, которую вы можете использовать и для других приложений. Будет лишней тратой времени на проектирование повторно реализовать данную инфраструктуру вновь и вновь.
За исключением этих недостатков этот второй подход в значительной степени сходен с первым, который использует файл JAD для хранения локализованных ресурсов. Как и подход с файлом JAD, этот подход может обрабатывать нестроковые ресурсы, определяя атрибуты, чьи значения являются именами чувствительных к региональным настройкам классов.
Использование классификационных файлов Java для определения интернационализированных ресурсов
В данном третьем подходе приложения определяют классы Java, которые содержат локализованные ресурсы. Каждый класс содержит ресурсы для одной региональной настройки. Файлы откомпилированы и упакованы как часть JAR приложения. При работе локализованные ресурсы затем достаются с помощью создания экземпляра соответствующего класса.
Эта разработка аналогична разработке иерархии пакетов ресурсов J2SE. Классы java.util.ResourceBundle и java.util.ListResourceBundle J2SE являются абстрактными классами, определяющими структуру создания агрегаций произвольных чувствительных к региональным настройкам объектов Java. Эти объекты могут быть любыми объектами Java.
Этот подход к разработке интернационализации определяет свою собственную версию классов ResourceBundle и ListResourceEundle J2SE. В листингах 9.7 и 9.8 показаны их реализации, которые определяют, соответственно, подмножества классов ResourceBundle и ListResourceBundle платформы J2SE. Хотя эти реализации являются собственными, сигнатуры методов являются теми же, что и у их аналогов в J2SE.