Как веб-серверы знают, что кодировка используется в формах, размещенных на них?

Question

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

Я изучил запросы, отправленные двумя сообщениями. Один был сделан со страницы с использованием UTF-8, а другой со страницы с использованием Windows-1255. Один и тот же текст был закодирован по-разному. AFAIK, заголовок Content-type может содержать кодировку после application/x-www-form-urlencoded, но это не так (с помощью Firefox).

В сервлете, когда вы используете request.getParameter(), вы должны получить декодированное значение. Как контейнер сервлетов делает это? Всегда ли делается ставка на UTF-8, используется какая-то эвристика или есть какой-то детерминированный способ, которого мне не хватает?

Answer 1

Из спецификации Serlvet 3.0, раздел 3.10 Запрос кодирования данных (выделено мое)

В настоящее время многие браузеры не отправляют спецификатор кодировки символов с заголовком ContentType, оставляя открытым определение кодировки символов для чтения. HTTP-запросы. Кодировка по умолчанию для запроса, который контейнер использует для создания запрашивать считыватель и анализировать POST-данные должны быть «ISO-8859-1» , если ни один не был указан по запросу клиента. Однако для того, чтобы указать разработчику, в этом случае ошибка при отправке клиентом кодировки символов, контейнер возвращает ноль из метод getCharacterEncoding.

Если клиент не установил кодировку символов, а данные запроса кодируются отличная от кодировки по умолчанию, как описано выше, может произойти поломка. к исправить эту ситуацию, новый метод setCharacterEncoding (String enc) имеет добавлен в интерфейс ServletRequest. Разработчики могут переопределить кодировка символов, предоставляемая контейнером при вызове этого метода. Это должно быть вызывается перед анализом любых пост-данных или чтением любого ввода из запроса. призвание этот метод после прочтения данных не повлияет на кодировку.

На практике я обнаружил, что установка кодировки в ответе влияет на кодировку, используемую в последующем POST. Для большей уверенности вы можете написать фильтр сервлетов, который вызывает setCharacterEncoding для каждого объекта запроса перед его использованием.

Вы также можете найти этот поток полезным - Определение кодировки символов запроса HTTP POST

Answer 2

Подходящий заголовок для указания кодировок: Accept-Charset.

Последний Chrome для Linux, например, плюет: Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3

при каждом запросе.

Раздел 14.2из http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html состояния:

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

(...)

Если заголовок Accept-Charset отсутствует, по умолчанию принимается любой набор символов.Если присутствует заголовок Accept-Charset, и если сервер не может отправить ответ, который является приемлемым в соответствии с заголовком Accept-Charset, то сервер ДОЛЖЕН отправить ответ об ошибке с кодом состояния 406 (не приемлемо), хотя отправкатакже допускается неприемлемый ответ.

Так что, если вы получаете такой заголовок от клиента, значение с наибольшим q может быть кодировкой, которую вы получаете от него.