2012-03-05 26 views
5

Tôi đang xuất dữ liệu qua các tệp. Đầu ra là dữ liệu được mã hóa base64.Có phải utf-8 phù hợp với loại văn bản/đồng bằng không?

$data = base64_encode(serialize($data)); 

mà kết quả trong một cái gì đó như:

bGFzcyI6MTp7czo1OiJzZXR1cCI7YTo3Mzp7czoyNToicGFnZXNfY29udGFjdF91c19oZWFkbGlu 

Vì vậy, tôi tự hỏi điều gì charset là phù hợp hơn cho dữ liệu này (plain text). ascii của chúng tôi có vẻ đủ nhưng utf-8 luôn có vẻ là một mặc định chống lỗi.

header('content-type: text/plain; charset=utf-8'); 
+3

Bạn không nên báo giá xung quanh phần văn bản/đồng bằng hoặc utf8. – Quentin

+0

@quentin Cảm ơn. Tôi thực sự không biết nó ... –

+0

Tôi vẫn cảm thấy câu trả lời được chấp nhận là sai (mặc dù tôi đã bị downvoted). Tôi đã làm rõ câu trả lời của mình một chút, quan tâm xem xét lại? – Evert

Trả lời

7

Nó thực sự không quan trọng; nội dung của bạn hợp lệ US-ASCII, hợp lệ UTF-8, hợp lệ ISO-8859-1 (hoặc, tôi tin rằng, bất kỳISO-8859-x), hợp lệ Windows-1252, v.v. Chỉ cần không đặt UTF-16 hoặc EBCDIC hoặc gì đó.

(Đối với giá trị của nó, tôi muốn đi với US-ASCII, vì nó được hỗ trợ đầy đủ bởi ngay cả máy tính tiền Unicode mà không được rõ ràng một bộ ký tự trước Unicode như ISO-8859-1 hoặc không, nhưng đó thực sự là một sở thích chủ quan.)

+0

Một nơi nào đó có thông số kỹ thuật cho biết bạn phải nêu bảng mã là bộ ký tự nhỏ nhất mô tả chính xác nó. Vì vậy, nếu nó là đúng ASCII, nó phải được gọi là thay vì ISO-8859-1 hoặc UTF-8, hoặc nếu nó là tập hợp con ISO-8859-1 của Windows-1252, bạn cũng phải nói điều đó. Tôi nghĩ rằng đây là cho email, vì vậy có thể không áp dụng trong trường hợp này, tuy nhiên. – tchrist

+1

@tchrist: Bạn đúng 90%. Các RFC hiện tại có liên quan (2046 và 2616) đưa ra khuyến nghị đó, nhưng chúng sử dụng "nên" thay vì "phải", trong RFCs là một sự khác biệt có ý nghĩa. Ngoài ra, thú vị, RFC 2616 nói rằng "không ghi nhãn thực thể được ưu tiên hơn ghi nhãn thực thể với nhãn US-ASCII hoặc ISO-8859-1", nhưng IMHO đã lỗi thời khi nói đến ISO-8859-1, vì nhiều người dùng các đại lý hiện nay giả định, trong việc thách thức tiêu chuẩn, một bộ mã mặc định của UTF-8. (Và tôi nhận thấy rằng bản thân IETF phục vụ một số trang với 'charset = ISO-8859-1'.) Nhưng nó vẫn có thể áp dụng cho US-ASCII. – ruakh

+0

Nhưng mặc dù nó tương thích với US-ASCII, điều đó không làm cho nó US-ASCII :) Tôi làm rõ câu trả lời của riêng tôi, bạn vẫn không đồng ý? – Evert

19

Thậm chí bạn sẽ không cần bộ ký tự. 'text/plain' có thể không chính xác, bởi vì nó cũng không thực sự là văn bản.

Mặc dù nó tương thích với ascii, utf-8, latin1 (như ruakh được đề cập), bạn chỉ nên coi đó là tệp nhị phân.

Cập nhật

tôi muốn làm rõ điều này một chút (sau khi tất cả các downvotes, guys chung cho tôi một cơ hội!)

@ dan04: UTF-8 là văn bản, tôi đã không nói không phải vậy. Base64 không phải là, base64 cũng là một mã hóa, nhưng nó có thể mã hóa bất kỳ chuỗi nhị phân nào. Base64 được mã hóa theo cách mà nó có thể bọc nó trong US-ASCII (và do đó cũng là UTF-8 và latin1/ISO-8859).

Base64 vẫn chỉ là chuỗi nhị phân, chứ không phải theo văn bản định nghĩa. Thực tế là cùng một loạt các giá trị octet được sử dụng như US-ASCII (và 'printable' bởi bất cứ thứ gì đọc US-ASCII) không làm cho nó thành văn bản.

Đây cũng là lý do tại sao Base64 không có mimetype riêng. Nó được coi là một mã hóa chuyển nội dung. (nhìn lên!)

Vì vậy, cách chính xác thực sự để phân phát Base64 với mimetype của chuỗi chứa, cùng với tiêu đề Mã hóa-Chuyển mã hóa. Ví dụ, nếu bạn đang mã hóa một jpeg, đây là định dạng đúng.

Content-Type: image/jpeg 
Content-Transfer-Encoding: base64 

Đây cũng là lý do tại sao tôi không muốn nói bất cứ điều gì về nội dung của chuỗi (hoặc không có thông tin này), tốt nhất là coi đó là 'binary binary', ví dụ:

Content-Type: application/octet-stream 
Content-Transfer-Encoding: base64 
+0

Văn bản UTF-8 không phải là văn bản? – dan04

+1

@ dan04: Tôi đã cập nhật câu trả lời của mình. Hy vọng điều này có ý nghĩa hơn – Evert

+2

+1 Điều bạn đề cập thực sự thú vị. Tôi sẽ có nó trong tài khoản trong tương lai. Trong trường hợp của tôi, tôi đã sử dụng 'US-ASCII' vì thực sự là một đối tượng được tuần tự hóa var. Cảm ơn sự đóng góp của bạn. –

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