Русский язык в java. Типы char и byte. Файлы и потоки данных

Nokia 26.03.2019

С другой стороны большинство файлов данных основано на 8-битовом представлении символов. Сюда входят также текстовые файлы и большинство баз данных (окромя наиболее продвинутых). Кроме того, что самое паршивое, одни и те же байты могут представлять разные символы (в зависимости от кодовой страницы). Налицо конфликт - как преобразовать одно в другое и наоборот, причём с наименьшими потерями для данных. Для этого был придуман довольно удобный механизм использования кодовых страниц. Для каждой кодовой страницы было создано по 2 класса перекодировки (ByteToChar и CharToByte). Классы эти лежат в пакете sun.io. Если, при перекодировке из char в byte не было найдено соответствующего символа, он заменяется на символ?.

Кстати, эти файлы кодовых страниц в некоторых ранних версиях JDK 1.1 содержат ошибки, вызывающие ошибки перекодировок, а то и вообще исключения при выполнении. Например, это касается кодировки KOI8_R. Лучшее, что можно при этом сделать - сменить версию на более позднюю. Судя по Sun-овскому описанию, большинство этих проблем было решено в версии JDK 1.1.6.

Когда и как надлежит пользоваться этой перекодировкой? Когда пользоваться, в принципе, понятно - при любом преобразовании из byte в char и наоборот. В классе String в тех местах, где есть преобразование можно указать дополнительный параметр (String enc), задающий имя кодовой страницы. Это конструктор по массиву байтов и метод getBytes(). Однако, в реальной программе, явно указывать кодовую страницу не всегда удобно. Для этого была введена кодировка по умолчанию. По умолчанию она зависит от системы (для русских виндов принята кодировка Cp1251), и в старых JDK её можно изменить установкой системного свойства file.encoding . Вообще-то, как утверждают в Sun, это свойство отражает системную кодировку, и она не должна изменяться в командной строке (см., например, комментарии к BugID ) Эта кодировка используется тогда, когда явно не указанно название страницы. Т.к. эта настройка одна на все преобразования, иногда можно наткнуться на неприятности. Например, эта же настройка используется для вывода на консольный экран, что, в случае виндов, как правило, неприемлемо - там нужно использовать страницу Cp866. Было бы здорово, если бы эти кодировки указывались независимо - например, console.encoding и т.п., но, думаю, Sun-овцам пока не до таких высоких материй.

Кстати, о выводе на консоль. Есть два пути решения вышеуказанной проблемы:

  1. Использовать вместо System.out.println свой класс, а уже в нём делать преобразование. Например:
    public class Msg { static String cp = System.getProperty("console.encoding","Cp866"); public static void message(String msg) { msg += "\n"; byte b; try { b = msg.getBytes(cp); } catch(UnsupportedEncodingException e) { // В случае отсутствия нужной кодировки, // делаем преобразование по умолчанию b = msg.getBytes(); } System.out.write(b); } } ... Msg.message("Сообщение");
  2. Написать свою версию PrintStream, поддерживающую нужную кодировку, и подставить его через System.setOut() и System.setErr(). Вот, например, обычное начало в моих программах:
    ... public static void main(String args) { // Установка вывода консольных сообщений // в нужной кодировке try { System.setOut(new CodepagePrintStream (System.out,System.getProperty ("console.encoding","Cp866"))); } catch(UnsupportedEncodingException e) { System.out.println ("Unable to setup console codepage: " + e); } ...

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

  1. Читать и записывать массивы байтов (byte), а для перекодировки использовать упомянутые методы класса String. Этот способ особенно удобен, когда в потоке могут присутствовать данные в разных кодировках.
  2. Использовать классы InputStreamReader и OutputStreamWriter из пакета java.io, специально предназначенные для этих целей.
  3. Сделать преобразование в нужную кодировку. Если вы всё сделаете корректно, то данные не потеряются, хотя, конечно, пользоваться этим желательно только в крайнем случае. Пример:
    // Чтение русских букв в кодировке Cp866 через объект, // поддерживающий только Cp437 String str = o.readString(); str = new String(str.getBytes("Cp437"),"Cp866"); // Сохранение русских букв // в кодировке Cp866 через объект, // поддерживающий только Cp437 str = new String(str.getBytes("Cp866"),"Cp437"); o.writeString(str);
    Более подробно о этом методе, и о возможных проблемах с ним, расписано ниже, в разделе О методе перекодировки символов .
  4. Настроить драйвер БД на нужную кодировку. Как именно - это зависит от конкретного драйвера. К сожалению, многие драйвера понятия не имеют о каких-то там кодировках. Иногда их можно пропатчить на этот счёт, но чаще всего приходится действовать обходными путями.

    Например, один из самых часто используемых драйверов - мост JDBC-ODBC. В версиях JDK 1.1, этот мост просто игнорировал кодировки символов, из-за чего нужно было предпринять дополнительные ухищрения, типа описанных в предыдущем пункте (это также касается и последней ихней версии, 1.1.8).

    Мост из комплекта Sun Java 2 теперь можно настроить на нужную кодировку. Это делается добавлением дополнительного свойства charSet в набор параметров, передаваемых для открытия соединения с базой. По умолчанию используется file.encoding . Делается это примерно так:

    // Параметры соединения с базой Properties connInfo = new Properties(); connInfo.put("user", username); connInfo.put("password", password); connInfo.put("charSet", "Cp1251"); // Устанавливаем соединение Connection db = DriverManager.getConnection(dataurl, connInfo);

    Другой пример - драйвер JDBC-OCI (не pure Java - тот называется thin) от Oracle 8.0.5 под Linux. При получении данных из БД, драйвер определяет "свою" кодировку при помощи переменной окружения NLS_LANG. Если эта переменная не найдена, то он считает что кодировка - ISO88591. Весь фокус в том, что NLS_LANG должна быть именно переменной окружения, а properties (типа file.encoding) здесь "не катят". В случае использования драйвера внутри servlet engine Apache+Jserv, переменную окружения можно задать в файле jserv.properties:

    wrapper.env=NLS_LANG=American_America.CL8KOI8R
    Информацию об этом прислал Сергей Безруков , за что ему отдельное спасибо.

Если же Вы свободны в формировании формата - тогда всё проще. Используйте формат Unicode или UTF8 - и проблем не будет.

В случае с БД, можно, конечно, использовать и какой-нибудь 16-ричный формат, но это не всегда приемлемо, т.к. Вы получите 2-х - 4-х кратный рост места на диске и потеряете возможность использовать стандартные программы работы с БД, например генераторы отчётов.

Как уже упоминалось, при выполнении программы используется Unicode. Исходные же файлы пишутся в обычных редакторах. Я пользуюсь Far-ом, у Вас, наверняка есть свой любимый редактор. Эти редакторы сохраняют файлы в 8-битовом формате, а значит, что к этим файлам также применимы рассуждения, аналогичные приведённым выше. Разные версии компиляторов немного по разному выполняют преобразование символов. В ранних версиях JDK 1.1.x используется настройка file.encoding , которую можно поменять при помощи нестандартной опции -J. В более новых (как сообщил Денис Кокарев - начиная с 1.1.4) был введён дополнительный параметр -encoding, при помощи которого можно указать используемую кодировку. В скомпилированных классах строки представлены в виде Unicode (точнее в модифицированном варианте формата UTF8), так что самое интересное происходит при компиляции. Поэтому, самое главное - выяснить, в какой кодировке у Вас исходники и указать правильное значение при компиляции. По умолчанию будет использован всё тот же пресловутый file.encoding . Пример вызова компилятора:

Кроме использования этой настройки есть ещё один метод - указывать буквы в формате "\uxxxx", где указывается код символа. Этот метод работает со всеми версиями, а для получения этих кодов можно использовать стандартную утилиту native2ascii .

Русские буквы в файлах properties.

Для чтения файлов properties используются методы загрузки ресурсов, которые работают специфичным образом. Собственно для чтения используется метод Properties.load, который не использует file.encoding (там кодировка жёстко указана), поэтому единственный способ указать русские буквы - использовать формат "\uxxxx" и утилиту native2ascii .

Метод Properties.save работает по разному в версиях JDK 1.1 и 1.2. В версиях 1.1 он просто отбрасывал старший байт, поэтому правильно работал только с англицкими буквами. В 1.2 делается обратное преобразование в "\uxxxx", так что он работает зеркально к методу load.

Русские буквы в Servlet-ах.

Ну, для чего эти самые Servlet-ы нужны, я думаю, Вы в курсе. Если нет - то лучше сначала прочитать документацию. Здесь же рассказывается только об особенностях работы с русскими буквами.

Так в чём же особенности? Когда Servlet посылает ответ клиенту, есть два способа послать этот ответ - через OutputStream (getOutputStream()) или через PrintWriter (getWriter()). В первом случае Вы записываете массивы байтов, поэтому применимы вышеописанные методы записи в файл. В случае же PrintWriter, он использует установленную кодировку. В любом случае необходимо правильно указать используемую кодировку при вызове метода setContentType(), для того, чтобы было правильное преобразование символов на стороне сервера. Это указание должно быть сделано перед вызовом getWriter() или перед первой записью в OutputStream. Пример:

public void doPost (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType ("text/html; charset=windows-1251")); PrintWriter out = response.getWriter(); // Отладочный вывод названия кодировки для проверки out.println("Encoding: " + response.getCharacterEncoding()); ... out.close();
Это по поводу отдачи ответов клиенту. Со входными параметрами, к сожалению не так просто. Входные параметры кодируются броузером побайтно в соответствии с MIME-типом "application/x-www-form-urlencoded". Как рассказал Алексей Менделев русские буквы броузеры кодируют, используя текущую установленную кодировку. Ну и, разумеется, ничего о ней не сообщают. Соотвественно, например, в JSDK 2.0 и 2.1 это никак не проверяется. Собственно для раскодирования используются методы HttpUtils.parsePostData() и HttpUtils.parseQueryString(), которые просто обнуляют старший байт. Это зарегистрированная ошибка в JSDK (). К сожалению, эту ошибку закрыли как "Will not be fixed", с тем оправданием, что, дескать, раз в RFC на эту тему ничего не сказанно, то и делать мы ничего не будем. Однако, после переписки наших разработчиков в майл-листе SERVLET-INTEREST дело, похоже, сдвинулось с мёртвой точки. По крайней мере на словах было обещано включить метод установки кодировки в спецификацию JSDK 2.3.

Пока же приходится обходиться своими средствами. Оригинальный способ работы с кодировками предлагает Russian Apache - расписано, как именно. Судя по отзывам, не имеет проблем с русскими и система Resin .

JNI (Java Native Interface) - это стандарт по взаимодействию с C/C++-ным кодом. Как и следовало ожидать, на этом водоразделе тоже происходит столкновение 8-ми и 16-битовых кодировок. Большинство C/C++-ных программ пишется без учёта Unicode, многие программисты даже не знают о нём. Я сам, за 7 лет писательства на C/C++, пока не начал писать на Java, про Unicode знал только по наслышке. Большинство строковых операций в C/C++ сделаны для 8-битового сишного типа char. В принципе, есть некоторые подвижки в этом направлении, в частности для Windows NT можно откомпилировать код, который будет взаимодействовать с Unicode-вариантами Win32 API, но, к сожалению, этого часто недостаточно.

Таким образом главная задача - получить тип char* из типа jstring (JNI-шное отображение String) и наоборот. Практически во всех описаних и примерах JNI для этого используется пара функций GetStringUTFChars/ReleaseStringUTFChars. Коварные буржуины и здесь приготовили засаду - эти функции формируют массив байтов по стандарту UTF, который соответствует ожидаемому только для ASCII-символов (первых 128 значений). Русские буквы опять в пролёте. Сишный char очень хорошо ложится на Java-овский тип byte, но при этом возникает загвоздка в виде ноль-символа. Его нужно добавлять при преобразовании byte->char* и учитывать при обратном преобразовании. Делать это на C/C++ неудобно, потому лучше всего сделать максимум возможного на Java. Пример:

// Получение сишной строки public static byte getCString(String s) { return (s+"\0").getBytes(); } public void action(String msg) throws java.io.IOException { int res = nAction(getCString(msg)); if(res!=0) throw new java.io.IOException (getErrorString(res)); } private String getErrorString(int error) { byte buf = new byte; int len = nGetErrorString(error,buf); return new String(buf,0,len); } private native int nAction(byte msg); private native int nGetErrorString (int error,byte msg); ... JNIEXPORT jint JNICALL Java_Test_nAction (JNIEnv *env, jobject obj, jbyteArray msg) { jint res; jbyte *bmsg = (*env)->GetByteArrayElements(env,msg,NULL); printf(bmsg); res = do_something(bmsg); (*env)->ReleaseByteArrayElements(env,msg,bmsg,JNI_ABORT); return res; } JNIEXPORT jint JNICALL Java_Test_nGetErrorString (JNIEnv *env, jobject obj, jint error, jbyteArray msg) { jbyte *bmsg = (*env)->GetByteArrayElements(env,msg,NULL); jsize sz = (*env)->GetArrayLength(env,msg); jint len; get_error_string(error,bmsg,sz); len = strlen(bmsg); (*env)->ReleaseByteArrayElements(env,msg,bmsg,0); return len; }
Тут используется преобразование символов по умолчанию, что вполне естественно при взаимодействиях с системным API. Если же Вам необходима определённая кодовая страница, соответственно нужно добавить её название.

GUI (AWT, Swing)

Многие связывают неправильный вывод русских букв с неправильной установкой шрифта. Мне кажется, это связанно с тяжким опытом программирования на Windows 3.x, где основная причина действительно была в этом. В Java всё сложнее и редко действительно связанно со шрифтами. Я не разбирался со специфическими настройками броузеров, т.к. ещё не писал апплетов, только приложения, но думаю в последних версиях в этом плане всё нормально.

Где же действительно лежат наибольшие подводные камни? В основном это связанно с неправильной перекодировкой символов. Часть этих проблем и методы их решения описаны выше. Если у Вас все преобразования выполняются корректно, и для вывода используется шрифт Unicode, то есть очень большой шанс, что Ваша программа будет работать правильно.

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

Если программа не работает нигде - значит проблема только в ней и в ваших руках. Внимательно перечитайте всё, что было написано выше, и ищите. Если же проблема проявляется только в конкретном окружении - значит дело, скорей всего в настройках. Где именно - зависит от того, какой графической библиотекой Вы пользуетесь. Если AWT - помочь может правильная настройка файла font.properties.ru. Пример корректного файла можно взять из Java 2. Если у Вас нет этой версии, можете скачать его с данного сайта: версия для Windows , версия для Linux . Если у Вас установлена русская версия OS - просто добавьте этот файл туда, где лежит файл font.properties. Если же это англицкая версия, то нужно, или дополнительно сменить текущий язык при помощи задания настройки -Duser.language=ru или переписать этот файл вместо font.properties. Этот файл задаёт используемые шрифты и кодовые страницы.

С библиотекой Swing всё проще - в ней всё рисуется через подсистему Java2D. Надписи в стандартных диалогах (JOptionPane, JFileChooser, JColorChooser) переделать на русский очень просто - достаточно лишь создать несколько файлов ресурсов. Я это уже проделал, так что можете просто взять готовый файл и добавить его в свой CLASSPATH. Единственная проблема, с которой я столкнулся - в версиях JDK начиная с 1.2 rc1 и по 1.3 beta, русские буквы не выводятся под Win9x при использовании стандартных шрифтов (Arial, Courier New, Times New Roman, etc.) из-за ошибки в Java2D. Ошибка весьма своеобразна - со стандартными шрифтами изображения букв отображаются не в соответствии с кодами Unicode, а по таблице Cp1251 (кодировка Ansi). Эта ошибка зарегистрирована в BugParade под номером . По умолчанию в Swing используются шрифты, задаваемые в файле font.properties.ru, так что достаточно заменить их другими - и русские буквы появляются. К сожалению, набор рабочих шрифтов небольшой - это шрифты Tahoma, Tahoma Bold и два набора шрифтов из дистрибутива JDK - Lucida Sans * и Lucida Typewriter * (пример файла font.properties.ru). Чем эти шрифты отличаются от стандартных - мне непонятно.

Начиная с версии 1.3rc1 эта проблема уже исправлена, так что можно просто обновить JDK. Так же надо учесть, что с оригинальной версией Win95 поставляются шрифты, не поддерживающие Unicode - в этой ситуации можно просто скопировать шрифты из Win98 или WinNT.

Если же вам, кровь из носу, нужно использовать стандартные шрифты, работая в JDK 1.2, то можно компенсировать этот глюк, перекодировав строки текста непосредственно перед выводом. Сделать это можно, например, так:

public static String convertToWin9x(String s) { byte bb; try { bb = s.getBytes("Cp1251"); } catch(java.io.UnsupportedEncodingException e) { return s; } char cb = new char; for(int i=0; i < bb.length; i++) { cb[i] = (char)(bb[i] & 0x00FF); } return new String(cb); }
Но только не забудьте - этот код будет работать только под Win9x и Sun JDK/JRE 1.2.

По поводу компилятора jikes. Как мне рассказали в конференции по Java (fido7.ru.java) при использовании этого компилятора русские буквы тоже появляются. Это на самом деле классический пример того, как один глюк компенсирует другой - jikes просто не учитывает кодировку исходников. Того же эффекта можно добиться, если указать javac кодировку ISO-8859-1 (Latin1) в ключике -encoding. Если при этом в исходниках русские символы записаны в кодировке Cp1251, то тем самым они вместо диапазона 0x400-0x4ff (стандартный диапазон Unicode для кириллицы) попадают в диапазон 0x80-0xff. Из-за вышеупомянутого глюка в среде Win9x кириллица в стандартных шрифтах отображается как раз в этом диапазоне и русские буквы появляются. Если же попробовать запустить программу в другой среде (например, в WinNT) - русских букв не будет, так как там этот глюк отсутствует.

Аналогично на подобную компенсацию можно нарваться, если поменять региональные настройки с русских на буржуйские. При этом, кроме всего прочего, меняется и кодировка по умолчанию (file.encoding) - вместо 1251 становится 1252. Это приводит к тому, что, если при чтении файлов кодировка не была явно указана (и при компиляции не задавался ключик -encoding), то русские буквы переезжают в диапазон 0x80-0xff и создаётся впечатление нормальной работы. Разницу можно заметить на преобразованиях регистра и сортировках через java.text.Collator - они будут выполняться неверно. А если были использованы строковые константы - то на других платформах вы увидите только кракозяблы.

Ещё один способ - скачать версию Swing для JDK 1.1 и запускать приложение из под Microsoft JVM - там всё выводится корректно. Только не забудьте обновить MS JVM - те версии, что идут в комплекте с IE 4.x не совсем корректно работают. С сервера Microsoft можно скачать свежую версию, например 5.00.3240 - с ней всё ОК.

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

I18n (вывод чисел, дат и т.п.)

Загадочная комбинация i18n расшифровывается просто - это сокращение от могучего слова Internationalization. 18 - это кол-во букв между i и n. Означает оно, в контексте Java, возможность автоматической подстройки программы под текущий язык и специфику страны. Делается это через использование класса Locale, представляющего язык и конкретную страну, и классов, которые знают, что с этим Locale делать. Большинство этих классов находятся в пакете java.text.

Основной класс, которым пользуются все остальные, - это java.util.ResourceBundle, который позволяет загружать различные виды ресурсов. Причём имя загружаемого класса или файла properties зависит от указанного Locale (или Locale по умолчанию - если ничего не указанно).

Имя искомого файла формируется при помощи добавления идентификатора языка и страны к имени ресурса. Например, если грузится ресурс resfile, а текущий Locale - ru_RU, то поиск его будет идти в следующем порядке:

  1. resfile_ru_RU.class
  2. resfile_ru_RU.properties
  3. resfile_ru.class
  4. resfile_ru.properties
  5. resfile.class
  6. resfile.properties

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

Что касается дат, то само форматирование выполняется классом DateFormat. Получить формат, уже настроенный на язык и страну можно при помощи методов getDateInstance(), getTimeInstance() и getDateTimeInstance(). В качестве аргумента можно указать одну из констант для задания необходимого стиля формата. По умолчанию будет использован предпочтительный стиль для данного Locale. Допустимые константы:

Пример:
// Вывод пользователю текущей даты DateFormat df = DateFormat.getDateInstance(); String s = df.format(new Date()); ... // Вывод текущего времени без секунд DateFormat df = DateFormat. getTimeInstance(DateFormat.SHORT); String s = df.format(new Date());

Если же вы хотите сами контролировать набор выводимых полей и их разделители, то для этого можно использовать класс SimpleDateFormat.

Аналогичным образом делается и форматирование чисел. За это отвечает класс NumberFormat. Получить форматы можно при помощи методов getInstance(), getNumberInstance(), getCurrencyInstance() и getPercentInstance(). Свой формат можно сконструировать при помощи класса DecimalFormat.

Об утилите native2ascii

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

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

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

String res = new String (src.getBytes("ISO-8859-1"),"Cp1251");
Проблем в использовании этого приёма может быть несколько. Например, для восстановления используется неверная страница, или же она может измениться в некоторых ситуациях. Другая проблема может быть в том, что некоторые страницы выполняют неоднозначное преобразование byte <-> char. Смотрите, например, описание ошибки за номером .

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

Наташа 26 октября 2013 в 22:59

Баг или фича в Java: Вывод кириллических символов в консоль

  • Java

Есть много особенностей, про которые желательно знать, программируя на Java, даже если Вы начинающий программист. Под катом я расскажу как вывести кириллические символы в консоль Windows и наглядно это продемонстрирую.
Начнем с простого.

Базовые типы

Их в Java 8:

  • boolean;
  • byte, char, short, int, long;
  • float, double.

Char - это символьный тип данных. Переменная такого типа занимает 2 байта памяти, так как хранится в кодировке unicode.
С переменными этого типа можно производить только операции присваивания, но зато различными способами. Самый простой из них выглядит так:
c = "b";
Символ можно представить также в виде его кода, записанного в восьмеричной системе счисления:
c = "\077";
Где 077 – это обязательно трехзначное число, не большее чем 377 (=255 в десятичной системе счисления).
Или же в шестнадцатеричной системе счисления следующим образом:
c = "\u12a4";
Кроме того, существуют специальные символы, такие как знак абзаца, разрыв страницы и др. Знак абзаца запишется, например, так:
c = "\n";
Не нужно перечислять их здесь. При необходимости всегда можно заглянуть в справочник.

Теперь внимание. Кодировкой по-умолчанию среды программирования Java является Latin-1. Однако, при выводе в поток System.out символы преобразуются в кодировку по умолчанию для операционной системы. Так для русскоязычной локализации кодировкой по-умолчанию является Windows-1251, для linux таковой будет UTF-8. Однако по задумке Microsoft решили для консоли Windows использовать кодировку Cp866.

Соответственно вывод: для корректного отображения кириллических символов в консоли нужно выводить символы в кодировке Cp866!

Это можно сделать следующим способом:

Import java.io.PrintStream;
import java.io.UnsupportedEncodingException;

Public class Hello {
public static void main(String args) throws UnsupportedEncodingException { /*Может возникнуть исключение типа UnsupportedEncodingException*/
String x = "Привет, мир!!!"; //Это строка, которую мы будем выводить на экран
PrintStream printStream = new PrintStream(System.out, true, "cp866");
/*Создаем новый поток вывода, который будет автоматически преобразоввывать символы в кодировку Cp866*/
printStream.println(x);
}
}
Сохраним полученный код в файл Hello.java. Далее создадим Hello.bat файл следующего содержания:
javac Hello.java
java -cp . Hello
pause
И поместим его в одну папку с файлом Hello.java. Должно получиться примерно так:

Далее запускаем полученный Hello.bat файл и вуаля, у нас образовался файл Hello.class в той же директории а на экран вывелось сообщение «Привет, мир!!!» в кодировке Cp866.

Для того, чтобы узнать, какая кодировка в данный момент используется в консоли нужно набрать там «chcp». А для того, чтобы поменять кодировку консоли, нужно набрать «chcp <номер кодовой таблицы>» например «chcp 1251». Продемонстрирую использование этой команды:

Замечание: если у Вас не находит команду javac, то заходим (для Windows 7) «Мой компьютер» - «Свойства» - «Дополнительные параметры системы» - «Переменные среды», находим «Системные переменные» и в переменную Path добавляем строку, куда установлена JDK, например «C:\Program Files\Java\jdk1.7.0_25\bin» - по умолчанию.

Кодировки

Когда я только начинал программировать на языке C, первой моей программой (не считая HelloWorld) была программа перекодировки текстовых файлов из основной кодировки ГОСТ-а (помните такую? :-) в альтернативную. Было это в далёком 1991-ом году. С тех пор многое изменилось, но за прошедшие 10 лет подобные программки свою актуальность, к сожалению, не потеряли. Слишком много уже накоплено данных в разнообразных кодировках и слишком много используется программ, которые умеют работать только с одной. Для русского языка существует не менее десятка различных кодировок, что делает проблему ещё более запутанной.

Откуда же взялись все эти кодировки и для чего они нужны? Компьютеры по своей природе могут работать только с числами. Для того чтобы хранить буквы в памяти компьютера надо поставить в соответствие каждой букве некое число (примерно такой же принцип использовался и до появления компьютеров - вспомните про ту же азбуку Морзе). Причём число желательно поменьше - чем меньше двоичных разрядов будет задействовано, тем эффективнее можно будет использовать память. Вот это соответствие набора символов и чисел собственно и есть кодировка. Желание любой ценой сэкономить память, а так же разобщённость разных групп компьютерщиков и привела к нынешнему положению дел. Самым распространённым способом кодирования сейчас является использование для одного символа одного байта (8 бит), что определяет общее кол-во символов в 256. Набор первых 128 символов стандартизован (набор ASCII) и является одинаковыми во всех распространённых кодировках (те кодировки, где это не так уже практически вышли из употребления). Англицкие буковки и символы пунктуации находятся в этом диапазоне, что и определяет их поразительную живучесть в компьютерных системах:-). Другие языки находятся не в столь счастливом положении - им всем приходится ютиться в оставшихся 128 числах.

Unicode

В конце 80-х многие осознали необходимость создания единого стандарта на кодирование символов, что и привело к появлению Unicode. Unicode - это попытка раз и навсегда зафиксировать конкретное число за конкретным символом. Понятно, что в 256 символов тут не уложишься при всём желании. Довольно долгое время казалось, что уж 2-х то байт (65536 символов) должно хватить. Ан нет - последняя версия стандарта Unicode (3.1) определяет уже 94140 символов. Для такого кол-ва символов, наверное, уже придётся использовать 4 байта (4294967296 символов). Может быть и хватит на некоторое время... :-)

В набор символов Unicode входят всевозможные буквы со всякими чёрточками и припендюльками, греческие, математические, иероглифы, символы псевдографики и пр. и пр. В том числе и так любимые нами символы кириллицы (диапазон значений 0x0400-0x04ff). Так что с этой стороны никакой дискриминации нет.

Если Вам интересны конкретные кода символов, для их просмотра удобно использовать программу "Таблица символов" из WinNT. Вот, например, диапазон кириллицы:

Если у Вас другая OS или Вас интересует официальное толкование, то полную раскладку символов (charts) можно найти на официальном сайте Unicode (http://www.unicode.org/charts/web.html).

Типы char и byte

В Java для символов выделен отдельный тип данных char размером в 2 байта. Это часто порождает путаницу в умах начинающих (особенно если они раньше программировали на других языках, например на C/C++). Дело в том, что в большинстве других языков для обработки символов используются типы данных размером в 1 байт. Например, в C/C++ тип char в большинстве случаев используется как для обработки символов, так и для обработки байтов - там нет разделения. В Java для байтов имеется свой тип - тип byte . Таким образом C-ишному char соответствует Java-вский byte , а Java-вскому char из мира C ближе всего тип wchar_t . Надо чётко разделять понятия символов и байтов - иначе непонимание и проблемы гарантированны.

Java практически с самого своего рождения использует для кодирования символов стандарт Unicode. Библиотечные функции Java ожидают увидеть в переменных типа char символы, представленные кодами Unicode. В принципе, Вы, конечно, можете запихнуть туда что угодно - цифры есть цифры, процессор всё стерпит, но при любой обработке библиотечные функции будут действовать исходя из предположения что им передали кодировку Unicode. Так что можно спокойно полагать, что у типа char кодировка зафиксирована. Но это внутри JVM. Когда данные читаются извне или передаются наружу, то они могут быть представлены только одним типом - типом byte . Все прочие типы конструируются из байтов в зависимости от используемого формата данных. Вот тут то на сцену и выходят кодировки - в Java это просто формат данных для передачи символов, который используется для формирования данных типа char . Для каждой кодовой страницы в библиотеке имеется по 2 класса перекодировки (ByteToChar и CharToByte). Классы эти лежат в пакете sun.io . Если, при перекодировке из char в byte не было найдено соответствующего символа, он заменяется на символ?.

Кстати, эти файлы кодовых страниц в некоторых ранних версиях JDK 1.1 содержат ошибки, вызывающие ошибки перекодировок, а то и вообще исключения при выполнении. Например, это касается кодировки KOI8_R. Лучшее, что можно при этом сделать - сменить версию на более позднюю. Судя по Sun-овскому описанию, большинство этих проблем было решено в версии JDK 1.1.6.

До появления версии JDK 1.4 набор доступных кодировок определялся только производителем JDK. Начиная с 1.4 появилось новое API (пакет java.nio.charset), при помощи которого Вы уже можете создать свою собственную кодировку (например поддержать редко используемую, но жутко необходимую именно Вам).

Класс String

В большинстве случаев для представления строк в Java используется объект типа java.lang.String . Это обычный класс, который внутри себя хранит массив символов (char), и который содержит много полезных методов для манипуляции символами. Самые интересные - это конструкторы, имеющие первым параметром массив байтов (byte) и методы getBytes() . При помощи этих методов Вы можете выполнять преобразования из массива байтов в строки и обратно. Для того, чтобы указать какую кодировку при этом использовать у этих методов есть строковый параметр, который задаёт её имя. Вот, например, как можно выполнить перекодировку байтов из КОИ-8 в Windows-1251:

// Данные в кодировке КОИ-8 byte koi8Data = ...; // Преобразуем из КОИ-8 в Unicode String string = new String(koi8Data,"KOI8_R"); // Преобразуем из Unicode в Windows-1251 byte winData = string.getBytes("Cp1251");

Список 8-ми битовых кодировок, доступных в современных JDK и поддерживающих русские буквы Вы можете найти ниже, в разделе .

Так как кодировка - это формат данных для символов, кроме знакомых 8-ми битовых кодировок в Java также на равных присутствуют и многобайтовые кодировки. К таким относятся UTF-8, UTF-16, Unicode и пр. Например вот так можно получить байты в формате UnicodeLittleUnmarked (16-ти битовое кодирование Unicode, младший байт первый, без признака порядка байтов):

// Преобразуем из Unicode в UnicodeLittleUnmarked byte data = string.getBytes("UnicodeLittleUnmarked");

При подобных преобразованиях легко ошибиться - если кодировка байтовых данных не соотвествуют указанному параметру при преобразовании из byte в char , то перекодирование будет выполнено неправильно. Иногда после этого можно вытащить правильные символы, но чаще всего часть данных будет безвозвратно потеряна.

В реальной программе явно указывать кодовую страницу не всегда удобно (хотя более надёжно). Для этого была введена кодировка по умолчанию. По умолчанию она зависит от системы и её настроек (для русских виндов принята кодировка Cp1251), и в старых JDK её можно изменить установкой системного свойства file.encoding . В JDK 1.3 изменение этой настройки иногда срабатывает, иногда - нет. Вызвано это следующим: первоначально file.encoding ставится по региональным настройкам компьютера. Ссылка на кодировку по умолчанию запоминается в нутрях при первом преобразовании. При этом используется file.encoding, но это преобразование происходит ещё до использования аргументов запуска JVM (собсно, при их разборе). Вообще-то, как утверждают в Sun, это свойство отражает системную кодировку, и она не должна изменяться в командной строке (см., например, комментарии к BugID ) Тем не менее в JDK 1.4 Beta 2 смена этой настройки опять начала оказывать эффект. Что это, сознательное изменение или побочный эффект, который может опять исчезнуть - Sun-овцы ясного ответа пока не дали.

Эта кодировка используется тогда, когда явно не указанно название страницы. Об этом надо всегда помнить - Java не будет пытаться предсказать кодировку байтов, которые Вы передаёте для создания строки String (так же она не сможет прочитать Ваши мысли по этому поводу:-). Она просто использует текущую кодировку по умолчанию. Т.к. эта настройка одна на все преобразования, иногда можно наткнуться на неприятности.

Для преобразования из байтов в символы и обратно следует пользовать только этими методами. Простое приведение типа использовать в большинстве случаев нельзя - кодировка символов при этом не будет учитываться. Например, одной из самых распространённых ошибок является чтение данных побайтно при помощи метода read() из InputStream, а затем приведение полученного значения к типу char:

InputStream is = ..; int b; StringBuffer sb = new StringBuffer(); while((b=is.read())!=-1) { sb.append((char)b); // <- так делать нельзя } String s = sb.toString();

Обратите внимание на приведение типа - " (char)b ". Значения байтов вместо перекодирования просто скопируются в char (диапазон значений 0-0xFF, а не тот, где находится кириллица). Такому копированию соответствует кодировка ISO-8859-1 (которая один в один соответствует первым 256 значениям Unicode), а значит, можно считать, что этот код просто использует её (вместо той, в которой реально закодированы символы в оригинальных данных). Если Вы попытаетесь отобразить полученное значение - на экране будут или вопросики или кракозяблы. Например, при чтении строки "АБВ" в виндовой кодировке может запросто отобразиться что-то вроде такого: "ÀÁÂ". Подобного рода код часто пишут программисты на западе - с английскими буквами работает, и ладно. Исправить такой код легко - надо просто заменить StringBuffer на ByteArrayOutputStream:

InputStream is = ..; int b; ByteArrayOutputStream baos = new ByteArrayOutputStream(); while((b=is.read())!=-1) { baos.write(b); } // Перекодирование байтов в строку с использованием кодировки по умолчанию String s = baos.toString(); // Если нужна конкретная кодировка - просто укажите её при вызове toString(): // // s = baos.toString("Cp1251");
Более подробно о распространённых ошибках смотрите раздел .

8-ми битовые кодировки русских букв

Вот основные 8-ми битовые кодировки русских букв, получившие распространение:

Помимо основного названия можно использовать синонимы. Набор их может отличаться в разных версиях JDK. Вот список от JDK 1.3.1:

  • Cp1251:
    • Windows-1251
  • Cp866:
    • IBM866
    • IBM-866
    • CP866
    • CSIBM866
  • KOI8_R:
    • KOI8-R
    • CSKOI8R
  • ISO8859_5:
    • ISO8859-5
    • ISO-8859-5
    • ISO_8859-5
    • ISO_8859-5:1988
    • ISO-IR-144
    • 8859_5
    • Cyrillic
    • CSISOLatinCyrillic
    • IBM915
    • IBM-915
    • Cp915

Причём синонимы, в отличии от основного имени нечувствительны к регистру символов - такова особенность реализации.

Стоит отметить, что эти кодировки на некоторых JVM могут отсутствовать. Например, с сайта Sun можно скачать две разные версии JRE - US и International. В US версии присутствует только минимум - ISO-8859-1, ASCII, Cp1252, UTF8, UTF16 и несколько вариаций двухбайтового Unicode. Всё прочее есть только в International варианте. Иногда из-за этого можно нарваться на грабли с запуском программы, даже если ей не нужны русские буквы. Типичная ошибка, возникающая при этом:

Error occurred during initialization of VM java/lang/ClassNotFoundException: sun/io/ByteToCharCp1251

Возникает она, как не трудно догадаться, из-за того, что JVM, исходя из русских региональных настроек пытается установить кодировку по умолчанию в Cp1251, но, т.к. класс поддержки таковой отсутствует в US версии, закономерно обламывается.

Файлы и потоки данных

Так же как и байты концептуально отделены от символов, в Java различаются потоки байтов и потоки символов. Работу с байтами представляют классы, которые прямо или косвенно наследуют классы InputStream или OutputStream (плюс класс-уникум RandomAccessFile). Работу с символами представляет сладкая парочка классов Reader/Writer (и их наследники, разумеется).

Для чтения/записи не преобразованных байтов используются потоки байтов. Если известно, что байты представляют собой только символы в некоторой кодировке, можно использовать специальные классы-преобразователи InputStreamReader и OutputStreamWriter, чтобы получить поток символов и работать непосредственно с ним. Обычно это удобно в случае обычных текстовых файлов или при работе с многими сетевыми протоколами Internet. Кодировка символов при этом указывается в конструкторе класса-преобразователя. Пример:

// Строка Unicode String string = "..."; // Записываем строку в текстовый файл в кодировке Cp866 PrintWriter pw = new PrintWriter // класс с методами записи строк (new OutputStreamWriter // класс-преобразователь (new FileOutputStream ("file.txt"), "Cp866"); pw.println(string); // записываем строку в файл pw.close();

Если в потоке могут присутствовать данные в разных кодировках или же символы перемешаны с прочими двоичными данными, то лучше читать и записывать массивы байтов (byte), а для перекодировки использовать уже упомянутые методы класса String. Пример:

// Строка Unicode String string = "..."; // Записываем строку в текстовый файл в двух кодировках (Cp866 и Cp1251) OutputStream os = new FileOutputStream("file.txt"); // класс записи байтов в файл // Записываем строку в кодировке Cp866 os.write(string.getBytes("Cp866")); // Записываем строку в кодировке Cp1251 os.write(string.getBytes("Cp1251")); os.close();

Консоль в Java традиционно представлена потоками, но, к сожалению, не символов, а байтов. Дело в том, что потоки символов появились только в JDK 1.1 (вместе со всем механизмом кодировок), а доступ к консольному вводу/выводу проектировался ещё в JDK 1.0, что и привело к появлению уродца в виде класса PrintStream. Этот класс используется в переменных System.out и System.err, которые собственно и дают доступ к выводу на консоль. По всем признакам это поток байтов, но с кучей методов записи строк. Когда Вы записываете в него строку, внутри происходит конвертация в байты с использованием кодировки по умолчанию, что в случае виндов, как правило, неприемлемо - кодировка по умолчанию будет Cp1251 (Ansi), а для консольного окна обычно нужно использовать Cp866 (OEM). Эта ошибка была зарегистрированна ещё в 97-ом году () но Sun-овцы исправлять её вроде не торопятся. Так как метода установки кодировки в PrintStream нет, для решения этой проблемы можно подменить стандартный класс на собственный при помощи методов System.setOut() и System.setErr(). Вот, например, обычное начало в моих программах:

... public static void main(String args) { // Установка вывода консольных сообщений в нужной кодировке try { String consoleEnc = System.getProperty("console.encoding","Cp866"); System.setOut(new CodepagePrintStream(System.out,consoleEnc)); System.setErr(new CodepagePrintStream(System.err,consoleEnc)); } catch(UnsupportedEncodingException e) { System.out.println("Unable to setup console codepage: " + e); } ...

Исходники класса CodepagePrintStream Вы можете найти на данном сайте: CodepagePrintStream.java .

Если Вы сами конструируете формат данных, я рекомендую Вам использовать одну из многобайтовых кодировок. Удобнее всего обычно формат UTF8 - первые 128 значений (ASCII) в нём кодируются одним байтом, что часто может значительно уменьшить общий объём данных (не зря эта кодировка принята за основу в мире XML). Но у UTF8 есть один недостаток - кол-во требуемых байтов зависит от кода символов. Там, где это критично можно использовать один из двухбайтовых форматов Unicode (UnicodeBig или UnicodeLittle).

Базы данных

Для того, чтобы прочитать корректно символы из БД, обычно достаточно указать JDBC-драйверу на нужную кодировку символов в БД. Как именно - это зависит от конкретного драйвера. Сейчас уже многие драйвера поддерживают подобную настройку, в отличии от недавнего прошлого. Далее приведены несколько известных мне примеров.

Мост JDBC-ODBC

Это один из самых часто используемых драйверов. Мост из JDK 1.2 и старше можно легко настроить на нужную кодировку. Это делается добавлением дополнительного свойства charSet в набор параметров, передаваемых для открытия соединения с базой. По умолчанию используется file.encoding . Делается это примерно так:

// Устанавливаем соединение

Драйвер JDBC-OCI от Oracle 8.0.5 под Linux

При получении данных из БД, данный драйвер определяет "свою" кодировку при помощи переменной окружения NLS_LANG. Если эта переменная не найдена, то он считает что кодировка - ISO-8859-1. Весь фокус в том, что NLS_LANG должна быть именно переменной окружения (устанавливаемой командой set), а не системное свойство Java (типа file.encoding). В случае использования драйвера внутри servlet engine Apache+Jserv, переменную окружения можно задать в файле jserv.properties:

wrapper.env=NLS_LANG=American_America.CL8KOI8R
Информацию об этом прислал Сергей Безруков , за что ему отдельное спасибо.

Драйвер JDBC для работы с DBF (zyh.sql.dbf.DBFDriver)

Данный драйвер только недавно научился работать с русскими буквами. Хоть он и сообщает по getPropertyInfo() что он понимает свойство charSet - это фикция (по крайней мере в версии от 30.07.2001). Реально же настроить кодировку можно установкой свойства CODEPAGEID. Для русских символов там доступны два значения - "66" для Cp866 и "C9" для Cp1251. Пример:

// Параметры соединения с базой Properties connInfo = new Properties(); connInfo.put("CODEPAGEID", "66"); // Кодировка Cp866 // Устанавливаем соединение Connection db = DriverManager.getConnection("jdbc:DBF:/C:/MyDBFFiles", connInfo);
Если у Вас DBF-файлы формата FoxPro, то у них своя специфика. Дело в том, что FoxPro сохраняет в заголовке файла ID кодовой страницы (байт со смещением 0x1D), которая использовалась при создании DBF-ки. При открытии таблицы драйвер использует значение из заголовка, а не параметр "CODEPAGEID" (параметр в этом случае используется только при создании новых таблиц). Соответственно, чтобы всё работало нормально, DBF-файл должен быть создан с правильной кодировкой - иначе будут проблемы.

MySQL (org.gjt.mm.mysql.Driver)

С этим драйвером тоже всё довольно просто:

// Параметры соединения с базой Properties connInfo = new Poperties(); connInfo.put("user",user); connInfo.put("password",pass); connInfo.put("useUnicode","true"); connInfo.put("characterEncoding","KOI8_R"); Connection conn = DriverManager.getConnection(dbURL, props);

InterBase (interbase.interclient.Driver)

Для этого драйвера работает параметр "charSet":
// Параметры соединения с базой Properties connInfo = new Properties(); connInfo.put("user", username); connInfo.put("password", password); connInfo.put("charSet", "Cp1251"); // Устанавливаем соединение Connection db = DriverManager.getConnection(dataurl, connInfo);

Однако не забудьте при создании БД и таблиц указать кодировку символов. Для русского языка можно использовать значения "UNICODE_FSS" или "WIN1251". Пример:

CREATE DATABASE "E:\ProjectHolding\DataBase\HOLDING.GDB" PAGE_SIZE 4096 DEFAULT CHARACTER SET UNICODE_FSS; CREATE TABLE RUSSIAN_WORD ("NAME1" VARCHAR(40) CHARACTER SET UNICODE_FSS NOT NULL, "NAME2" VARCHAR(40) CHARACTER SET WIN1251 NOT NULL, PRIMARY KEY ("NAME1"));

В версии 2.01 InterClient присутствует ошибка - классы ресурсов с сообщениями для русского языка там неправильно скомпилированы. Скорей всего разработчики просто забыли указать кодировку исходников при компиляции. Есть два пути исправления этой ошибки:

  • Использовать interclient-core.jar вместо interclient.jar. При этом русских ресурсов просто не будет, и автоматом подхватятся английские.
  • Перекомпилировать файлы в нормальный Unicode. Разбор class-файлов - дело неблагодарное, поэтому лучше воспользоваться JAD-ом. К сожалению JAD, если встречает символы из набора ISO-8859-1, выводит их в 8-иричной кодировке, так что воспользоваться стандартным перекодировщиком native2ascii не удастся - придётся написать свой (программа Decode). Если Вам не хочется заморачиваться с этими проблемами - можете просто взять готовый файл с ресурсами (пропатченый jar с драйвером - interclient.jar , отдельные классы ресурсов - interclient-rus.jar).

Но даже настроив JDBC-драйвер на нужную кодировку в некоторых случаях можно нарваться на неприятности. Например, при попытке использования новых замечательных скролируемых курсоров стандарта JDBC 2 в мосте JDBC-ODBC из JDK 1.3.x довольно быстро можно обнаружить, что русские буквы там просто не работают (метод updateString()).

С этой ошибкой связанна небольшая история. Когда я впервые её обнаружил (под JDK 1.3 rc2), я зарегистрил её на BugParade (). Когда вышла первая бета JDK 1.3.1, эту ошибку пометили как пофиксеную. Обрадованный, я скачал эту бету, запустил тест - не работает. Написал Sun-овцам об этом - в ответ мне написали, что фикс будет включён в последующие релизы. Ну ладно, подумал я, подождём. Время шло, вышел релиз 1.3.1, а потом и бета 1.4. Наконец я нашёл время проверить - опять не работает. Мать, мать, мать... - привычно откликнулось эхо. После гневного письма в Sun они завели новую ошибку (), которую отдали на растерзание индийскому филиалу. Индусы пошаманили над кодом, и заявили, что в 1.4 beta3 всё исправлено. Скачал я эту версию, запустил под ним тестовый пример, вот результат - . Как оказалось, та beta3, которую раздают на сайте (build 84) это не та beta3, куда был включён окончательный фикс (build 87). Теперь обещают, что исправление войдёт в 1.4 rc1... Ну, в общем, Вы понимаете:-)

Русские буквы в исходниках Java-программ

Как уже упоминалось, при выполнении программы используется Unicode. Исходные же файлы пишутся в обычных редакторах. Я пользуюсь Far-ом, у Вас, наверняка есть свой любимый редактор. Эти редакторы сохраняют файлы в 8-битовом формате, а значит, что к этим файлам также применимы рассуждения, аналогичные приведённым выше. Разные версии компиляторов немного по разному выполняют преобразование символов. В ранних версиях JDK 1.1.x используется настройка file.encoding , которую можно поменять при помощи нестандартной опции -J. В более новых (как сообщил Денис Кокарев - начиная с 1.1.4) был введён дополнительный параметр -encoding, при помощи которого можно указать используемую кодировку. В скомпилированных классах строки представлены в виде Unicode (точнее в модифицированном варианте формата UTF8), так что самое интересное происходит при компиляции. Поэтому, самое главное - выяснить, в какой кодировке у Вас исходники и указать правильное значение при компиляции. По умолчанию будет использован всё тот же пресловутый file.encoding . Пример вызова компилятора:

Кроме использования этой настройки есть ещё один метод - указывать буквы в формате "\uXXXX", где указывается код символа. Этот метод работает со всеми версиями, а для получения этих кодов можно использовать стандартную утилиту .

Если Вы пользуетесь каким-либо IDE, то у него могут быть свои глюки. Зачастую эти IDE пользуются для чтения/сохранения исходников кодировку по умолчанию - так что обращайте внимание на региональные настройки своей ОС. Кроме этого могут быть и явные ошибки - например довольно неплохая IDE-шка CodeGuide плохо переваривает заглавную русскую букву "Т". Встроенный анализатор кода принимает эту букву за двойную кавычку, что приводит к тому, что корректный код воспринимается как ошибочный. Бороться с этим можно (заменой буквы "Т" на её код "\u0422"), но неприятно. Судя по всему где-то внутри парсера применяется явное преобразование символов в байты (типа: byte b = (byte)c), поэтому вместо кода 0x0422 (код буквы "Т") получается код 0x22 (код двойной кавычки).

Другая проблема встречается у JBuilder, но она больше связанна с эргономикой. Дело в том, что в JDK 1.3.0, под которым по умолчанию работает JBuilder, имеется бага (), из-за которой вновь создаваемые окна GUI при активизации автоматически включают раскладку клавиатуры в зависимости от региональных настроек ОС. Т.е. если у Вас русские региональные настройки, то он будет постоянно пытаться переключиться на русскую раскладку, что при написании программ жутко мешается. На сайте JBuilder.ru есть парочка патчиков которые меняют текущую локаль в JVM на Locale.US, но самый лучший способ - перейти на JDK 1.3.1, в котором данная бага пофиксена.

Начинающие пользователи JBuilder могут также встретиться с такой проблемой - русские буквы сохраняются в виде кодов "\uXXXX". Чтобы этого избежать, надо в диалоге Default Project Properties, закладка General, в поле Encoding поменять Default на Cp1251.

Если Вы используете для компиляции не стандартный javac, а другой компилятор - обратите внимание на то, как он выполняет преобразование символов. Например, некоторые версии IBM-овского компилятора jikes не понимают, что бывают кодировки, отличные от ISO-8859-1:-). Существуют версии, пропатченые на этот счёт, но часто там тоже зашивается некоторая кодировка - нет такого удобства, как в javac.

JavaDoc

Для генерации HTML-документации по исходникам используется утилита javadoc, входящая в стандартную поставку JDK. Для указания кодировок у неё есть аж 3 параметра:

  • -encoding - эта настройка задаёт кодировку исходников. По умолчанию используется file.encoding.
  • -docencoding - эта настройка задаёт кодировку генерируемых HTML-файлов. По умолчанию используется file.encoding.
  • -charset - эта настройка задаёт кодировку, которая будет записываться в заголовки генерируемых HTML-файлов (). Очевидно, что она должна совпадать с предыдущей настройкой. Если данная настройка опущена, то тег meta добавляться не будет.

Русские буквы в файлах properties

Для чтения файлов properties используются методы загрузки ресурсов, которые работают специфичным образом. Собственно для чтения используется метод Properties.load, который не использует file.encoding (там в исходниках жёстко указана кодировка ISO-8859-1), поэтому единственный способ указать русские буквы - использовать формат "\uXXXX" и утилиту .

Метод Properties.save работает по разному в версиях JDK 1.1 и 1.2. В версиях 1.1 он просто отбрасывал старший байт, поэтому правильно работал только с англицкими буквами. В 1.2 делается обратное преобразование в "\uXXXX", так что он работает зеркально к методу load.

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

Русские буквы в Servlet-ах.

Ну, для чего эти самые Servlet-ы нужны, я думаю, Вы в курсе. Если нет - то лучше сначала прочитать документацию. Здесь же рассказывается только об особенностях работы с русскими буквами.

Так в чём же особенности? Когда Servlet посылает ответ клиенту, есть два способа послать этот ответ - через OutputStream (метод getOutputStream()) или через PrintWriter (метод getWriter()). В первом случае Вы записываете массивы байтов, поэтому применимы вышеописанные методы записи в потоки. В случае же PrintWriter, он использует установленную кодировку. В любом случае необходимо правильно указать используемую кодировку при вызове метода setContentType(), для того, чтобы было правильное преобразование символов на стороне сервера. Это указание должно быть сделано перед вызовом getWriter() или перед первой записью в OutputStream. Пример:

// Установка кодировки ответа // Учтите, что некоторые engine не допускают // наличие пробела между ";" и "charset" response.setContentType("text/html;charset=UTF-8"); PrintWriter out = response.getWriter(); // Отладочный вывод названия кодировки для проверки out.println("Encoding: " + response.getCharacterEncoding()); ... out.close(); }

Это по поводу отдачи ответов клиенту. Со входными параметрами, к сожалению не так просто. Входные параметры кодируются броузером побайтно в соответствии с MIME-типом "application/x-www-form-urlencoded". Как рассказал Алексей Менделев русские буквы броузеры кодируют, используя текущую установленную кодировку. Ну и, разумеется, ничего о ней не сообщают. Соответственно, например, в JSDK версий от 2.0 до 2.2 это никак не проверяется, а то, что за кодировка будет использована для преобразования - зависит от используемого engine. Начиная со спецификации 2.3 появилась возможность устанавливать кодировку для javax.servlet.ServletRequest - метод setCharacterEncoding(). Эту спецификацию уже поддерживают последние версии Resin и Tomcat .

Таким образом, если Вам повезло, и у Вас стоит сервер с поддержкой Servlet 2.3, то всё довольно просто:

public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException { // Кодировка сообщений request.setCharacterEncoding("Cp1251"); String value = request.getParameter("value"); ...

В применении метода request.setCharacterEncoding() есть одна существенная тонкость - он должен быть применен до первого обращения к запросу за данными (например request.getParameter()). Если Вы используете фильтры, которые обрабатывают запрос до того как он приходит в сервлет, есть ненулевая вероятность того, что в одном из фильтров может произойти чтение какого-нибудь параметра из запроса (например для авторизации) и request.setCharacterEncoding() в сервлете не сработает.

Потому идеологически более правильно написать фильтр, устанавливающий кодировку запроса. При этом он должен стоять первым в цепочке фильтров в web.xml.

Пример такого фильтра:

import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; public class CharsetFilter implements Filter { // кодировка private String encoding; public void init(FilterConfig config) throws ServletException { // читаем из конфигурации encoding = config.getInitParameter("requestEncoding"); // если не установлена - устанавливаем Cp1251 if(encoding==null) encoding="Cp1251"; } public void doFilter(ServletRequest request, ServletResponse response, FilterChain next) throws IOException, ServletException { request.setCharacterEncoding(encoding); next.doFilter(request, response); } public void destroy(){} }

И его конфигурации в web.xml:

Charset Filter CharsetFilter Charset Filter /*

Если же Вам не повезло, и у Вас более старая версия - для достижения результата придётся поизвращаться:

    Оригинальный способ работы с кодировками предлагает Russian Apache - расписано, как именно.

  • FOP

    Если программа не работает нигде - значит проблема только в ней и в Ваших руках. Внимательно перечитайте всё, что было написано выше, и ищите. Если же проблема проявляется только в конкретном окружении - значит дело, возможно в настройках. Где именно - зависит от того, какой графической библиотекой Вы пользуетесь. Если AWT - помочь может правильная настройка файла font.properties.ru. Пример корректного файла можно взять из Java 2. Если у Вас нет этой версии, можете скачать его с данного сайта: версия для Windows , версия для Linux (см. также ниже). Этот файл задаёт используемые шрифты и кодовые страницы. Если у Вас установлена русская версия OS - просто добавьте этот файл туда, где лежит файл font.properties. Если же это англицкая версия, то нужно, или переписать этот файл вместо font.properties или дополнительно сменить текущие региональные настройки на русские. Иногда может сработать настройка -Duser.language=ru , но чаще - нет. Тут примерно те же проблемы, что и с file.encoding - сработает или нет, зависит от JDK (см. ошибку за номером ).

    С библиотекой Swing всё проще - в ней всё рисуется через подсистему Java2D. Надписи в стандартных диалогах (JOptionPane, JFileChooser, JColorChooser) переделать на русский очень просто - достаточно лишь создать несколько файлов ресурсов. Я это уже проделал, так что можете просто взять готовый файл и добавить его в lib\ext или в CLASSPATH. Единственная проблема, с которой я столкнулся - в версиях JDK начиная с 1.2 rc1 и по 1.3 beta, русские буквы не выводятся под Win9x при использовании стандартных шрифтов (Arial, Courier New, Times New Roman, etc.) из-за ошибки в Java2D. Ошибка весьма своеобразна - со стандартными шрифтами изображения букв отображаются не в соответствии с кодами Unicode, а по таблице Cp1251 (кодировка Ansi). Эта ошибка зарегистрирована в BugParade под номером . По умолчанию в Swing используются шрифты, задаваемые в файле font.properties.ru, так что достаточно заменить их другими - и русские буквы появляются. К сожалению, набор рабочих шрифтов небольшой - это шрифты Tahoma, Tahoma Bold и два набора шрифтов из дистрибутива JDK - Lucida Sans * и Lucida Typewriter * (пример файла font.properties.ru). Чем эти шрифты отличаются от стандартных - мне непонятно.

    Начиная с версии 1.3rc1 эта проблема уже исправлена, так что нужно просто обновить JDK. JDK 1.2 уже сильно устарел, так что я не рекомендую им пользоваться. Так же надо учесть, что с оригинальной версией Win95 поставляются шрифты, не поддерживающие Unicode - в этой ситуации можно просто скопировать шрифты из Win98 или WinNT.

    Типичные ошибки, или "куда делась буква Ш?"

    Буква Ш.

    Этот вопрос ("куда делась буква Ш?") довольно часто возникает у начинающих программистов на Java. Давайте разберёмся, куда же она действительно чаще всего девается. :-)

    Вот типичная программа а-ля HelloWorld:

    public class Test { public static void main(String args) { System.out.println("ЙЦУКЕНГШЩЗХЪ"); } }
    в Far-е сохраняем данный код в файл Test.java, компиляем...
    C:\>javac Test.java
    и запускаем...
    C:\>java Test ЙЦУКЕНГ?ЩЗХЪ

    Что же произошло? Куда делась буква Ш? Весь фокус здесь в том, что произошла взаимокомпенсация двух ошибок. Текстовый редактор в Far по умолчанию создаёт файл в DOS-кодировке (Cp866). Компилятор же javac для чтения исходника использует file.encoding (если не указано иное ключиком -encoding). А в среде Windows с русскими региональными настройками кодировкой по умолчанию является Cp1251. Это первая ошибка. В результате, в скомпилированном файле Test.class символы имеют неверные кода. Вторая ошибка состоит в том, что для вывода используется стандартный PrintStream, который тоже использует настройку из file.encoding, однако консольное окно в Windows отображает символы, используя кодировку DOS. Если бы кодировка Cp1251 была взаимоодназначной, то потери данных бы не было. Но символ Ш в Cp866 имеет код 152, который в Cp1251 не определён, и поэтому отображается на Unicode-символ 0xFFFD. Когда происходит обратное преобразование из char в byte, вместо него подставляется символ "?".

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

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

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

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

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

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

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

    Об утилите native2ascii

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

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

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

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

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

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

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

    Русские буквы и 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 существует две параллельных проблемы:

    1. Проблема вывода кириллицы в GUI-компонентах
    2. Проблема ввода кириллицы с клавиатуры (в X11)

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

    1. Установить в X11 нормальные шрифты ttf из Windows NT/200. Я бы рекомендовал Arial, Times New Roman, Courier New, Verdana и Tahoma - причем подключать их лучше не через сервер шрифтов, а как каталог с файлами.
    2. Добавить следующий файл 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 без локали НЕ РАБОТАЕТ))

    Процедура:

    1. выставляется локаль (где-нибудь типа в /etc/profile или в ~/.bash_profile)
      export LANG=ru_RU.KOI8-R export LC_ALL=ru_RU.KOI8-R
    2. правится (если это еще не сделано) /etc/X11/XF86Config. В секции Keyboard должно быть примерно следующее:
      XkbKeycodes "xfree86" XkbTypes "default" XkbCompat "default" XkbSymbols "ru" XkbGeometry "pc" XkbRules "xfree86" XkbModel "pc101" XkbLayout "ru" XkbOptions "grp:shift_toggle" # переключение 2-мя шифтами #XkbOptions "grp:caps_toggle" # переключение caps-lock"ом
      примечание: такая настройка xkb не совместима с xrus (и ему подобными типа kikbd) а посему с ними придется распрощаться.
    3. перезапускаются X-ы. Нужно проверить чтобы все работало (типа русские буковки в терминале и приложениях)
    4. font.properties.ru -> $JAVA_HOME/jre/lib
    5. fonts.dir -> $JAVA_HOME/jre/lib/fonts
    6. cd $JAVA_HOME/jre/lib/fonts; rm fonts.scale; ln -s fonts.dir fonts.scale

    Теперь русские буквы должны вводиться и выводиться в свинге без проблем.

Если Вы заметите неточность в описании или захотите дополнить, то напишите мне об этом, и Ваше имя так же появится в этом списке. :-)

Ваша проблема в том, что "консоль" Netbeans - и консоль ОС - это немного разные вещи. В частности, у них отличаются используемые кодировки. Оптимальным было бы получение текущей кодировки консоли через Console API - но Java такого не предоставляет. Поэтому надо получить информацию о консольной кодировке другим способом. К примеру, через свойство console.encoding .

Способ 1

Для начала, установка свойства console.encoding в предопределенное значение ничего не дает. Это свойство попросту никем не читается. Вместо того, чтобы ставить его в cp866 , следовало бы, напротив, прочитать из него значение.

String encoding = System.getProperty("console.encoding", "utf-8"); Scanner sc = new Scanner(System.in, encoding); PrintStream ps = new PrintStream(System.out, encoding);

Таким образом, вместо того, чтобы ожидать ввода в cp866 , программа позволяет запустившему ее указать любую кодировку (utf-8 - это кодировка по умолчанию. Замените ее на ту, которую использует консоль NetBeans). Запускать программу надо будет как-то так:

Java -Dconsole.encoding=cp866 ...

На первый взгляд, такой способ запуска кажется сложным. Но обычно для запуска "серьезных" программ на Java всегда используется некоторый пакетный файл. Что мешает дописать этот ключ в него?

И не забывайте, консоль в Windows может оказаться в любой кодировке! К примеру, некоторые программы, такие как reg.exe , умеют работать с консолью только в windows-1251 . Умение выводить в любой кодировке может пригодиться.

Chcp 1251 reg ... java -Dconsole.encoding=windows-1251 ...

Способ 2

Если уже заговорили про пакетные файлы, то есть более простой способ, хотя и не такой мощный. Можно просто сменить кодировку консоли на нужную перед запуском программы:

Chcp 1251 java ...

Вот номера кодовых страниц Windows, которые могут пригодиться:

  • 866 - cp866
  • 1251 - windows-1251
  • 65001 - кодировка utf-8
  • 1200 - двухбайтовая кодировка utf-16

PS

Помните, что System.in и System.out , как правило, всегда должны быть в одной и той же кодировке. У вас в исходной программе сканер читал из System.in в кодировке cp866 - а принтер выводил в System.out в кодировке по умолчанию. Такое несоответствие - тоже источник ошибок. Никогда так не делайте.



Рекомендуем почитать