кодировка JSP UTF - PullRequest
Новая
       13

кодировка JSP UTF

8 голосов
/ 28 января 2009

Мне трудно понять, как решить эту проблему:

Я разрабатываю веб-инструмент для итальянского университета, и мне нужно отображать слова с ударением (например, è, ù, ...); иногда я получаю эти слова из таблицы PostgreSql (в кодировке UTF8), но в основном мне приходится читать длинные отрывки из файла. Эти файлы кодируются в формате utf-8 xml и прекрасно отображаются в Smultron или любом редакторе utf-8 (они были созданы при разборе старых файлов python с такими сущностями, как è вместо «è»).

Я написал класс Java, который извлекает соответствующие сегменты из файла XML, который работает следующим образом:

String s = parseText(filename, position)

если я запишу возвращенную строку в файл, все будет хорошо; проблема в том, что если я сделаю

out.write(s)

на странице jsp я получаю странные символы. Кстати, я использую

String s = getWordFromPostgresql(...)

out.write(s)

в том же JSP, и он показывает ОК.

Есть подсказка?

Спасибо Nicola

@ krosenvold

Спасибо за ваш ответ, однако эта директива уже есть на странице, но она не работает (на самом деле она "работает", но только для строк, которые я получаю из базы данных). Я думаю, что есть что-то о чтении из файлов, но я не могу понять ... они работают в "java", но не в "jsp" (не могу придумать лучшего объяснения ...)

вот базовый пример, извлеченный из фактического кода: метод для чтения из файлов возвращает Map, от Mark (объекта, представляющего позицию в тексте) до String (содержащего текст):

это на странице .jsp (с указанием utf-директивы в постах выше) 

    // ...
    Map<Mark, String> map = TestoMarkParser.parseMarks(...);
    out.write(map.get(m));

и вот результат:

"Fu però così in uso il Genere Enharmonico, che quelli quali vi si esercitavano",

если я помещу тот же код в java-класс и заменю out.write на System.out.println, результат будет следующим:

"Fu però così in uso il Genere Enharmonico, che quelli quali vi si esercitavano",

Я провел некоторый анализ с помощью шестнадцатеричного редактора, вот он:

оригинальная строка: "fu però così"

в файле xml: C3 B2

как показано в out.write () в файле jsp: E2 88 9A E2 89 A4

ò как записано в файл через: 

FileWriter w = new FileWriter(new File("out.txt"));
w.write(s);     // s is the parsed string
w.close();

C3 B2

печать значений каждого символа в формате int 

0: 70 = F
1: 117 = u
2: 32 =  
3: 112 = p
4: 101 = e
5: 114 = r
6: 8730 = � 
7: 8804 = � 
8: 32 =  
9: 99 = c
10: 111 = o
11: 115 = s
12: 8730 = �
13: 168 = �
14: 10 = `

Ответы [ 4 ]

15 голосов
/ 28 января 2009

В директиве jsp page вы должны попробовать установить тип контента в utf-8, что также установит pageEncoding в utf-8. 

<%@page contentType="text/html;charset=UTF-8"%>

UTF-8 - это , а не тип содержимого по умолчанию в jsp, и из этого возникают всевозможные интересные проблемы. Проблема заключается в том, что основной поток по умолчанию интерпретируется как поток ISO-8859-1. Если вы запишите в этот поток несколько байтов Юникода, они будут интерпретированы как ISO-8859-1. Я считаю, что установка кодировки в utf-8 является лучшим решением.

Редактировать : Кроме того, переменная string в Java должна всегда быть юникодом. Таким образом, вы всегда должны быть в состоянии сказать 

System.out.println(myString)

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

3 голосов
/ 20 марта 2013

У меня есть несколько международных jsp [с «специальными» международными (по отношению к английскому) символами].

Вставка этого [и только этого, т. Е. директивы contentType также нет (из-за которой произошла дублирующаяся ошибка contentType )], в верхней части их можно было сохранить и правильно отобразить: 

<%@page pageEncoding="UTF-8"%>

Эта ссылка [http://www.inter -locale.com / codeset1.jsp] помогла мне обнаружить это.

0 голосов
/ 26 мая 2013

У меня тоже была такая же проблема, все "utf-8" и почему я вижу
бессмысленные персонажи и проблема была в jsp и оно должно быть в начале страницы. 

 <%request.setCharacterEncoding("utf-8");%>

и все будет хорошо.

0 голосов
/ 28 января 2009 
String s = parseText(filename, position)

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

Если кодировка по умолчанию вашей работающей JVM не соответствует фактической кодировке в файле, вы получите неправильные символы в вашей строке. Кроме того, если вы читаете контент, закодированный в многобайтовой форме (например, UTF-8), ваша «позиция» может указывать на середину многобайтовой кодировки.

Если исходные файлы находятся в правильно сформированном XML, вам будет гораздо лучше использовать реальный синтаксический анализатор (например, встроенный в JDK) для их синтаксического анализа, поскольку синтаксический анализатор обеспечит правильный перевод байтов в персонажи. Затем используйте выражение XPath для получения значений.

Если вы ранее не использовали анализатор XML, вот два документа, которые я написал для парсинга и XPath .

Редактировать: одна вещь, которая вам может пригодиться, это распечатать действительные значения символов в строке, используя что-то вроде следующего: 

public static void main(String[] argv) throws Exception
{
    String s = "testing\u20ac";
    for (int ii = 0 ; ii < s.length() ; ii++)
    {
        System.out.println(ii + ": " + (int)s.charAt(ii) + " = " + s.charAt(ii));
    }
}

Вы, вероятно, также должны распечатать свой набор символов по умолчанию, чтобы знать, как любая конкретная последовательность байтов переводится в символы: 

public static void main(String[] argv) throws Exception
{
    System.out.println(Charset.defaultCharset());
}

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

Редактировать # 2: символ œ это значение Unicode 00F2, которое будет кодироваться в кодировке UTF-8 как C3 B2. Эти два кода не соответствуют символам, которые вы указали в предыдущем ответе.

Подробнее о символах Unicode см. В кодовых таблицах на Unicode.org.

...