2010-11-03 20 views
7

mã hóa mặc định mà người dùng nên sử dụng để giải mã multipart/form-data nếu không có bộ ký tự nào được cung cấp? RFC2388 khẳng định:multipart/form-data, bộ ký tự mặc định cho các trường là gì?

4,5 Charset của văn bản trong dữ liệu mẫu

Mỗi phần của một multipart/form-data là phải có một trang nội dung loại. Trong trường hợp phần tử trường là văn bản, thông số ký tự cho văn bản cho biết mã hóa ký tự được sử dụng.

Ví dụ, một hình thức với một trường văn bản, trong đó một người dùng gõ 'Joe nợ <eu> 100' nơi <eu> là biểu tượng Euro có thể có dữ liệu mẫu trở như:

--AaB03x 
content-disposition: form-data; name="field1" 
content-type: text/plain;charset=windows-1250 
content-transfer-encoding: quoted-printable>> 

Joe owes =80100. 
--AaB03x 

Trong trường hợp của tôi, bộ ký tự không được đặt và tôi không biết cách giải mã dữ liệu trong phần văn bản/đồng bằng đó. Vì tôi không muốn thực thi một cái gì đó không phải là hành vi tiêu chuẩn, tôi hỏi những gì hành vi mong đợi trong trường hợp này là. RFC dường như không giải thích được điều này vì vậy tôi bị lạc.

Cảm ơn bạn!

Trả lời

5

Bộ mã mặc định cho HTTP 1.1 là ISO-8859-1 (Latin1), tôi đoán rằng điều này cũng áp dụng ở đây.

3.7.1 Quá trình chuẩn hóa và văn bản Defaults

--snip--

Các "charset" tham số được sử dụng với một số loại phương tiện truyền thông để xác định bộ ký tự (phần 3.4) của dữ liệu. Khi không có thông số bộ ký tự rõ ràng nào được cung cấp bởi người gửi, các loại phụ phương tiện của loại "văn bản" được xác định để có giá trị mặc định của ký tự "ISO-8859-1" khi nhận được qua HTTP. Dữ liệu trong các bộ ký tự khác với "ISO-8859-1" hoặc các tập con của nó phải được gắn nhãn bằng giá trị ký tự thích hợp. Xem phần 3.4.1 để biết các vấn đề tương thích.

5

Điều này dường như đã thay đổi trong HTML5 (xem http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data).

Các phần của tài nguyên đa phần/biểu mẫu được tạo tương ứng với trường không phải tệp phải không có tiêu đề Loại nội dung được chỉ định.

Vậy bộ ký tự được chỉ định ở đâu? Theo như tôi có thể biết từ thuật toán mã hóa, địa điểm duy nhất nằm trong mục nhập dữ liệu biểu mẫu có tên _charset_.

Nếu biểu mẫu của bạn không có đầu vào bị ẩn có tên _charset_, điều gì sẽ xảy ra? Tôi đã thử nghiệm điều này trong Chrome 28, gửi biểu mẫu được mã hóa bằng UTF-8 và một trong ISO-8859-1 và kiểm tra tiêu đề và tải trọng đã gửi và tôi không thấy bộ ký tự được cung cấp ở bất kỳ đâu (mặc dù mã hóa văn bản chắc chắn thay đổi). Nếu tôi bao gồm trường trống _charset_ trong biểu mẫu, Chrome sẽ điền vào đó bằng loại bộ ký tự chính xác. Tôi đoán bất kỳ mã phía máy chủ nào cũng phải tìm trường _charset_ này để tìm ra?

Tôi đã gặp sự cố này khi viết tiện ích Chrome sử dụng XMLHttpRequest.send của đối tượng FormData, trong đó always gets encoded in UTF-8 no matter what the source document encoding is.

Cho phép cơ quan thực thể yêu cầu là kết quả của việc chạy thuật toán mã hóa nhiều biểu mẫu/dữ liệu với dữ liệu dưới dạng tập dữ liệu biểu mẫu và với utf-8 làm mã hóa ký tự rõ ràng.

Để loại mime là kết nối của "multipart/form-data;", ký tự U + 0020 SPACE, "boundary =" và chuỗi ranh giới nhiều biểu mẫu/dữ liệu được tạo bởi mã hóa nhiều biểu mẫu/dữ liệu thuật toán.

Như tôi đã tìm thấy trước đó, charset = utf-8 không được xác định bất cứ nơi nào trong yêu cầu POST, trừ khi bạn bao gồm một trống trường _charset_ vào biểu mẫu, mà trong trường hợp này sẽ tự động được dân cư với "utf- số 8".

Đây là hiểu biết của tôi về trạng thái của sự vật. Tôi hoan nghênh mọi sửa đổi đối với các giả định của tôi!

+0

Chính xác cùng một vấn đề với tôi, nhưng giải pháp không hoạt động. Những gì tôi nhận được thay vào đó là một phần của payload với 'name' được đặt thành' charset', nhưng không có tuyên bố nào cả. Đây là đầu vào của tôi: '' – Ercksen

+0

@Ercksen, bạn nên sử dụng đầu vào "__ \ _ charset \ ___" – Romeno

1

Nhờ giải thích chi tiết của @owlman.

Chỉ cần một số thông tin thêm ở đây:

Tải lên yêu cầu trọng tải đoạn:

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

Nếu "xxx.txt" có một số char UNICODE trong đó sử dụng mã UTF-8, Resin (tính đến 4.0. 40) không thể giải mã nó một cách chính xác, nhưng Jetty (9.x) có thể. Tôi nghĩ lý do cho hành vi của Resin là loại Nội dung không chỉ định bất kỳ mã hóa nào, vì vậy Resin giải mã tên tệp bằng cách sử dụng "ISO8859-1", điều này có thể dẫn đến các ký tự bị cắt xén.

tôi đã làm một số googling:

https://mail-archives.apache.org/mod_mbox/struts-user/200310.mbox/%[email protected]%3E

Dường như hành vi Resin là theo Servlet Spec 2.3

Và tôi không thể tìm thấy bất kỳ cài đặt từ http://www.caucho.com/resin-4.0/reference.xtp mà có thể thay đổi hành vi này cho Nhựa.

Các vấn đề liên quan