Đối với phản hồi HTTP với Loại nội dung đề xuất dữ liệu ký tự, bộ ký tự nào phải được trình khách giả định nếu không có chỉ định nào được chỉ định?

Question

Nếu không có tham số charset được quy định trong tiêu đề Content-Type, RFC2616 section 3.7.1 dường như ngụ ý iso8859-1 nên được giả định đối với các loại phương tiện truyền thông của kiểu phụ "text":

Khi không có tham số charset rõ ràng là được cung cấp bởi người gửi, loại phương tiện truyền thông loại "văn bản" được xác định là có giá trị mặc định của ký tự là "ISO-8859-1" khi nhận được qua HTTP.

Dữ liệu trong bộ ký tự khác với "ISO-8859-1" hoặc tập hợp con của nó PHẢI là được gắn nhãn bằng bộ ký tự thích hợp giá trị.

Tuy nhiên, tôi thường thấy các ứng dụng phân phối các tệp Javascript có các giá trị Loại nội dung như "application/x-javascript" (tức là không có thông số charset), ngay cả khi các tập lệnh này chứa ký tự UTF-8 không phải ASCII sẽ bị hỏng nếu được hiểu là ISO8859-1.

Điều này dường như không gây ra sự cố cho khách hàng. Làm thế nào để khách hàng biết để giải thích các byte như UTF-8? Có quy tắc nào cho các loại phụ dữ liệu ký tự khác ngụ ý UTF-8 phải là mặc định không? Tài liệu này ở đâu?

Answer 1

Tất cả các trình duyệt chính tôi đã kiểm tra (IE, FF và Opera) hoàn toàn bỏ qua đặc điểm kỹ thuật RFC trong phần này.

Nếu bạn quan tâm đến thuật toán tự động phát hiện bộ ký tự theo dữ liệu, hãy xem liên kết Mozilla Firefox.

Chỉ một lưu ý nhỏ về các loại nội dung: Chỉ văn bản có bộ ký tự. Đó là hợp lý để giả định rằng các trình duyệt xử lý ứng dụng/x-javascript giống như họ xử lý văn bản/javascript (ngoại trừ IE6, nhưng đó là một chủ đề khác).

Internet Explorer sẽ sử dụng charset mặc định (có thể bảo quản ở registry), như đã nêu:

Theo mặc định, Internet Explorer sử dụng các thiết lập nhân vật được quy định trong HTTP kiểu nội dung được trả về bởi các máy chủ để xác định bản dịch này. Nếu không có thông số này, Internet Explorer sử dụng bộ ký tự được chỉ định bởi phần tử meta trong tài liệu . Sử dụng tùy chọn của người dùng nếu không có phần tử meta nào được chỉ định là .

Nguồn: http://msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx

Mozilla Firefox nỗ lực để tự động phát hiện các charset, như chỉ ở đây:

Bài viết này trình bày ba loại phương pháp tự động phát hiện để xác định mã hóa tài liệu mà không khai báo bộ ký tự rõ ràng.

Nguồn: http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html

Opera sử dụng tính năng tự động phát hiện quá, như tài liệu:

Nếu giao thức vận chuyển cung cấp một tên mã hóa, được sử dụng. Nếu không, Opera sẽ xem trang để khai báo ký tự. Nếu điều này bị thiếu, Opera sẽ cố gắng tự động phát hiện mã hóa, sử dụng tên miền để xem tập lệnh có phải là tập lệnh CJK hay không và nếu có. Opera cũng có thể tự động phát hiện UTF-8.

Nguồn: http://www.opera.com/docs/specs/opera9/

Answer 2

Đó là một chút đặc biệt cho XMLHttpRequest và được mô tả ở đây: http://www.w3.org/TR/XMLHttpRequest/

Answer 3

Chỉ ra rõ ràng: "application/x-javascript" được không phải là một subtype của "văn bản".

Ngoài ra, văn bản trong RFC 2616 đã lỗi thời. Bản sửa đổi tiếp theo của HTTP/1.1 sẽ không xác định mặc định. Xem RFC 6657 để biết thêm thông tin.

Answer 4

Như đã trình bày trong RFC 4329, cũng application/javascript có thể có một tham số charset. Câu hỏi khác là việc xử lý việc triển khai trình duyệt. Xin lỗi, nhưng không được kiểm tra.

Answer 5

RFC 4329 xác định loại phương tiện "ứng dụng/javascript" làm thay thế cho "văn bản/javascript", "ứng dụng/x-javascript" và các loại tương tự khác. Phần 4.2 thiết lập mã hóa ký tự mặc định là UTF-8 khi không có tham số "ký tự" rõ ràng và không có Unicode BOM có mặt ở phía trước của dữ liệu.

Answer 6

Trong trường hợp thông số charset, có thể chỉ định mã hóa ký tự trong nội dung . Dưới đây là một số phương pháp được thực hiện bởi một số loại nội dung:

HTML - Qua meta tag:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 

HTML5 biến thể:

<meta charset="utf-8"> 

XML (XHTML, KML) - Qua số XML declaration:

<?xml version="1.0" encoding="UTF-8"?> 

Văn bản - Qua số Byte order mark.Ví dụ, đối UTF-8 ba byte đầu tiên của một tập tin trong hệ thập lục phân:

EF BB BF 

Như phân biệt với bộ ký tự kết hợp với các tài liệu, cũng lưu ý rằng các ký tự ASCII có thể được mã hóa thông qua ký tự ASCII trình tự sử dụng các cách tiếp cận khác nhau:

HTML - Via character references:

&#nnnn; 
&#xhhhh; 

XML - Via character references:

& 
&defined-entity; 

JSON - Qua escaping mechanism:

\u005C 
\uD834\uDD1E 

Bây giờ, đối với với các giao thức HTTP 1.1, RFC 2616 says this about charset:

Các "charset" tham số được sử dụng với một số loại phương tiện để xác định bộ ký tự (phần 3.4) của dữ liệu. Khi không có thông số rõ ràng do người gửi cung cấp, các loại phương tiện truyền thông của loại "văn bản" được xác định để có giá trị mặc định là "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.

Vì vậy, giải thích của tôi ở trên là một không thể giả một nhân vật mặc định thiết lập trừ cho phân nhóm phương tiện truyền thông của các loại "văn bản". Tất nhiên, chúng ta sống trong thế giới thực và những người thực hiện không phải lúc nào cũng tuân theo các quy tắc. Như được mô tả trong accepted answer, các nhà cung cấp trình duyệt web khác nhau đã triển khai chiến lược riêng của họ để xác định bộ ký tự tài liệu khi nó không được chỉ định rõ ràng. Người ta có thể giả định rằng các nhà cung cấp của các khách hàng khác (ví dụ: Google Earth) cũng thực hiện các chiến lược của riêng họ.