2010-10-29 7 views
7

Я пытаюсь преобразовать строку UTF8 в строку Java Unicode.Как конвертировать UTF8 в Unicode

String question = request.getParameter("searchWord"); 
byte[] bytes = question.getBytes(); 
question = new String(bytes, "UTF-8"); 

Входные китайские символы и когда я сравниваю шестнадцатеричный код каждого carácter это тот же самый Chinses характер. Поэтому я уверен, что кодировка UTF8.

Где я могу пойти не так?

ответ

11

В Java нет такой вещи, как «строка UTF-8». Все в Юникоде.

Когда вы вызываете String.getBytes() без указания кодировки, которая использует кодировку по умолчанию для платформы - это почти всегда плохая идея.

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

Не могли бы вы привести пример того, что на самом деле происходит не так? Укажите значения Unicode символов в строке, которую вы получаете (например, с помощью toCharArray(), а затем конвертируете каждый char в int) и то, что вы ожидали получить.

EDIT: Для того, чтобы диагностировать это, использовать что-то вроде этого:

public static void dumpString(String text) { 
    for (int i = 0; i < text.length(); i++) { 
     System.out.println(i + ": " + (int) text.charAt(i)); 
    } 
} 

Обратите внимание, что это даст десятичного значения каждого символа Unicode. Если у вас есть удобный метод шестнадцатеричной библиотеки, вы можете использовать его, чтобы дать вам шестнадцатеричное значение. Главное, что он сбрасывает символы Unicode в строке.

+0

告 Этот символ, например, должен быть преобразован я получаю 229 145 138 это десятичное представление whichis исправить согласно http://www.ansell-uebersetzungen.com/gbuni.html потому что это шестнадцатеричное представление: E5 91 8A Так что теперь мне нужно его преобразовать в unicode. I –

+0

Итак, на мой взгляд, запрос отправляет правильные символы, но я не могу их прочитать в java, его нужно преобразовать в unicode –

+0

@Rob: Нет, это должно появиться в строке как U + 544A. Представленное шестнадцатеричное представление - это представление UTF-8, которое никогда не будет состоять в том, что находится в самой строке. Вы говорите, что «получите» 229 145 138 - когда вы что-то делаете? Я отредактирую свой ответ с помощью диагностического кода. –

2

Сначала убедитесь, что данные фактически закодированы как UTF-8.

Существует некоторая несогласованность между браузерами относительно кодировки, используемой при отправке данных формы HTML. Самый безопасный способ отправки кодированных данных UTF-8 из веб-формы - это разместить эту форму на странице, которая подается с заголовком Content-Type: text/html; charset=utf-8 или содержит метатег <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />.


Теперь, чтобы правильно декодировать вызов request.setCharacterEncoding("UTF-8") данных в сервлет перед первым вызовом request.getParameter().

Контейнер сервлетов заботится о кодировке для вас. Если вы правильно используете setCharacterEncoding(), вы можете ожидать getParameter(), чтобы вернуть нормальные строки Java.

+0

Кодировка прямо в html. –

+0

Теперь, когда я конвертирую, я получаю представление юникода 63 для каждого символа. Поэтому я предполагаю, что мое преобразование все еще не так –

+0

@Rob Вам не нужно делать никаких ручных преобразований. Вы должны вызвать 'setCharacterEncoding (« UTF-8 »)' и использовать 'request.getParameter()' для получения нормальной строки Java Unicode. Я полагаю, что ваш код работает и с обычными символами ascii? –

0

Также вам может потребоваться специальный фильтр, который позаботится о кодировании ваших запросов. Например такой фильтр существует в весеннем рамках org.springframework.web.filter.CharacterEncodingFilter

0
String question = request.getParameter("searchWord"); 

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

Смежные вопросы