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

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

11 голосов
/ 03 ноября 2010

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

4.5 Кодировка текста в данных формы

Каждая часть составных данных / данных формы должна иметь тип содержимого.В случае, когда элементом поля является текст, параметр 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, похоже, не объясняет этого, поэтому я немного растерялся.

Спасибо!

Ответы [ 3 ]

9 голосов
/ 23 июля 2013

Это, очевидно, изменилось в 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 , который всегда кодируется в UTF-8, независимо от того, какая кодировка исходного документа .

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

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

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

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

6 голосов
/ 03 ноября 2010

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

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

- чик -

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

2 голосов
/ 25 июля 2016

Благодаря подробному объяснению @ 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) может.

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

Я немного погуглил:

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

Кажется, что поведение Ресина соответствует спецификациям Servlet 2.3

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

...