Respuestas:
Cuando realiza una solicitud POST, tiene que codificar los datos que forman el cuerpo de la solicitud de alguna manera.
Los formularios HTML proporcionan tres métodos de codificación.
application/x-www-form-urlencoded (el valor por defecto)multipart/form-datatext/plainSe estaba trabajando en agregar application/json, pero eso ha sido abandonado.
(Son posibles otras codificaciones con solicitudes HTTP generadas por otros medios que no sean el envío de un formulario HTML. JSON es un formato común para usar con servicios web y algunos todavía usan SOAP).
Los detalles de los formatos no son importantes para la mayoría de los desarrolladores. Los puntos importantes son:
text/plain.Cuando escribe código del lado del cliente:
multipart/form-datacuando su formulario incluya cualquier <input type="file">elementomultipart/form-datao application/x-www-form-urlencodedpero application/x-www-form-urlencodedserá más eficienteCuando escribe código del lado del servidor:
La mayoría (como Perl CGI->paramo la expuesta por el $_POSTsuperglobal de PHP ) se encargará de las diferencias por usted. No se moleste en tratar de analizar la entrada sin formato recibida por el servidor.
A veces encontrarás una biblioteca que no puede manejar ambos formatos. La biblioteca más popular de Node.js para manejar datos de formulario es body-parser que no puede manejar solicitudes de varias partes (pero tiene documentación que recomienda algunas alternativas que sí pueden).
Si está escribiendo (o depurando) una biblioteca para analizar o generar los datos sin procesar, entonces debe comenzar a preocuparse por el formato. También es posible que desee saber al respecto por el interés.
application/x-www-form-urlencoded es más o menos lo mismo que una cadena de consulta al final de la URL.
multipart/form-dataes significativamente más complicado pero permite incluir archivos completos en los datos. Se puede encontrar un ejemplo del resultado en la especificación HTML 4 .
text/plaines introducido por HTML 5 y es útil solo para la depuración, a partir de la especificación : no son interpretables de manera confiable por computadora , y diría que los otros combinados con herramientas (como el Panel de red en las herramientas de desarrollador de la mayoría de los navegadores) son mejores para eso).
cuando deberíamos usarlo
La respuesta de Quentin es correcta: utilícela multipart/form-datasi el formulario contiene una carga de archivo y application/x-www-form-urlencoded, de lo contrario, cuál es el valor predeterminado si omite enctype.
Voy a:
Hay tres posibilidades para enctype:
application/x-www-form-urlencodedmultipart/form-data(puntos de especificación a RFC7578 )text/plain. Esto "no se puede interpretar de manera confiable por computadora", por lo que nunca se debe usar en la producción, y no lo analizaremos más a fondo.Una vez que vea un ejemplo de cada método, se hace evidente cómo funcionan y cuándo debe usar cada uno.
Puede producir ejemplos usando:
nc -lo un servidor ECHO: servidor de prueba HTTP que acepta solicitudes GET / POSTGuarde el formulario en un .htmlarchivo mínimo :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title>upload</title>
</head>
<body>
<form action="http://localhost:8000" method="post" enctype="multipart/form-data">
<p><input type="text" name="text1" value="text default">
<p><input type="text" name="text2" value="aωb">
<p><input type="file" name="file1">
<p><input type="file" name="file2">
<p><input type="file" name="file3">
<p><button type="submit">Submit</button>
</form>
</body>
</html>Establecemos el valor de texto predeterminado en aωb, lo que significa aωbporque ωes U+03C9, que son los bytes 61 CF 89 62en UTF-8.
Crear archivos para cargar:
echo 'Content of a.txt.' > a.txt
echo '<!DOCTYPE html><title>Content of a.html.</title>' > a.html
# Binary file containing 4 bytes: 'a', 1, 2 and 'b'.
printf 'a\xCF\x89b' > binaryEjecute nuestro pequeño servidor echo:
while true; do printf '' | nc -l 8000 localhost; doneAbra el HTML en su navegador, seleccione los archivos y haga clic en enviar y verifique el terminal.
nc imprime la solicitud recibida.
Probado en: Ubuntu 14.04.3, ncBSD 1.105, Firefox 40.
Firefox envió:
POST / HTTP/1.1
[[ Less interesting headers ... ]]
Content-Type: multipart/form-data; boundary=---------------------------735323031399963166993862150
Content-Length: 834
-----------------------------735323031399963166993862150
Content-Disposition: form-data; name="text1"
text default
-----------------------------735323031399963166993862150
Content-Disposition: form-data; name="text2"
aωb
-----------------------------735323031399963166993862150
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain
Content of a.txt.
-----------------------------735323031399963166993862150
Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html
<!DOCTYPE html><title>Content of a.html.</title>
-----------------------------735323031399963166993862150
Content-Disposition: form-data; name="file3"; filename="binary"
Content-Type: application/octet-stream
aωb
-----------------------------735323031399963166993862150--Para el archivo binario y el campo de texto, los bytes 61 CF 89 62( aωben UTF-8) se envían literalmente. Puede verificar eso con nc -l localhost 8000 | hd, que dice que los bytes:
61 CF 89 62fueron enviados ( 61== 'a' y 62== 'b').
Por lo tanto, está claro que:
Content-Type: multipart/form-data; boundary=---------------------------735323031399963166993862150establece el tipo de contenido multipart/form-datay dice que los campos están separados por la boundarycadena dada .
Pero tenga en cuenta que el:
boundary=---------------------------735323031399963166993862150tiene dos papas menos --que la barrera real
-----------------------------735323031399963166993862150Esto se debe a que el estándar requiere que el límite comience con dos guiones --. Los otros guiones parecen ser exactamente cómo Firefox eligió implementar el límite arbitrario. RFC 7578 menciona claramente que --se requieren esos dos guiones iniciales:
4.1. Parámetro "límite" de datos multiparte / formulario
Al igual que con otros tipos de varias partes, las partes se delimitan con un delimitador de límite, construido utilizando CRLF, "-" y el valor del parámetro "límite".
cada campo se pone algunas cabeceras sub antes de que sus datos: Content-Disposition: form-data;el campo name, la filename, seguido de los datos.
El servidor lee los datos hasta la siguiente cadena de límite. El navegador debe elegir un límite que no aparecerá en ninguno de los campos, por lo que el límite puede variar entre las solicitudes.
Debido a que tenemos el límite único, no es necesaria la codificación de los datos: los datos binarios se envían tal cual.
TODO: ¿cuál es el tamaño de límite óptimo ( log(N)apuesto) y el nombre / tiempo de ejecución del algoritmo que lo encuentra? Preguntado en: /cs/39687/find-the-shortest-sequence-that-is-not-a-sub-sequence-of-a-set-of-sequences
Content-Type se determina automáticamente por el navegador.
Se preguntó cómo se determina exactamente en: ¿Cómo se determina el tipo mime de un archivo cargado por el navegador?
Ahora cambie enctypea application/x-www-form-urlencoded, vuelva a cargar el navegador y vuelva a enviar.
Firefox envió:
POST / HTTP/1.1
[[ Less interesting headers ... ]]
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
text1=text+default&text2=a%CF%89b&file1=a.txt&file2=a.html&file3=binaryClaramente, los datos del archivo no se enviaron, solo los nombres básicos. Por lo tanto, esto no se puede usar para archivos.
En cuanto al campo de texto, vemos que a los caracteres imprimibles habituales les gusta ay bse enviaron en un byte, mientras que a los no imprimibles les gusta 0xCFy 0x89ocupaban 3 bytes cada uno %CF%89:!
Las cargas de archivos a menudo contienen muchos caracteres no imprimibles (por ejemplo, imágenes), mientras que los formularios de texto casi nunca lo hacen.
De los ejemplos hemos visto que:
multipart/form-data: agrega unos pocos bytes de sobrecarga de límite al mensaje, y debe pasar algún tiempo calculándolo, pero envía cada byte en un byte.
application/x-www-form-urlencoded: tiene un límite de un solo byte por campo ( &), pero agrega un factor de sobrecarga lineal de 3x por cada carácter no imprimible.
Por lo tanto, incluso si pudiéramos enviar archivos con application/x-www-form-urlencoded, no nos gustaría, porque es muy ineficiente.
Pero para los caracteres imprimibles que se encuentran en los campos de texto, no importa y genera menos sobrecarga, por lo que solo lo usamos.
%CFes de 3 bytes de longitud: %, Cy F:-) historia de lo que es legible por humanos.
ncno aceptará tanto -llos -pargumentos como simultáneamente. Pero esto funciona para mí: while true; do printf '' | nc -l 8000; done.
Content-Typetiene dos guiones ( --) menos, es decir, cuando se usa el límite en el cuerpo del mensaje, debe colocarle un prefijo --. Además, el último límite debe tener el sufijo --, pero eso es bastante fácil de notar. Ver stackoverflow.com/questions/3508252/…
enctype='multipart/form-dataes un tipo de codificación que permite enviar archivos a través de una POST . Simplemente, sin esta codificación, los archivos no pueden enviarse a través de POST .
Si desea permitir que un usuario cargue un archivo a través de un formulario, debe utilizar este tipo de letra .
multipart/form-datapara enviar archivos no binarios, pero es ineficiente. Creo que usar application/x-www-form-urlencodedes la forma correcta de enviar datos no binarios, pero alguien con más experiencia con archivos no binarios puede necesitar corregirme.
multipart/form-data para enviar un archivo es que funcionará automáticamente tanto en el front-end como en el back-end. No tiene que hacer ningún manejo especial. Todos los archivos son binarios, incluso si solo deben contener texto. application/x-www-form-urlencodedes la forma estándar de PUBLICAR un formulario sin archivos adjuntos. multipart/form-dataes la forma estándar de PUBLICAR un formulario con archivos adjuntos. (También hay muchas otras codificaciones, como application/jsony application/json-patch+json, que son comunes para la comunicación entre el servidor y el cliente).
multipart/form-data. Lo que no puede hacer es hacerlo utilizando un envío de formulario HTML normal, sin JavaScript. Establecer un formulario para usar multipart/form-dataes el único mecanismo que proporciona HTML para permitirle POSTAR archivos sin usar JavaScript. Siento que esto no es lo suficientemente claro en la respuesta, y que un lector ingenuo podría pensar que la incapacidad para enviar archivos sin multipart/form-datauna limitación de HTTP ; ese no es el caso.
Al enviar un formulario, le indica a su navegador que envíe, a través del protocolo HTTP, un mensaje en la red, debidamente envuelto en una estructura de mensaje de protocolo TCP / IP. Una página HTML tiene una forma de enviar datos al servidor: usando <form>s.
Cuando se envía un formulario, se crea una solicitud HTTP y se envía al servidor, el mensaje contendrá los nombres de campo en el formulario y los valores completados por el usuario. Esta transmisión puede ocurrir con métodos HTTPPOST o .GET
POST le dice a su navegador que cree un mensaje HTTP y coloque todo el contenido en el cuerpo del mensaje (una forma muy útil de hacer las cosas, más segura y también flexible).GETenviará los datos del formulario en la cadena de consulta . Tiene algunas restricciones sobre la representación y la longitud de los datos.Atributo enctype solo tiene sentido cuando se usa el POSTmétodo. Cuando se especifica, indica al navegador que envíe el formulario codificando su contenido de una manera específica. De MDN - Formulario enctype :
Cuando el valor del atributo del método es post, enctype es el tipo de contenido MIME que se utiliza para enviar el formulario al servidor.
application/x-www-form-urlencoded: Este es el valor predeterminado. Cuando se envía el formulario, se recopilan todos los nombres y valores y se realiza la codificación de URL en la cadena final.multipart/form-data: Los caracteres NO están codificados. Esto es importante cuando el formulario tiene un control de carga de archivos. Desea enviar el archivo binario y esto asegura que bitstream no se altere.text/plain: Los espacios se convierten, pero no se realiza más codificación.Al enviar formularios, pueden surgir algunos problemas de seguridad como se indica en RFC 7578 Sección 7: Datos de formulario de varias partes - Consideraciones de seguridad :
Todo el software de procesamiento de formularios debe tratar los datos de formulario proporcionados por el usuario
con sensibilidad, ya que a menudo contiene información confidencial o de
identificación personal . Existe un uso generalizado de las funciones de "autocompletar" en los navegadores web; estos podrían usarse para engañar a los usuarios para que
envíen información confidencial sin saberlo al completar
tareas que de otra manera serían inocuas. multipart / form-data no proporciona ninguna característica
para verificar la integridad, garantizar la confidencialidad, evitar la
confusión del usuario u otras características de seguridad; esas preocupaciones deben ser
abordadas por las aplicaciones de llenado de formularios e interpretación de datos de formularios.Las aplicaciones que reciben formularios y los procesan deben tener cuidado de no proporcionar datos al sitio de procesamiento de formularios que no fue enviado.
Al interpretar el nombre de archivo del
campo de encabezado Content- Disposition es importante no sobrescribir accidentalmente archivos en el
espacio de archivos del destinatario.
Esto le preocupa si es un desarrollador y su servidor procesará los formularios enviados por los usuarios que podrían terminar conteniendo información confidencial.
enctypehacer. Sé que es literalmente del multipart/form-dataRFC, pero no obstante es un volcado arbitrario de consideraciones de seguridad sobre el envío de formularios que son completamente ortogonales a si los datos se envían como application/x-www-form-urlencodedo multipart/form-data.
Establezca el atributo de método en POST porque el contenido del archivo no se puede colocar dentro de un parámetro de URL mediante un formulario.
Establezca el valor de enctype en multipart / form-data porque los datos se dividirán en varias partes, una para cada archivo más una para el texto del cuerpo del formulario que se puede enviar con ellos.
POSTes probable que sea suficiente para enviar un archivo a través de un formulario y que agregar multipart/form-dataes solo una ventaja de alguna manera vaga. Ese no es el caso. La mayoría de los archivos requerirán absolutamente el uso multipart/form-data.
<head>y <body>es irrelevante y confuso.
Por lo general, esto es cuando tiene un formulario POST que necesita tomar la carga de un archivo como datos ... esto le dirá al servidor cómo codificará los datos transferidos, en tal caso no se codificará porque simplemente transferirá y cargará los archivos al servidor, como por ejemplo al cargar una imagen o un pdf
El atributo enctype especifica cómo se deben codificar los datos de formulario al enviarlos al servidor.
El atributo enctype solo se puede usar si method = "post".
No hay caracteres codificados. Este valor es obligatorio cuando utiliza formularios que tienen un control de carga de archivos
De W3Schools
multipart/form-data. Tampoco está bastante claro; ¿Qué significa incluso la oración "No se codifican caracteres"? -1.