Mã hóa ký tự JSON - UTF-8 có được hỗ trợ tốt bởi các trình duyệt hay tôi nên sử dụng chuỗi thoát số?

Tôi đang viết một dịch vụ web sử dụng json để đại diện cho các tài nguyên của nó và tôi hơi khó nghĩ về cách tốt nhất để mã hóa json. Đọc json rfc ( http://www.ietf.org/rfc/rfc4627.txt ) rõ ràng là kiểu mã hóa ưu tiên là utf-8. Nhưng rfc cũng mô tả một cơ chế thoát chuỗi để chỉ định các ký tự. Tôi cho rằng điều này thường được sử dụng để thoát các ký tự không phải ascii, do đó làm cho kết quả utf-8 ascii hợp lệ.

Vì vậy, giả sử tôi có một chuỗi json chứa các ký tự unicode (điểm mã) không phải là ascii. Dịch vụ web của tôi nên mã hóa utf-8 và trả lại nó, hay nó phải thoát tất cả các ký tự không phải ascii đó và trả về ascii thuần túy?

Tôi muốn các trình duyệt có thể thực thi kết quả bằng jsonp hoặc eval. Điều đó có ảnh hưởng đến quyết định? Kiến thức của tôi về hỗ trợ javascript của các trình duyệt khác nhau cho utf-8 còn thiếu.

CHỈNH SỬA: Tôi muốn làm rõ rằng mối quan tâm chính của tôi về cách mã hóa kết quả thực sự là về việc xử lý kết quả của trình duyệt. Những gì tôi đã đọc chỉ ra rằng các trình duyệt có thể nhạy cảm với mã hóa khi sử dụng JSONP nói riêng. Tôi không tìm thấy bất kỳ thông tin thực sự tốt nào về chủ đề này, vì vậy tôi sẽ phải bắt đầu thực hiện một số thử nghiệm để xem điều gì sẽ xảy ra. Lý tưởng nhất là tôi chỉ muốn thoát một số ký tự được yêu cầu và chỉ mã hóa utf-8 kết quả.

Đặc tả JSON yêu cầu bộ giải mã hỗ trợ UTF-8. Do đó, tất cả các bộ giải mã JSON đều có thể xử lý UTF-8 cũng như chúng có thể xử lý các chuỗi thoát số. Đây cũng là trường hợp của trình thông dịch Javascript, có nghĩa là JSONP cũng sẽ xử lý JSON được mã hóa UTF-8.

Khả năng bộ mã hóa JSON sử dụng các chuỗi thoát số thay vào đó chỉ cung cấp cho bạn nhiều lựa chọn hơn. Một lý do khiến bạn có thể chọn trình tự thoát dạng số là nếu cơ chế truyền tải giữa bộ mã hóa của bạn và bộ giải mã dự kiến ​​không an toàn nhị phân.

Một lý do khác mà bạn có thể muốn sử dụng trình tự thoát số là để ngăn chặn một số nhân vật xuất hiện trong dòng, chẳng hạn như <, &và ", trong đó có thể được giải thích dưới dạng HTML chuỗi nếu mã JSON được đặt mà không cần thoát sang HTML hoặc một trình duyệt không đúng diễn giải nó dưới dạng HTML . Đây có thể là một biện pháp bảo vệ chống lại việc chèn HTML hoặc tập lệnh giữa các trang web (lưu ý: một số ký tự PHẢI được thoát trong JSON, bao gồm "và \).

Một số khung công tác, bao gồm cả việc triển khai JSON của PHP, luôn thực hiện các chuỗi thoát dạng số ở phía bộ mã hóa cho bất kỳ ký tự nào bên ngoài ASCII. Điều này nhằm mục đích tương thích tối đa với các cơ chế vận chuyển hạn chế và những thứ tương tự. Tuy nhiên, điều này không nên được hiểu là một dấu hiệu cho thấy bộ giải mã JSON có vấn đề với UTF-8.

Vì vậy, tôi đoán bạn chỉ có thể quyết định sử dụng như thế này:

• Chỉ cần sử dụng UTF-8, trừ khi phương pháp lưu trữ hoặc vận chuyển của bạn giữa bộ mã hóa và bộ giải mã không an toàn nhị phân.

• Nếu không, hãy sử dụng các chuỗi thoát số.

Tôi đã có một vấn đề ở đó. Khi tôi JSON mã hóa một chuỗi có ký tự như "é", mọi trình duyệt sẽ trả về cùng một "é", ngoại trừ IE sẽ trả về "\ u00e9".

Sau đó với PHP json_decode (), nó sẽ không thành công nếu tìm thấy "é", vì vậy đối với Firefox, Opera, Safari và Chrome, tôi phải gọi utf8_encode () trước json_decode ().

Lưu ý: với các thử nghiệm của tôi, IE và Firefox đang sử dụng đối tượng JSON gốc của chúng, các trình duyệt khác đang sử dụng json2.js.

ASCII không còn trong đó nữa. Sử dụng mã hóa UTF-8 có nghĩa là bạn không sử dụng mã hóa ASCII. Những gì bạn nên sử dụng cơ chế thoát là những gì RFC nói:

Tất cả các ký tự Unicode có thể được đặt trong dấu ngoặc kép ngoại trừ các ký tự phải được thoát ra ngoài: dấu ngoặc kép, dấu gạch ngang ngược và các ký tự điều khiển (U + 0000 đến U + 001F)

Tôi đã phải đối mặt với cùng một vấn đề. Nó làm việc cho tôi. Làm ơn kiểm tra cái này.

json_encode($array,JSON_UNESCAPED_UNICODE);

Đọc json rfc ( http://www.ietf.org/rfc/rfc4627.txt ) rõ ràng là kiểu mã hóa ưu tiên là utf-8.

FYI, RFC 4627 không còn là thông số JSON chính thức. Nó đã được xóa sổ vào năm 2014 bởi RFC 7159 , sau đó được xóa sổ vào năm 2017 bởi RFC 8259 , đây là thông số kỹ thuật hiện tại.

RFC 8259 trạng thái:

8.1. Mã hóa ký tự

Văn bản JSON được trao đổi giữa các hệ thống không thuộc hệ sinh thái khép kín PHẢI được mã hóa bằng UTF-8 [RFC3629] .

Các thông số kỹ thuật trước đây của JSON không yêu cầu sử dụng UTF-8 khi truyền văn bản JSON. Tuy nhiên, phần lớn các triển khai phần mềm dựa trên JSON đã chọn sử dụng mã hóa UTF-8, ở mức độ mà nó là mã hóa duy nhất đạt được khả năng tương tác.

Việc triển khai KHÔNG ĐƯỢC thêm dấu thứ tự byte (U + FEFF) vào đầu văn bản JSON được truyền qua mạng. Vì lợi ích của khả năng tương tác, các triển khai phân tích cú pháp văn bản JSON CÓ THỂ bỏ qua sự hiện diện của dấu thứ tự byte thay vì coi nó như một lỗi.

Tôi đã gặp sự cố tương tự với é char ... Tôi nghĩ nhận xét "có thể văn bản bạn đang cho nó không phải là UTF-8" có lẽ gần với dấu ở đây. Tôi có cảm giác đối chiếu mặc định trong trường hợp của tôi là một cái gì đó khác cho đến khi tôi nhận ra và thay đổi thành utf8 ... vấn đề là dữ liệu đã ở đó, vì vậy không chắc liệu nó có chuyển đổi dữ liệu hay không khi tôi thay đổi nó, hiển thị tốt trong mysql bàn làm việc. Kết quả cuối cùng là php sẽ không mã hóa dữ liệu json, chỉ trả về false. Không quan trọng bạn sử dụng trình duyệt nào làm máy chủ gây ra sự cố của tôi, php sẽ không phân tích cú pháp dữ liệu thành utf8 nếu có ký tự này. Giống như tôi nói không chắc liệu đó có phải là do chuyển đổi lược đồ thành utf8 sau khi có dữ liệu hay chỉ là một lỗi php. Trong trường hợp này sử dụngjson_encode(utf8_encode($string));