Предыдущая страница реферата | 15  16  17  18  19  20  21  22  23  24  25 | Следующая страница реферата

На аналогичную компенсацию можно нарваться, если прочитать символы из текстового файла при помощи java.io.FileReader, а затем вывести их на экран через System.out.println(). Если файл был записан в кодировке Cp866, то вывод будет идти верно, за исключением опять же буквы Ш.

Прямая конверсия byte<->char.

Эта ошибка является любимой у зарубежных программистов на Java. Она довольно подробно рассмотрена в начале описания. Если Вы когда-нибудь будете смотреть чужие исходники, то всегда обращайте внимание на явную конверсию типов - (byte) или (char). Довольно часто в таких местах закопаны грабли.

Алгоритм поиска проблем с русскими буквами

Если Вы не представляете себе где в Вашей программе может происходить потеря русских букв, то можно попробовать следующий тест. Любую программу можно рассматривать как обработчик входных данных. Русские буквы - это такие же данные, они проходят в общем случае три стадии обработки: они откуда-то читаются в память программы (вход), обрабатываются внутри программы и выводятся пользователю (выход). Для того, чтобы определить место проблем, надо попробовать вместо данных зашить в исходник такую тестовую строку: "АБВu0410u0411u0412", и попробовать её вывести. После этого смотрите, что у Вас вывелось:

Если Вы увидите "АБВАБВ", значит компиляция исходников и вывод у Вас работают правильно.

Если Вы увидите "???АБВ" (или любые другие символы кроме "АБВ" на месте первых трёх букв), значит вывод работает правильно, но вот компиляция исходников происходит неверно - скорей всего не указан ключик -encoding.

Если Вы увидите "??????" (или любые другие символы кроме "АБВ" на месте второй тройки букв), значит вывод у Вас работает неверно.

Настроив вывод и компиляцию уже можно легко разобраться и со входом. После настройки всей цепочки проблемы должны исчезнуть.

Об утилите native2ascii

Эта утилита входит в состав Sun JDK и предназначена для преобразования исходных текстов к ASCII-виду. Она читает входной файл, используя указанную кодировку, а на выходе записывает символы в формате "uXXXX". Если указать ключик -reverse, то выполняется обратная конвертация. Эта программа очень полезна для конвертации файлов ресурсов (.properties) или для обработки исходников, если Вы предполагаете, что они могут компиляться на компьютерах с отличными от русских региональными настройками.

Если запустить программу без параметров, она работает со стандартным входом (stdin), а не выводит подсказку по ключам, как остальные утилиты. Это приводит к тому, что многие и не догадываются о необходимости указания параметров (кроме, может быть, тех, кто нашёл в себе силы и мужество заглянуть таки в документацию :-). Между тем этой утилите для правильной работы необходимо, как минимум, указать используемую кодировку (ключик -encoding). Если этого не сделать, то будет использована кодировка по умолчанию (file.encoding), что может несколько расходится с ожидаемой. В результате, получив неверные кода букв (из-за неверной кодировки) можно потратить весьма много времени на поиск ошибок в абсолютно верном коде.

О методе перекодировки символов

Этот метод многие используют неправильно, наверное, не совсем понимая его суть и ограничения. Он предназначен для восстановления верных кодов букв, если они были неверно проинтерпретированы. Суть метода проста: из полученных неверных символов, используя соответствующую кодовую страницу, восстанавливается исходный массив байтов. Затем из этого массива байтов, используя уже корректную страницу, получаются нормальные кода символов. Пример:

String res = new String( src.getBytes("ISO-8859-1"), "Cp1251" );

Проблем в использовании этого приёма может быть несколько. Например, для восстановления используется неверная страница, или же она может измениться в некоторых ситуациях. Другая проблема может быть в том, что некоторые страницы выполняют неоднозначное преобразование byte <-> char. Смотрите, например, описание ошибки за номером 4296969.

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

Русские буквы и MS JVM

Непонятно по каким соображениям, но в ней отсутствуют все файлы кодировок русских букв, акромя Cp1251 (наверное, они таким образом пытались уменьшить размер дистрибутива). Если Вам нужны другие кодировки, например, Cp866, то нужно добавить соответствующие классы в CLASSPATH. Причём классы от последних версий Sun JDK не подходят - у Sun-а уже давно изменилась их структура, поэтому последние версии классов с Microsoft-ом не стыкуются (у MS осталась структура от JDK 1.1.4). На сервере Microsoft, в принципе, лежит полный комплект дополнительных кодировок, но там файл размером около 3 метров, а их сервер докачку не поддерживает :-). Мне удалось таки выкачать этот файл, я его переупаковал jar-ом, можете взять его отсюда.

Если же Вы пишете апплет, который должен работать под MS JVM и Вам потребовалось прочитать откуда-то (например из файла на сервере) байты в русской кодировке, отличной от Cp1251 (например, в Cp866), то стандартный механизм кодировок Вы уже не сможете использовать - апплетам запрещено добавлять классы в системные пакеты, коим в данном случае является пакет sun.io. Выхода тут два - или перекодировать файл на сервере в Cp1251 (или в UTF-8) или перед преобразованием из байтов в Unicode выполнять конвертацию байтов из нужной кодировки в Cp1251.

Руссификация Java под Linux

Скажу сразу - я с Linux не работаю, а приведённая здесь информация получена от читателей данного описания. Если Вы найдёте неточность или захотите дополнить - напишите мне.

При кириллизации JVM в Linux существует две параллельных проблемы:

Проблема вывода кириллицы в GUI-компонентах

Проблема ввода кириллицы с клавиатуры (в X11)

Проблему вывода можно решить таким способом (данный алгоритм прислал Artemy E. Kapitula):

Установить в X11 нормальные шрифты ttf из Windows NT/200. Я бы рекомендовал Arial, Times New Roman, Courier New, Verdana и Tahoma - причем подключать их лучше не через сервер шрифтов, а как каталог с файлами.

Добавить следующий файл font.properties.ru в каталог $JAVA_HOME/jre/lib

Проблема ввода решается примерно таким способом (данный алгоритм прислал Михаил Иванов):

Настройка ввода русских букв в следующей конфигурации:

Mandrake Linux 7.1

XFree86 3.3.6

IBM Java 1.3.0 (релизная)

Проблема:

IBM Java 1.3 не дает вводить русские буквы (видны как крокозябры) при том что на лейблах и в менюхах их видно.

Причина:

использование XIM ( -> xkb) в AWT. (это не есть плохо само по себе, просто с такими штуками нужно обращаться осторожно + некоторые прилады xkb не любят).

Решение:

Настроить xkb (и локаль (xkb без локали НЕ РАБОТАЕТ))

Процедура:

выставляется локаль (где-нибудь типа в /etc/profile или в ~/.bash_profile)

export LANG=ru_RU.KOI8-R

export LC_ALL=ru_RU.KOI8-R

правится (если это еще не сделано) /etc/X11/XF86Config. В секции Keyboard должно быть примерно следующее:

XkbKeycodes     "xfree86"

XkbTypes        "default"

XkbCompat       "default"

XkbSymbols      "ru"

XkbGeometry     "pc"

XkbRules        "xfree86"

Рекомендуем скачать другие рефераты по теме: курсовые работы, реферат государственный.



Предыдущая страница реферата | 15  16  17  18  19  20  21  22  23  24  25 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки