Enctype = ‘Multipart / form-data’ nghĩa là gì?

khi nào tất cả chúng ta nên sử dụng nó

Lời đáp của Quentin là đúng: sử dụng multipart/form-datanếu biểu mẫu có chứa tệp tải lên và application/x-www-form-urlencodednếu không, đó là mặc định nếu như khách hàng bỏ qua enctype.

Tôi sẽ:

  • thêm một số tài liệu tham khảo HTML5
  • giảng giải lý do vì sao anh ta đúng với một ví dụ gửi mẫu

Tài liệu tham khảo HTML5

Có ba khả năng cho enctype:

  • application/x-www-form-urlencoded
  • multipart/form-data(thông số kỹ thuật chỉ ra RFC7578 )
  • text/plain. Đây là “không đáng tin cậy bằng máy tính”, vì vậy nó không bao giờ nên được sử dụng trong sinh sản và chúng tôi sẽ không còn nhìn sâu hơn vào nó.

Cách tạo các ví dụ

Khi chúng ta thấy một ví dụ về mỗi phương thức, nó sẽ trở thành rõ ràng về phong thái chúng hoạt động và khi nào bạn nên sử dụng từng phương thức.

Bạn cũng có thể tạo các ví dụ bằng phương pháp sử dụng:

  • nc -lhoặc sever ECHO: Sever thử nghiệm HTTP chấp thuận các yêu cầu GET / POST
  • một tác nhân người dùng như trình duyệt hoặc cURL

Lưu biểu mẫu vào một trong những .htmltệp tối thiểu :

<!DOCTYPE htmlvàgt; <html lang=”en”> <headvàgt; <meta charset=”utf-8″/> <titlevàgt;uploadvàlt;/titlevàgt; </headvàgt; <bodyvàgt; <form action=”http://localhost:8000″ method=”post” enctype=”multipart/form-data”> <pvàgt;<input type=”text” name=”text1″ value=”text default”> <pvàgt;<input type=”text” name=”text2″ value=”aωb”> <pvàgt;<input type=”file” name=”file1″> <pvàgt;<input type=”file” name=”file2″> <pvàgt;<input type=”file” name=”file3″> <pvàgt;<button type=”submit”>Submitvàlt;/buttonvàgt; </formvàgt; </bodyvàgt; </htmlvàgt;

Chúng tôi thiết lập các giá trị văn bản mặc định aωb, có tức thị aωbbởi vì ωlà U+03C9, đó là các byte 61 CF 89 62trong UTF-8.

Tạo tập tin để tải lên:

echo ‘Content of a.txt.’ > a.txt echo ‘<!DOCTYPE htmlvàgt;<titlevàgt;Content of a.html.</titlevàgt;’ > a.html # Binary file containing 4 bytes: ‘a’, 1, 2 and ‘b’. printf ‘axCFx89b’ > binary

Chạy sever echo nhỏ của chúng tôi:

while true; do printf ” | nc -l 8000 localhost; done

Mở HTML trên trình duyệt của bạn, chọn các tệp và nhấp vào gửi và kiểm tra thiết bị đầu cuối.

nc in yêu cầu nhận được.

Đã thử nghiệm trên: Ubuntu 14.04.3, ncBSD 1.105, Firefox 40.

nhiều tài liệu / biểu mẫu

Firefox đã gửi:

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 htmlvàgt;<titlevàgt;Content of a.html.</titlevàgt; -735323031399963166993862150 Content-Disposition: form-data; name=”file3″; filename=”binary” Content-Type: application/octet-stream aωb -735323031399963166993862150-

So với tệp nhị phân và trường văn bản, các byte 61 CF 89 62( aωbtrong UTF-8) được gửi theo nghĩa đen. Bạn cũng có thể xác minh rằng với nc -l localhost 8000 | hd, nói rằng các byte:

61 CF 89 62

đã được gửi ( 61== ‘a’ và 62== ‘b’).

Vì vậy, rõ ràng rằng:

  • Content-Type: multipart/form-data; boundary=-9051914041544843365972754266đặt loại nội dung thành multipart/form-datavà nói rằng các trường được phân tích bằng boundarychuỗi đã cho .

  • mỗi trường có một số tiêu đề phụ trước tài liệu của nó : Content-Disposition: form-data;, trường name, the filename, theo sau là tài liệu.

    Sever đọc tài liệu cho tới chuỗi ranh giới tiếp theo. Trình duyệt phải chọn một ranh giới sẽ không còn xuất hiện trong bất kỳ trường nào, vì vậy đây là lý do vì sao ranh giới có thể khác nhau giữa các yêu cầu.

    Bởi vì chúng tôi có ranh giới duy nhất, không cần mã hóa tài liệu: tài liệu nhị phân được gửi như hiện có.

    TODO: kích thước ranh giới tối ưu ( log(N)tôi đặt cược) và tên / thời kì chạy của thuật toán tìm thấy nó là gì? Đã hỏi tại: https://cs.stackexchange.com/questions/39487/find-the-shortest- resultence-that-is-not-a-sub-resultence-of-a-set-of- result

  • Content-Type được tự động hóa xác định bởi trình duyệt.

    Làm thế nào nó được xác định xác thực đã được hỏi tại: Làm thế nào loại mime của một tệp tải lên được xác định bởi trình duyệt?

ứng dụng / x-www-form-urlencoding

Hiện nay thay đổi enctypethành application/x-www-form-urlencoded, tải lại trình duyệt và gửi lại.

Firefox đã gửi:

POST / HTTP/1.1 [[ Less interesting headers … ]] Content-Type: application/x-www-form-urlencoded Content-Length: 51 text1=text+defaultvàamp;text2=a%CF%89bvàamp;file1=a.txtvàamp;file2=a.htmlvàamp;file3=binary

Rõ ràng tài liệu tệp không được gửi, chỉ có những tên cơ sở. Vì vậy, điều này sẽ không thể được sử dụng cho những tập tin.

So với trường văn bản, chúng tôi thấy rằng các ký tự có thể in thông thường như avà bđược gửi trong một byte, trong lúc các ký tự không in được như vậy 0xCFvà 0x89chiếm 3 byte mỗi ký tự : %CF%89!

So sánh

Tải lên tệp thường chứa nhiều ký tự không in được (ví dụ hình ảnh), trong lúc các hình thức văn bản hầu như không bao giờ thực hiện.

Từ các ví dụ tất cả chúng ta đã thấy rằng:

  • multipart/form-data: thêm một vài byte ngân sách biên cho thông tin và phải dành thời kì để tính toán nó, nhưng sẽ gửi mỗi byte trong một byte.

  • application/x-www-form-urlencoded: có một ranh giới byte đơn trên mỗi trường ( &), nhưng thêm hệ số ngân sách tuyến tính là 3x cho từng ký tự không in được.

Do đó, ngay cả những lúc chúng tôi có thể gửi tệp cùng application/x-www-form-urlencoded, chúng tôi sẽ không còn muốn, vì nó rất kém hiệu quả.

Nhưng khi đối chiếu với các ký tự có thể in được tìm thấy trong các trường văn bản, nó không quan trọng và tạo ra ít ngân sách hơn, vì vậy chúng tôi chỉ sử dụng nó.

You May Also Like

About the Author: v1000