Windows-1252 символ 146 останавливает POST-данные, достигающие сервлета в Glassfish v2 - PullRequest
Новая
       21

Windows-1252 символ 146 останавливает POST-данные, достигающие сервлета в Glassfish v2

0 голосов
/ 22 сентября 2009

Для моего сервлета сделан запрос HTTP POST. В запросе http есть параметр опубликованной формы, который мой код в сервлете извлекает для дальнейшей обработки под названием «полезная нагрузка». Когда значение полезной нагрузки включает символ windows-1252 «’ »(ascii value 146), метод экземпляра HttpServletRequest getParameter (« payload ») возвращает ноль. В файле server.log нет ничего, связанного с проблемой. Мы думаем, что для создания этого символа используется кодировка символов windows-1252. По умолчанию для http-запросов символьная кодировка Glassfish по умолчанию соответствует ISO-8859-1. Значение Ascii 146 является контрольным символом в ISO-8859-1.

У кого-нибудь есть предложения, как мне решить эту проблему?

Заголовки HTTP-запроса в сообщении, в котором показана проблема: 

POST /dbxchange/TechAnywhere HTTP/1.1
CONTENT_LENGTH: 13117
Content-type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_16
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 13117

Ответы [ 3 ]

1 голос
/ 22 сентября 2009

Java не заботится о различиях между Cp1252 и Latin-1. Поскольку в обеих кодировках нет недопустимой последовательности байтов, вы не получите null ни с одной из них. Я думаю, что ваш сервер использует UTF-8, а браузер использует Cp1252 или Latin1.

Попробуйте поместить следующие атрибуты в форму, чтобы увидеть, помогает ли это, 

<form action="..." method="post" charset="UTF-8" accept-encoding="UTF-8"...>
0 голосов
/ 22 сентября 2009

Мы обнаружили, что проблема в коде JavaScript, который отправляет запрос на публикацию. Код javascript был URL-адресом, кодирующим значение полезной нагрузки перед отправкой запроса. Встроенная функция javascript escape () использовалась для кодирования URL. Это было кодирование символа в нестандартной реализации кодирования% u2019. Похоже, что Glassfish не поддерживает эту нестандартную форму кодирования.

См. http://en.wikipedia.org/wiki/Percent-encoding#Non-standard_implementations

Исправлено использование встроенной функции JavaScript encodeURI (), которая возвращает "% E2% 80% 99" для ’

0 голосов
/ 22 сентября 2009

Мы думаем, что кодировка символов, используемая для создания этого символа, - windows-1252.

Да, очень вероятно. Даже когда браузеры утверждают, что используют iso-8559-1, они обычно используют windows-1252.

По умолчанию для http-запросов символьная кодировка Glassfish по умолчанию соответствует ISO-8859-1

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

Для чтения тел запросов POST вы должны иметь возможность исправить кодировку, вызвав setCharacterEncoding для объекта запроса, если вы можете сделать это достаточно рано, чтобы никто не заставил его читать тело, вызывая такие методы, как getParameter. Попробуйте установить кодировку «Cp1252». Хотя на самом деле вы должны стремиться к UTF-8 для всего в долгосрочной перспективе.

К сожалению, не существует стандартного способа J2EE для указания того, какую кодировку ожидает ваше приложение для всех запросов (включая параметры строки запроса, на которые setCharacterEncoding не влияет). У каждого сервера свой путь, который создает раздражающие проблемы развертывания. Но для Glassfish, установите <parameter-encoding> в вашем sun-web.xml.

...