Кодирование преобразования в java

Question

Есть ли бесплатная java-библиотека, которую я могу использовать для преобразования строки в одну кодировку в другую кодировку, что-то вроде iconv в php? Я использую java версию 1.3.

Answer 1

Вам не нужна библиотека за стандартной - просто использовать Charset. (Вы можете просто использовать конструкторы String и методы getBytes, но лично мне не нравится просто работать с именами кодировок символов. Слишком много места для опечаток.) ​​

EDIT: Как указано в комментариях, вы все равно можете используйте экземпляры Charset, но имеют простоту использования методов String: new String(bytes, charset) и String.getBytes(charset).

Answer 2

CharsetDecoder должно быть тем, что вы ищете, нет?

Многие сетевые протоколы и файлы хранят свои символы с байт-ориентированным набором символов, например ISO-8859-1 (ISO-Latin-1).
Однако родная кодировка символов Java - это Unicode UTF16BE (шестнадцатибитный формат преобразования UCS, порядок байтов байтов).

См. Charset. Это вовсе не означает, что UTF16 является кодировкой по умолчанию (то есть: «отображение между последовательностями шестнадцать-битном Unicode code units и последовательностью байт» по умолчанию):

Каждого экземпляр виртуальной машины Java имеет кодировку по умолчанию , который может быть или не быть одним из стандартных кодировок.
[US-ASCII, ISO-8859-1 а.к.а. ISO-LATIN-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16]
По умолчанию используется кодировка определяется во время запуска виртуальной машины и, как правило, зависит от локализации и набора символов, используемых базовой операционной системы.

Этот пример показывает, как преобразовать ISO-8859-1 закодированных байтов в ByteBuffer в строку в CharBuffer и наоборот.

// Create the encoder and decoder for ISO-8859-1 
Charset charset = Charset.forName("ISO-8859-1"); 
CharsetDecoder decoder = charset.newDecoder(); 
CharsetEncoder encoder = charset.newEncoder(); 

try { 
    // Convert a string to ISO-LATIN-1 bytes in a ByteBuffer 
    // The new ByteBuffer is ready to be read. 
    ByteBuffer bbuf = encoder.encode(CharBuffer.wrap("a string")); 

    // Convert ISO-LATIN-1 bytes in a ByteBuffer to a character ByteBuffer and then to a string. 
    // The new ByteBuffer is ready to be read. 
    CharBuffer cbuf = decoder.decode(bbuf); 
    String s = cbuf.toString(); 
} catch (CharacterCodingException e) { 
} 

Answer 3

Это намного проще, если вы думаете о юникоде как наборе символов (который на самом деле есть - это в основном пронумерованный набор всех известных символов). Вы можете кодировать его как UTF-8 (1-3 байта на каждый символ) или, может быть, UTF-16 (2 байта на символ или 4 байта, используя суррогатные пары).

Назад в туман времени Java, используемый для использования UCS-2 для кодирования набора символов Юникода. Это может обрабатывать только 2 байта на символ и теперь устарело. Это был довольно очевидный взлом, чтобы добавить суррогатные пары и перейти на UTF-16.

Многие люди думают, что они должны были использовать UTF-8 в первую очередь. Когда Java была первоначально написана, юникод имел в любом случае более 65535 символов ...

Answer 4

UTF-8 и UCS-2/UTF-16 можно легко распознать с помощью знака порядка байтов в начале файла. Если это существует, то довольно неплохо, что файл находится в этой кодировке, но это не мертвая уверенность. Вы также можете обнаружить, что файл находится в одном из этих кодировок, но не имеет знака порядка байтов.

Я мало знаю об ISO-8859-2, но я не удивлюсь, если почти каждый файл является допустимым текстовым файлом в этой кодировке. Лучшее, что вы сможете сделать, это проверить его эвристически. Действительно, страница Wikipedia, говорящая об этом, предполагает, что только байт 0x7f недействителен.

Нет идеи читать файл «как есть», но при этом получать текст - файл представляет собой последовательность байтов, поэтому вам необходимо применить кодировку символов, чтобы декодировать эти байты в символы.

Источника на StackOverflow

Answer 5

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

Ответ на другой вопрос дает объяснение, почему преобразование не всегда дает правильные результаты https://stackoverflow.com/a/2623793/4702806