Vreau să pun o întrebare despre multipart/form-data
. În antetul HTTP, mi se pare că Content-Type: multipart/form-data; boundary=???
.
Este ???
gratuit pentru a fi definite de către utilizator? Sau este generat de HTML? Este posibil pentru mine pentru a defini ??? = abcdefg
?
Este
???
gratuit pentru a fi definite de către utilizator?
Da.
sau este furnizat de HTML?
Nr. HTML a nimic de-a face cu asta. Citiți mai jos.
Este posibil pentru mine pentru a defini
???
caabcdefg
?
Da.
Dacă doriți să trimiteți următoarele date la serverul de web:
name = John
age = 12
folosind `application/x-www-form-urlencoded", " ar fi ca aceasta:
name=John&age=12
După cum puteți vedea, serverul știe că parametrii sunt separate prin simbolul " & " &
. Dacă &
este necesar pentru o valoare a parametrului, atunci acesta trebuie să fie codificat.
Deci, cum se face server știu în cazul în care valoarea unui parametru începe și se termină atunci când primește o cerere HTTP, folosind multipart/form-data
?
Folosind hotar, similare cu &
.
De exemplu:
--XXX
Content-Disposition: form-data; name="name"
John
--XXX
Content-Disposition: form-data; name="age"
12
--XXX--
În acest caz, valoarea limită este XXX
. Specificați în "Content-Type" de antet, astfel încât serverul stie cum să împartă datele pe care le primește.
Deci, aveți nevoie pentru a:
Utilizați o valoare care a câștigat't apar în HTTP datele trimise la server.
Să fie în concordanță și de a folosi aceeași valoare peste tot în mesajul de solicitare.
Răspunsul exact la întrebarea este: da, puteți folosi o valoare arbitrară pentru limita
parametru, având în vedere că nu depășească 70 bytes în lungime și constă numai din 7-bit US-ASCII
(tipărit) caractere.
Dacă utilizați unul dintre multipart/` tipuri de conținut, vă sunt de fapt necesar* pentru a specifica limita
parametru în "Content-Type" antet, în caz contrar server (în cazul de o cerere HTTP) nu va fi capabil de a analiza încărcătura.
Probabil, de asemenea, doriți să setați charset
parametru UTF-8
în "Content-Type" antet, dacă nu poate fi absolut sigur că doar NE-ASCII` charset vor fi utilizate în încărcătura de date.
Câteva relevante extrase din RFC2046:
4.1.2. Charset Parametru:
spre Deosebire de alte valori ale parametrilor, valorile parametrilor caracterelor NU sunt sensibile la majuscule. Setul de caractere implicit, care trebuie să fie asumate în absența unui set de caractere parametru, este US-ASCII.
5.1. Mai Multe Mass-Media De Tip
după Cum se menționează în definiția Content-Transfer-Encoding domeniul [RFC 2045], nu de codificare, altele decât "7bit", "8bit", sau "binar" este permisă pentru entitățile de tip "mai multe". "mai multe" limita delimitatori și câmpuri antet sunt întotdeauna reprezentate ca 7bit US-ASCII în orice caz (deși câmpurile de antet poate codifica non-US-ASCII text antet ca pe RFC 2047) și datele în părți ale corpului pot fi codificate pe de o parte-de-o parte de bază, cu Content-Transfer-Encoding câmpuri pentru fiecare caz parte a corpului.
Conținutul-Tip de teren pentru mai multe entități necesită un parametru, "limita". Limita delimitator linie este apoi definită ca o linie formată în întregime din două personaje cratimă ("-", valoarea zecimală 45), urmată de limita parametru valoarea din antetul Content-Type domeniu, opțional liniar de spațiu, și o rezistență CRLF.
Limita delimitatori nu trebuie să apară în încapsulate material, și trebuie să fie nu mai mult de 70 de caractere, nu de numărare principalele două cratime.
limita delimitator linia de la ultima parte a corpului este un distins delimitator, care indică faptul că nu există alte părți ale corpului vor urma. Astfel un delimitator linie este identică cu cea anterioară delimitator linii, cu adaos de mai multe de două cratime după limita valorii parametrului.
Aici este un exemplu folosind o limită arbitrară:
Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"
--another cool boundary
Content-Disposition: form-data; name="foo"
bar
--another cool boundary
Content-Disposition: form-data; name="baz"
quux
--another cool boundary--
"Multipurpose Internet Mail Extensions (MIME) Partea a Doua: Tipurile de mass-Media"
multipart/form-data conține limita pentru a separa perechile nume/valoare. Limita acționează ca un marker de fiecare bucată de perechi nume/valoare la trecut, atunci când un formular este trimis. Limita este adăugat automat la un tip de conținut de o cerere antet.
Forma cu enctype="multipart/form-data" atribut va avea o cerere antet Content-Type : multipart/form-data; de frontieră --- WebKit193844043-h (browser-ul generat vaue).
Încărcătura trecut arata ceva de genul asta:
Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW
-----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name=”file”; filename=”captcha”
Content-Type:
-----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name=”action”
submit
-----WebKitFormBoundary7MA4YWxkTrZu0gW--
Pe webservice parte, se's a consumat în @Consumă("multipart/form-data") formular.
Feriți-vă, atunci când testarea webservice folosind chrome poștaș, aveți nevoie pentru a verifica datele din formular opțiune(buton radio) și meniul Fișier din caseta derulantă pentru a trimite atașament. Explicit furnizarea de conținut-tipul multipart/form-data aruncă o eroare. Deoarece limita este de lipsă ca se poate răsuci cerere de om post de server cu conținutul-tip prin adăugarea la limita care funcționează bine.
A se vedea RFC1341 sec7.2 Multipart Content-Type