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

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

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

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

например, форма с текстовым полем, в котором пользователь набрал " Джо должен 100', где является символом евро, могут быть возвращены данные формы as:

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

Joe owes =80100.
--AaB03x

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

спасибо!

8
http multipartform-data rfc standards-compliance

3 ответов

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

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

-- snip--

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

5

Это, по-видимому, изменилось в 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.отправить виде FormData

6

благодаря подробному объяснению @owlman.

просто еще немного информации здесь:

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

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

Если "xxx.txt" имеет некоторый символ UNICODE в нем, используя кодировку UTF-8, смола(по состоянию на 4.0.40) не может его правильно декодировать, но Jetty(9.х) может.

Я думаю, что причина поведения смолы заключается в том, что тип содержимого не указывает кодировку, поэтому смола декодирует имя файла с помощью "ISO8859-1", что может привести к искажению письмена.

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

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

похоже, что поведение смолы соответствует спецификации сервлета 2.3

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

2