multipart/form-data, что такое кодировка по умолчанию для полей?

Question

Что такое кодировка по умолчанию, которую нужно использовать для декодирования multipart/form-data, если не указан charset? RFC2388 гласит:

4,5 Charset текста в виде данных

Каждая часть составного/форма-данные должны иметь контент- типа. В случае, когда элемент поля является текстом, параметр charset для текста указывает используемую кодировку символов.

Например, форма с текстовым полем, в котором пользователь вводит «Джо должен < ес > 100», где < ес > является символом Евро может иметь данные формы возвращаются как:

--AaB03x 
content-disposition: form-data; name="field1" 
content-type: text/plain;charset=windows-1250 
content-transfer-encoding: quoted-printable>> 

Joe owes =80100. 
--AaB03x 

В моем случае кодировка не установлена, и я не знаю, как декодировать данные в этом текстовом/обычном разделе. Поскольку я не хочу применять что-то, что не является стандартным поведением, я спрашиваю, каково ожидаемое поведение в этом случае. RFC, похоже, не объясняет это, поэтому я потерян.

Спасибо!

Answer 1

Шрифт по умолчанию для HTTP 1.1 - ISO-8859-1 (Latin1), я бы предположил, что это также применимо и здесь.

3.7.1 канонизации и текстовые значения по умолчанию

--snip--

Параметр "кодировка" используется с некоторыми типами средств массовой информации, чтобы определить набор символов (раздел 3.4) данных. Если для отправителя не указывается явный параметр charset, подтипы мультимедиа типа «text» определены как значение по умолчанию для кодировки «ISO-8859-1» при получении через HTTP. Данные в наборах символов, отличных от «ISO-8859-1» или его подмножеств, ДОЛЖНЫ быть помечены соответствующим значением кодировки. См. Раздел 3.4.1 о проблемах совместимости.

Answer 2

Это, по-видимому, изменилось в HTML5 (см. http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data).

Части генерируемого ресурса multipart/form-data, которые соответствуют нефайловым полям, не должны содержать заголовок Content-Type.

Итак, где указан набор символов? Насколько я могу судить по алгоритму кодирования, единственное место находится в записи набора данных формы с именем _charset_.

Если у вашей формы нет скрытого ввода с именем _charset_, что происходит? Я протестировал это в Chrome 28, отправив форму, закодированную в UTF-8, и одну в ISO-8859-1, и проверил отправленные заголовки и полезную нагрузку, и я не вижу кодировку, предоставляемую в любом месте (даже если текстовая кодировка определенно изменяется). Если я включу пустое поле _charset_ в форму, Chrome заполняет это с правильным типом кодировки. Я предполагаю, что любой серверный код должен искать это поле _charset_, чтобы понять это?

Я столкнулся с этой проблемой при написании расширения Chrome, которое использует XMLHttpRequest.send объекта FormData, который always gets encoded in UTF-8 no matter what the source document encoding is.

Пусть тело объекта запроса является результатом запуска алгоритма кодирования multipart/form-data с данными в виде набора данных формы и с utf-8 в качестве явного кодирования символов.

Пусть тип mime является конкатенацией «multipart/form-data;», символом SPACE «U + 0020», «border =» и граничной строкой multipart/form-data, генерируемой кодировкой multipart/form-data алгоритм.

Как я нашел ранее, кодировка = UTF-8 нигде не указана в запросе POST, если не включать пустое _charset_ поля в форме, которая в этом случае будет автоматически заполняется «UTF- 8" .

Это мое понимание состояния вещей. Я приветствую любые поправки к моим предположениям!

Answer 3

Спасибо за подробное объяснение от @owlman.

Просто некоторые подробнее здесь:

Загрузить фрагмент запроса полезной нагрузки:

------WebKitFormBoundarydZAwJIasnBbGaUqM 
Content-Disposition: form-data; name="file"; filename="xxx.txt" 
Content-Type: text/plain 

Если "xxx.txt" имеет некоторые UNICODE символ в нем с помощью UTF-8 кодировке, Resin (как 4.0. 40) не может его правильно декодировать, но Jetty (9.x) может.

Я думаю, что причиной поведения Resin является то, что Content-type не указывает какую-либо кодировку, поэтому Resin декодирует имя файла, используя «ISO8859-1», что может привести к искаженным символам.

Я сделал некоторые погуглите:

https://mail-archives.apache.org/mod_mbox/struts-user/200310.mbox/%3C3FA0395B.1080209@kumachan.net.nz%3E

Это кажется, что поведение Ресина является согласно Servlet Spec 2.3

И я не могу найти какие-либо настройки из http://www.caucho.com/resin-4.0/reference.xtp , которые могут изменить это поведение для Смола.