Какой способ кодирования данных формы enctype нужно использовать если в форме отправляется файл
HTML-формы предназначены для пересылки данных от удаленного пользователя к Web-серверу. С их помощью можно организовать простейший диалог между пользователем и сервером, например, регистрацию пользователя на сервере или выбор нужного документа из представленного списка. Формы поддерживаются всеми популярными браузерами.
Синтаксис формы
В HTML-документе для задания формы используются тэги
, Документ может содержать несколько форм, но они не могут быть вложены одна в другую.Тэг имеет параметры action , method и enctype . Отдельные браузеры ( Netscape , Internet Explorer) поддерживают дополнительные параметры, например, class , name , style и др.
В общем виде форма задается следующим образом:
Параметр action является единственным обязательным. Его значением является URL-адрес CGI -программы, которая будет обрабатывать информацию, извлеченную из данной формы.
Взаимодействие между браузером и web-сервером
MIME-типы
Значением параметра enctype является медиа -тип, определяющий формат кодирования данных при передаче их от браузера к серверу. Браузер кодирует данные, чтобы исключить их искажение в процессе передачи. Возможны два значения этого параметра: application/x-www-form-urlencoded (по умолчанию) и multipart/form-data .
Второй метод нужен только в том случае, если к содержимому формы присоединяется локальный файл, выбранный при помощи элемента формы . В остальных случаях следует использовать метод кодирования по умолчанию.
URL-кодирование
Схема кодирования application/x-www-form-urlencoded одинакова для обоих методов пересылки ( GET и POST ) и заключается в следующем. Для каждого элемента формы, имеющего имя, заданное параметром name , формируется пара "name=value" , где value — значение элемента, введенное пользователем или назначенное по умолчанию. Если значение отсутствует, соответствующая пара имеет вид "name texample">value не определено, по умолчанию используется значение "on" .
Все пары объединяются в строку, в качестве разделителя служит символ "&" . Так как имена и значения представляют собой обычный текст, то они могут содержать символы, недопустимые в составе URL (метод GET пересылает данные как часть URL). Такие символы заменяются последовательностью, состоящей из символа % и их шестнадцатеричного ASCII- кода. Символ пробела может заменяться не только кодом %20 , но и знаком + (плюс). Признак конца строки, встречающийся в поле textarea , заменяется кодом %0D%0A . Такое кодирование называется URL-кодированием .
Методы передачи данных
Закодированная информация пересылается серверу одним из методов GET или POST . Основное отличие заключается в том, как метод передает информацию CGI -программе.
При использовании метода GET данные формы пересылаются в составе URL-запроса, к которому присоединяются после символа "?" в виде совокупности пар
разделенных символом "&" . В этом случае первая строка запроса может иметь следующий вид:
Часть URL после символа "?" называется строкой запроса . Web-сервер, получив запрос, присвоит переменной среды QUERY_STRING значение строки запроса и вызовет CGI -программу, обозначенную в первой части URL до символа "?" .
При использовании метода POST данные формы пересылаются серверу в теле запроса, после чего передаются сервером в CGI -программу через стандартный ввод .
Методы GET и POST имеют свои достоинства и недостатки. Метод GET обеспечивает лучшую производительность при пересылке форм, состоящих из небольшого набора коротких полей. При пересылке большого объема данных следует использовать метод POST , так как браузер или сервер могут накладывать ограничения на размер данных, передаваемых в составе URL, и отбрасывать часть данных, выходящую за границу. Метод POST , к тому же, является более надежным при пересылке конфиденциальной информации .
Поля ввода формы
Форма отображается в окне браузера в виде набора стандартных элементов управления, используемых для заполнения полей формы значениями, которые затем передаются Web-серверу. Значение вводится в поле ввода пользователем или назначается по умолчанию. Для создания полей средствами языка HTML существуют специальные тэги: , , textarea > , которые употребляются только внутри тэга .
Это наиболее употребительный тэг, с помощью которого можно генерировать внутри формы поля для ввода строки текста, пароля, имени файла, различные кнопки. Он имеет два обязательных параметра: type и name . Параметр type определяет тип поля: селекторная кнопка, кнопка передачи и др. Параметр name определяет имя, присваиваемое полю. Оно не отображается браузером, а используется в качестве идентификатора значения, передаваемого Web-серверу. Остальные параметры меняются в зависимости от типа поля. Ниже приведено описание типов полей, создаваемых при помощи тэга , и порождаемых ими элементов ввода.
type="text"
Создает элемент для ввода строки текста.
- maxlength="n" - задает максимальное количество символов, разрешенных в текстовом поле. По умолчанию — не ограничено.
- size="n" - максимальное количество отображаемых символов.
- value = "начальное_значение" . Первоначальное значение текстового поля.
type="password"
Создает элемент ввода строки текста, отличающийся от предыдущего только тем, что все вводимые символы представляются в виде символа * . Поле password не обеспечивает безопасности введенного текста, так как на сервер он передается в незашифрованном виде.
type="files"
Создает поле для ввода имени локального файла, сопровождаемое кнопкой Browse . Выбранный файл присоединяется к содержимому формы при пересылке на сервер. Имя файла можно ввести непосредственно или выбрать его из диалогового окна. Для корректной передачи присоединенного файла следует установить значения параметров формы равными enctype="multipart/form-data" и method="post" . В противном случае будет передана введенная строка, то есть маршрутное имя файла, а не его содержимое. Дополнительные параметры maxlength и size имеют тот же смысл, что и для элементов типа text и password .
type="checkbox"
Создает поле для установки флажка. Элементы checkbox можно объединить в группу, установив одинаковое значение параметра name .
- value="строка" . Значение, которое будет передано серверу, если данная кнопка выбрана. Если кнопка не выбрана, значение не передается. Обязательный параметр. Если флажки образуют группу, то передаваемым значением является строка разделенных запятыми значений параметра value всех установленных флажков.
- checked . Если указан параметр checked , элемент является выбранным по умолчанию.
type="radio"
Создает элемент-переключатель, существующий только в составе группы подобных элементов, из которых может быть выбран только один. Все элементы группы должны иметь одинаковое значение параметра name .
Отображается в виде круглой кнопки. Дополнительные параметры:
- value="строка" . Обязательный параметр, значение которого передается серверу при выборе данной кнопки. Должен иметь уникальное значение для каждого члена группы .
- checked . Устанавливает элемент выбранным по умолчанию. Один и только один элемент в группе должен иметь этот параметр.
type="submit"
Создает кнопку передачи, нажатие которой вызывает пересылку на сервер всего содержимого формы. По умолчанию отображается в виде прямоугольной кнопки с надписью Submit .
Дополнительный параметр позволяет изменить надпись на кнопке. Параметр name для данного элемента может быть опущен. В этом случае значение кнопки не включается в список параметров формы и не передается на сервер.
Если параметры name и value присутствуют, например,
то в список параметров формы, передаваемых на сервер, включается параметр submit_button="ok" . Внутри формы могут существовать несколько кнопок передачи.
type="reset"
Создает кнопку сброса, нажатие которой отменяет все сделанные изменения, восстанавливая значения полей формы на тот момент, когда она была загружена. По умолчанию отображается в виде прямоугольной кнопки с надписью Reset . Надпись можно изменить при помощи дополнительного параметра
Значение кнопки Reset никогда не пересылается на сервер, поэтому у нее отсутствует параметр name .
type="image"
Создает элемент в виде графического изображения, действующий аналогично кнопке Submit . Дополнительные параметры:
- src="https://intuit.ru/studies/professional_skill_improvements/1450/courses/239/lecture/url_%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F" . Задает URL-адрес файла с графическим изображением элемента.
- align="тип_выравнивания" . Задает тип выравнивания изображения относительно текущей строки текста.
Если на изображении элемента щелкнуть мышью, то координаты указателя мыши в виде name.x=n&name.y=m включаются браузером в список параметров формы, посылаемых на сервер.
type="hidden"
Создает скрытый элемент, не отображаемый пользователю. Информация, хранящаяся в скрытом поле , всегда пересылается на сервер и не может быть изменена ни пользователем, ни браузером. Скрытое поле можно использовать, например, в следующем случае. Пользователь заполняет форму и отправляет ее серверу. Сервер посылает пользователю для заполнения вторую форму, которая частично использует информацию, содержащуюся в первой форме. Сервер не хранит историю диалога с пользователем, он обрабатывает каждый запрос независимо и при получении второй формы не будет знать, как она связана с первой. Чтобы повторно не вводить уже введенную информацию, можно заставить CGI -программу, обрабатывающую первую форму, переносить необходимые данные в скрытые поля второй формы. Они не будут видимы пользователем и, в то же время, доступны серверу. Значение скрытого поля определяется параметром value .
Тэг предназначен для того, чтобы организовать внутри формы выбор из нескольких вариантов без применения элементов типа checkbox и radio . С помощью тэга варианты выбора более компактно представляются в окне браузера в виде элементов ниспадающего меню или списка прокрутки. Пример:
Тэг имеет следующие параметры:
name="имя_поля" . Обязательный параметр. При выборе одного или нескольких элементов формируется список выбранных значений, который передается на сервер под именем name .
size="n" . Устанавливает число одновременно видимых элементов выбора. Если n="1" , то отображается ниспадающее меню, если n>1 , то — список прокрутки с n одновременно видимыми элементами.
Элементы меню задаются внутри тэга при помощи тэга :
Параметр value содержит значение, которое пересылается серверу, если данный элемент выбран из меню или списка. Если значение этого параметра не задано, то по умолчанию оно устанавливается равным содержимому тэга .
Тэг textarea > создает внутри формы поле для ввода многострочного текста, отображаемое в окне браузера в виде прямоугольной области с горизонтальной и вертикальной полосами прокрутки. Для пересылки на сервер каждая введенная строка дополняется символами %0D%0A (ASCII-символы " Возврат каретки " и " Перевод строки " с предшествующим символом %), полученные строки объединяются в одну строку, которая и отправляется на сервер под именем, задаваемым параметром name .
- name . Необходимый параметр, используемый для идентификации данных при пересылке на сервер.
- cols="n" . Задает число столбцов видимого текста.
- rows="m" . Задает число строк видимого текста.
Между тэгами textarea > и textarea > можно поместить текст, который будет отображаться по умолчанию.
HTML5
Блочные элементы
Строчные элементы
Универсальные элементы
Нестандартные теги
Осуждаемые теги
Видео
Документ
Звук
Изображения
Объекты
Скрипты
Списки
Ссылки
Таблицы
Текст
Форматирование
Формы
Фреймы
Internet Explorer | Chrome | Opera | Safari | Firefox | Android | iOS |
3.0+ | 1.0+ | 4.0+ | 1.0+ | 1.0+ | 1.0+ | 1.0+ |
Кодировка urlencoded
Основной способ кодировки запросов – это urlencoded, то есть – стандартное кодирование URL.
Здесь есть два поля: name=Ivan и surname=Ivanov .
Браузер перечисляет такие пары «имя=значение» через символ амперсанда & и, так как метод GET, итоговый запрос выглядит как /submit?name=Ivan&surname=Ivanov .
Все символы, кроме английских букв, цифр и - _ . ! ~ * ' ( ) заменяются на их цифровой код в UTF-8 со знаком %.
Например, пробел заменяется на %20 , символ / на %2F , русские буквы кодируются двумя байтами в UTF-8, поэтому, к примеру, Ц заменится на %D0%A6 .
Будет отправлена так: /submit?name=%D0%92%D0%B8%D0%BA%D1%82%D0%BE%D1%80&surname=%D0%A6%D0%BE%D0%B9 .
в JavaScript есть функция encodeURIComponent для получения такой кодировки «вручную»:
Эта кодировка используется в основном для метода GET, то есть для передачи параметра в строке запроса. По стандарту строка запроса не может содержать произвольные Unicode-символы, поэтому они кодируются как показано выше.
FormData
Современные браузеры, исключая IE9- (впрочем, есть полифил), поддерживают встроенный объект FormData, который кодирует формы для отправки на сервер.
Это очень удобно. Например:
Этот код отправит на сервер форму с полями name , surname и patronym .
- Конструктор new FormData([form]) вызывается либо без аргументов, либо с DOM-элементом формы.
- Метод formData.append(name, value) добавляет данные к форме.
Описание
Тег устанавливает форму на веб-странице. Форма предназначена для обмена данными между пользователем и сервером. Область применения форм не ограничена отправкой данных на сервер, с помощью клиентских скриптов можно получить доступ к любому элементу формы, изменять его и применять по своему усмотрению.
Документ может содержать любое количество форм, но одновременно на сервер может быть отправлена только одна форма. По этой причине данные форм должны быть независимы друг от друга.
Для отправки формы на сервер используется кнопка Submit, того же можно добиться, если нажать клавишу Enter в пределах формы. Если кнопка Submit отсутствует в форме, клавиша Enter имитирует ее использование.
Когда форма отправляется на сервер, управление данными передается программе, заданной атрибутом action тега . Предварительно браузер подготавливает информацию в виде пары «имя=значение», где имя определяется атрибутом name тега , а значение введено пользователем или установлено в поле формы по умолчанию. Если для отправки данных используется метод GET , то адресная строка может принимать следующий вид.
Параметры перечисляются после вопросительного знака, указанного после адреса CGI-программы и разделяются между собой символом амперсанда (&). Нелатинские символы преобразуются в шестнадцатеричное представление (в форме %HH, где HH — шестнадцатеричный код для значения ASCII-символа), пробел заменяется на плюс (+).
Допускается внутрь контейнера помещать другие теги, при этом сама форма никак не отображается на веб-странице, видны только ее элементы и результаты вложенных тегов.
GET-запрос
Например, для посылки GET-запроса с параметрами name и surname , аналогично форме выше, их необходимо закодировать так:
Поэтому в некоторых фреймворках, чтобы сказать серверу, что это AJAX, добавляют специальный заголовок, например такой:
Security
When submitting forms, some security concerns can arise as stated in RFC 7578 Section 7: Multipart form data - Security considerations:
All form-processing software should treat user supplied form-data
with sensitivity, as it often contains confidential or personally
identifying information. There is widespread use of form "auto-fill" features in web browsers; these might be used to trick users to
unknowingly send confidential information when completing otherwise
innocuous tasks. multipart/form-data does not supply any features
for checking integrity, ensuring confidentiality, avoiding user
confusion, or other security features; those concerns must be
addressed by the form-filling and form-data-interpreting applications.Applications that receive forms and process them must be careful not to supply data back to the requesting form-processing site that was not intended to be sent.
It is important when interpreting the filename of the Content-
Disposition header field to not inadvertently overwrite files in the
recipient's file space.
This concerns you if you are a developer and your server will process forms submitted by users which might end up containing sensitive information.
I know that in the past you needed to set enctype="multipart/form-data" in the tag, if you wanted to upload files.
I would like to avoid this condition in my generic template.
What should I do? I see these solutions:
- use enctype="multipart/form-data" always.
- use enctype="multipart/form-data" never.
Background: I am lucky, I don't need to support old browsers. I don't need to support IE9 or older versions.
It's working
We are using enctype="multipart/form-data" since several month in all forms (even if there are no files to upload).
It works. This makes our templates simpler. For me it is one simple step to the big goal "conditionlesscode".
I assume yes.. haven't worked with form uploads since a long time but mentioning multipart/form-data explicitly states that you are having a file upload field. Think of it like websites having form uploads as optional but even if the file is not provided.. attribute stays there as is. So no harm in defining it on all the forms.
Итого
- У форм есть две основные кодировки: application/x-www-form-urlencoded – по умолчанию и multipart/form-data – для POST запросов, если явно указана в enctype . Вторая кодировка обычно используется для больших данных и только для тела запроса.
- Для составления запроса в application/x-www-form-urlencoded используется функция encodeURIComponent .
- Для отправки запроса в multipart/form-data – объект FormData .
- Для обмена данными JS ↔ сервер можно использовать и просто JSON, желательно с указанием кодировки в заголовке Content-Type .
Спецификация
Кодировка multipart/form-data
Кодировка urlencoded за счёт замены символов на %код может сильно «раздуть» общий объём пересылаемых данных. Поэтому для пересылки файлов используется другая кодировка: multipart/form-data.
В этой кодировке поля пересылаются одно за другим, через строку-разделитель.
Чтобы использовать этот способ, нужно указать его в атрибуте enctype и метод должен быть POST:
Форма при такой кодировке будет выглядеть примерно так:
…То есть, поля передаются одно за другим, значения не кодируются, а чтобы было чётко понятно, какое значение где – поля разделены случайно сгенерированной строкой, которую называют «boundary» (англ. граница), в примере выше это RaNdOmDeLiMiTeR :
Сервер видит заголовок Content-Type: multipart/form-data , читает из него границу и раскодирует поля формы.
Такой способ используется в первую очередь при пересылке файлов, так перекодировка мегабайтов через urlencoded существенно загрузила бы браузер. Да и объём данных после неё сильно вырос бы.
Однако, никто не мешает использовать эту кодировку всегда для POST запросов. Для GET доступна только urlencoded.
How to generate the examples
Once you see an example of each method, it becomes obvious how they work, and when you should use each one.
You can produce examples using:
Save the form to a minimal .html file:
Create files to upload:
Run our little echo server:
Open the HTML on your browser, select the files and click on submit and check the terminal.
nc prints the request received.
Tested on: Ubuntu 14.04.3, nc BSD 1.105, Firefox 40.
10 Answers 10
When you make a POST request, you have to encode the data that forms the body of the request in some way.
HTML forms provide three methods of encoding.
- application/x-www-form-urlencoded (the default)
- multipart/form-data
- text/plain
Work was being done on adding application/json , but that has been abandoned.
When you are writing client-side code:
- use multipart/form-data when your form includes any elements
- otherwise you can use multipart/form-data or application/x-www-form-urlencoded but application/x-www-form-urlencoded will be more efficient
When you are writing server-side code:
Most (such as Perl's CGI->param or the one exposed by PHP's $_POST superglobal) will take care of the differences for you. Don't bother trying to parse the raw input received by the server.
Sometimes you will find a library that can't handle both formats. Node.js's most popular library for handling form data is body-parser which cannot handle multipart requests (but has documentation that recommends some alternatives which can).
If you are writing (or debugging) a library for parsing or generating the raw data, then you need to start worrying about the format. You might also want to know about it for interest's sake.
application/x-www-form-urlencoded is more or less the same as a query string on the end of the URL.
multipart/form-data is significantly more complicated but it allows entire files to be included in the data. An example of the result can be found in the HTML 4 specification.
text/plain is introduced by HTML 5 and is useful only for debugging — from the spec: They are not reliably interpretable by computer — and I'd argue that the others combined with tools (like the Network Panel in the developer tools of most browsers) are better for that).
@Quentin Excuse me, what will be any probable problem if we use multipart for all forms? with and whit out files.
@MasterJoe because it can have multiple data items separated by boundaries, see RFC 2046 section 5.1.1.
Quentin's answer is right: use multipart/form-data if the form contains a file upload, and application/x-www-form-urlencoded otherwise, which is the default if you omit enctype .
- add some more HTML5 references
- explain why he is right with a form submit example
Stating how to send your form to the server
Attribute enctype has sense only when using POST method. When specified, it instructs the browser to send the form by encoding its content in a specific way. From MDN - Form enctype:
When the value of the method attribute is post, enctype is the MIME type of content that is used to submit the form to the server.
- application/x-www-form-urlencoded : This is the default. When the form is sent, all names and values are collected and URL Encoding is performed on the final string.
- multipart/form-data : Characters are NOT encoded. This is important when the form has a file upload control. You want to send the file binary and this ensures that bitstream is not altered.
- text/plain : Spaces get converted, but no more encoding is performed.
5 Answers 5
When uploading a file in your form, you should specify the encoding as "multipart/form-data".
If you want to keep your form generic, omit this attribute in the form and directly override it using formenctype attribute of input or button elements (only possible in browsers with HTML5 support). In your case, change:
Also, you can check this question where it was recommended to avoid always using enctype="multipart/form-data" .
@Mr.Alien you think I know this already? I know a bit, but not much. It was new for me that you can set the formenctype per input element.
I cannot comment directly so I have to write it as an answer.
The only difference I am aware of is in the backend if the backend is using PHP (have no clue if this affects Java/Python or any other language used in the backend apart from PHP).
If PHP is fetching the data from the $_POST and $_FILES superglobals then there should be no problem, you can always use it, but you might have troubles if you are using :
As far as I can remember the content inside $post_content becomes blank, or something similar (it might work with a single file but not multiple files, can't remember correctly. ).
You can do it using javascript
Thank you for this answer. My high level goal is to do less, not more. But you are right, executing this javascript snippet works around the uncertainty (if somebody is still unsure)
I think you should opt use enctype="multipart/form-data" always.. As it's capable to send any data type.but as you no need to manage backward compatibility with the old browser then you can go with HTML5 for not only this other functionality also which you want in your generic template.
You can check HTML 5 attributes available at this link HTML5 Attributes
I recommend you to add a filter/interceptor which will grab all parameters from the request and put in some data structure or a generic function which help them to extract value from the request which will help backend developer to get the data from the request.
You also can write a javascript function which will be called on every form submit and submit the request to the server based or attribute or some specified format which will work even client browsers is older.
Материал на этой странице устарел, поэтому скрыт из оглавления сайта.
Во время обычной отправки формы браузер собирает значения её полей, делает из них строку и составляет тело GET/POST-запроса для посылки на сервер.
HTML5 references
There are three possibilities for enctype :
POST с urlencoded
В методе POST параметры передаются не в URL, а в теле запроса. Оно указывается в вызове send(body) .
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
В зависимости от enctype браузер кодирует данные соответствующим способом перед отправкой на сервер.
В частности, при POST обязателен заголовок Content-Type , содержащий кодировку. Это указание для сервера – как обрабатывать (раскодировать) пришедший запрос.
Для примера отправим запрос в кодировке application/x-www-form-urlencoded :
Всегда используется только кодировка UTF-8, независимо от языка и кодировки страницы.
Если сервер вдруг ожидает данные в другой кодировке, к примеру windows-1251, то их нужно будет перекодировать.
POST с multipart/form-data
Достаточно указать в заголовке Content-Type кодировку и границу, и далее сформировать тело запроса, удовлетворяющее требованиям кодировки.
Пример кода для того же запроса, что и раньше, теперь в кодировке multipart/form-data :
Тело запроса будет иметь вид, описанный выше, то есть поля через разделитель.
Можно создать запрос, который сервер воспримет как загрузку файла.
Для добавления файла нужно использовать тот же код, что выше, модифицировав заголовки перед полем, которое является файлом, так:
Синтаксис
Спецификация
Другие кодировки
Поэтому для обмена данными часто используется формат JSON:
multipart/form-data
For the binary file and text field, the bytes 61 CF 89 62 ( aωb in UTF-8) are sent literally. You could verify that with nc -l localhost 8000 | hd , which says that the bytes:
were sent ( 61 == 'a' and 62 == 'b').
Therefore it is clear that:
Content-Type: multipart/form-data; boundary=---------------------------735323031399963166993862150 sets the content type to multipart/form-data and says that the fields are separated by the given boundary string.
But note that the:
has two less dashes -- than the actual barrier
This is because the standard requires the boundary to start with two dashes -- . The other dashes appear to be just how Firefox chose to implement the arbitrary boundary. RFC 7578 clearly mentions that those two leading dashes -- are required:
4.1. "Boundary" Parameter of multipart/form-data
As with other multipart types, the parts are delimited with a boundary delimiter, constructed using CRLF, "--", and the value of the "boundary" parameter.
every field gets some sub headers before its data: Content-Disposition: form-data; , the field name , the filename , followed by the data.
The server reads the data until the next boundary string. The browser must choose a boundary that will not appear in any of the fields, so this is why the boundary may vary between requests.
Because we have the unique boundary, no encoding of the data is necessary: binary data is sent as is.
Content-Type is automatically determined by the browser.
Атрибуты
What does enctype='multipart/form-data' mean in an HTML form and when should we use it?
It's for POSTing entire files as part of form submission. I thought it might have something to do with multiple parts of text-form input, but it doesn't, it's just for file uploads.
application/x-www-form-urlencoded
Now change the enctype to application/x-www-form-urlencoded , reload the browser, and resubmit.
Clearly the file data was not sent, only the basenames. So this cannot be used for files.
As for the text field, we see that usual printable characters like a and b were sent in one byte, while non-printable ones like 0xCF and 0x89 took up 3 bytes each: %CF%89 !
Comparison
File uploads often contain lots of non-printable characters (e.g. images), while text forms almost never do.
From the examples we have seen that:
multipart/form-data : adds a few bytes of boundary overhead to the message, and must spend some time calculating it, but sends each byte in one byte.
application/x-www-form-urlencoded : has a single byte boundary per field ( & ), but adds a linear overhead factor of 3x for every non-printable character.
Therefore, even if we could send files with application/x-www-form-urlencoded , we wouldn't want to, because it is so inefficient.
But for printable characters found in text fields, it does not matter and generates less overhead, so we just use it.
On OS X, nc won't accept both the -l and the -p arguments simultaneously. But this works for me: while true; do printf '' | nc -l 8000; done .
So far as I can tell, the point of putting ANY DASHES AT ALL in the boundary is to make it impossible to check the syntax of the request by eye. Please don't use them in your boundary tokens.
@DewiMorgan You are completely right. I edited the post and removed the dashes from the boundary string.
@CiroSantilli冠状病毒审查六四事件法轮功 The point is not that dashes in the boundary string wouldn't work. They do work perfectly. But, as Dewi Morgan said: They are unnecessary and highly confusing because the multipart/form-data encoding requires setting "--" before each boundary and after the last boundary.
enctype='multipart/form-data is an encoding type that allows files to be sent through a POST. Quite simply, without this encoding the files cannot be sent through POST.
If you want to allow a user to upload a file via a form, you must use this enctype.
From what I understand, you can use multipart/form-data for sending non-binary files but it is inefficient. I believe using application/x-www-form-urlencoded is the correct way to send non-binary data but someone with more experience with non-binary files may need to correct me.
The main advantage to using multipart/form-data for sending a file is that it will work automatically in both frontend and backend. You don't have to do any special handling. All files are binary even if they should only contain text. application/x-www-form-urlencoded is the standard way to POST a form without attached files. multipart/form-data is the standard way to POST a form with attached file(s). (There are also numerous other encodings, such as application/json and application/json-patch+json , which are common for communication between server and client.)
Читайте также: