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

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

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

]}

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

Например, форма с текстовым полем, в котором пользователь набрал ' Joe Debt 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 8
http multipartform-data standards-compliance

3 ответа:

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

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

-- СНиП--

Параметр "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, соответствующие нефайловым полям, не должны иметь указанного заголовка типа содержимого.

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

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

Я столкнулся с этой проблемой при написании расширения Chrome, которое использует XMLHttpRequest.отправка объектаFormData , которыйвсегда кодируется в UTF-8 независимо от того, какая кодировка исходного документа .

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

Пусть MIME-тип является конкатенацией "multipart / form-data;", символ пробела U+0020, " boundary="и строка границы multipart / form-data, генерируемая алгоритмом кодирования multipart/form-data.

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

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

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

Просто немного больше информации здесь:

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

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

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

Я думаю, что причина поведения Resin заключается в том, что тип содержимого не указывает кодировку, поэтому Resin декодирует имя файла с помощью "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