JSON Thoát / Hủy Thoát

Escape các ký tự đặc biệt của một chuỗi để tích hợp JSON an toàn, hoặc unescape một chuỗi JSON sang văn bản thuần.

Cách thức hoạt động

  1. Dán chuỗi của bạn: nhập văn bản để escape, đây có thể là văn bản thuần chứa các dấu ngoặc kép, các xuống dòng, các dấu gạch chéo ngược hoặc bất kỳ ký tự đặc biệt nào khác.
  2. Chọn escape hoặc unescape: chọn xem bạn muốn escape văn bản để nhúng nó trong JSON, hay unescape một chuỗi JSON thành văn bản dễ đọc.
  3. Sao chép kết quả: đầu ra đã escape hoặc unescape xuất hiện ngay lập tức. Sao chép nó để sử dụng trong mã hoặc dữ liệu của bạn.

Tại sao sử dụng escape JSON?

Các chuỗi JSON có các quy tắc escape nghiêm ngặt, các dấu ngoặc kép phải trở thành \", các xuống dòng \n, các dấu gạch chéo ngược \\ và các tab \t. Không escape đúng các ký tự này gây ra các lỗi phân tích JSON làm hỏng các API, các tệp cấu hình và các pipeline dữ liệu. Công cụ này tự động xử lý tất cả việc escape và unescape, loại bỏ tìm-thay thế thủ công và tránh các bug tinh vi do các chuỗi escape bị bỏ sót.

Tính năng

Câu hỏi thường gặp

Các ký tự nào escape JSON xử lý?

JSON yêu cầu escape: các dấu ngoặc kép ("), dấu gạch chéo ngược (\), dấu gạch chéo (/), xuống dòng (\n), return chariot (\r), tab (\t), trang nhảy (\f), backspace (\b) và các ký tự Unicode trên U+FFFF. Công cụ này xử lý tất cả chúng.

Tại sao lỗi phân tích JSON của tôi do escape?

Các nguyên nhân phổ biến bao gồm các dấu ngoặc kép không escape bên trong một giá trị chuỗi, các xuống dòng theo nghĩa đen trong một chuỗi (phải là \n) và các dấu gạch chéo ngược không escape. Dán chuỗi bị hỏng của bạn vào đây để escape nó đúng cách.

Nó có bao gồm các dấu ngoặc kép bao quanh không?

Mặc định, công cụ escape nội dung mà không bao quanh các dấu ngoặc kép, để bạn có thể dán kết quả vào chuỗi JSON của bạn. Kích hoạt tùy chọn «Bao gồm các dấu ngoặc kép» nếu bạn muốn đầu ra được bao quanh bởi các dấu ngoặc kép.

Đặc tả chuỗi JSON, trong một bảng

RFC 8259 (tháng 12 năm 2017, bởi Tim Bray) là tiêu chuẩn JSON hiện tại, thay thế RFC 7159 và RFC 4627 ban đầu. Phần 7 của đặc tả liệt kê chính xác các ký tự nào PHẢI được escape bên trong một chuỗi literal:

Ký tự Escape Code point Ý nghĩa
"\"U+0022dấu ngoặc kép (kết thúc chuỗi)
\\\U+005Cdấu gạch chéo ngược (bắt đầu một escape)
\b\bU+0008backspace
\f\fU+000Cform feed
\n\nU+000Axuống dòng (LF)
\r\rU+000Dtrở về đầu dòng (CR)
\t\tU+0009tab
/\/U+002Fdấu gạch chéo (tùy chọn, nhưng hữu ích cho việc nhúng HTML)
control\uXXXXU+0000-U+001Fbất kỳ ký tự điều khiển C0 nào không được đề cập ở trên

Các quy tắc tương đương có trong ECMA-404 (phiên bản thứ 2, tháng 12 năm 2017), được giữ đồng bộ với đặc tả IETF. JSON không có escape bát phân (\012) hoặc thập lục phân (\x41), những thứ đó chỉ dành cho JavaScript; JSON chỉ hỗ trợ tám escape được đặt tên ở trên cộng với \uXXXX.

Escape \uXXXX và bẫy cặp surrogate

Các chuỗi \uXXXX của JSON mã hóa các đơn vị mã UTF-16, không phải là code point Unicode. Điều đó quan trọng đối với emoji và các ký tự mặt phẳng bổ sung. Một emoji đơn như 😀 (U+1F600) không được escape thành \u1F600 (đó không phải là dạng bốn chữ số hex hợp lệ), mà là cặp surrogate: \uD83D\uDE00, hai escape liên tiếp mã hóa surrogate cao và thấp. Phạm vi surrogate cao là U+D800–U+DBFF; thấp là U+DC00–U+DFFF; cùng nhau chúng bao phủ U+10000 đến U+10FFFF (các mặt phẳng bổ sung).

Đây là nguồn gốc phổ biến nhất của lỗi escape emoji. RFC 8259 Phần 7 nói rõ ràng: «Để escape một ký tự mở rộng không nằm trong Basic Multilingual Plane, ký tự được biểu diễn dưới dạng một chuỗi 12 ký tự, mã hóa cặp surrogate UTF-16.» Một emoji gia đình bốn người như 👨‍👩‍👧‍👦, về mặt kỹ thuật là bốn emoji cơ sở cộng với ba zero-width joiner, được escape thành 30+ ký tự trong một chuỗi JSON. Số byte phình to tương ứng: 25 byte UTF-8 thô, ~58 byte sau khi escape JSON.

JSON bên trong HTML, URL, SQL và CSV

Việc escape JSON một mình không đủ khi JSON được nhúng trong một định dạng khác. Mỗi ngữ cảnh thêm lớp riêng của nó.

JSON bên trong HTML. Cái bẫy cổ điển là <script>const data = {{ payload | json }};</script> khi payload chứa chuỗi con literal </script>. Trình phân tích HTML đóng thẻ script ở giữa chuỗi và phần còn lại của JSON được hiển thị dưới dạng văn bản nhìn thấy được trên trang. Khắc phục là escape tùy chọn \/: <\/script> là JSON hợp lệ và an toàn HTML. Cheat sheet cross-site scripting của OWASP khuyến nghị luôn escape <, >, &' trong JSON dành cho nhúng HTML.

JSON bên trong chuỗi truy vấn URL. Hai lớp: trước tiên escape JSON, sau đó percent-encoding. {"name":"Bob"} trở thành %7B%22name%22%3A%22Bob%22%7D. Quên percent-encoding là nguyên nhân số 1 của các lỗi JSON-trong-URL bị lỗi định dạng.

JSON bên trong SQL. Được lưu trữ trong cột PostgreSQL jsonb, giá trị được phân tích cú pháp tự nhiên, không cần escape thêm. Nhưng JSON được nhúng trong literal chuỗi SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) cần escape chuỗi SQL trên đỉnh JSON: dấu nháy đơn nhân đôi (''), hoặc tốt hơn, sử dụng truy vấn tham số hóa.

JSON bên trong các ô CSV. Việc trích dẫn của CSV khác với JSON (CSV sử dụng dấu nháy nhân đôi "", không phải chuỗi gạch chéo ngược). Nhúng JSON trong một ô CSV cần cả hai lớp: escape JSON chuỗi, sau đó escape CSV kết quả (bọc trong "...", nhân đôi bất kỳ " bên trong).

API runtime trên các ngôn ngữ

Ngôn ngữ Mã hóa Giải mã Ghi chú
JavaScriptJSON.stringifyJSON.parseNative từ IE 8 (2009). Có sẵn trong mọi trình duyệt và Node.
Pythonjson.dumpsjson.loadsensure_ascii=False từ bỏ escape \uXXXX cho non-ASCII.
PHPjson_encodejson_decodeNative từ PHP 5.2 (tháng 11 năm 2006). Cờ JSON_UNESCAPED_UNICODE từ 5.4.
JavaObjectMapper.writeValueAsStringreadTreeJackson là tiêu chuẩn thực tế kể từ ~2009.
Gojson.Marshaljson.UnmarshalThư viện chuẩn encoding/json.
Rustserde_json::to_stringserde_json::from_strCrate serde_json, có mặt khắp nơi.

JSON đến từ đâu, và những gì Crockford đã bỏ ra

JSON lần đầu tiên được chính thức hóa bởi Douglas Crockford vào năm 2001 tại State Software, ban đầu để serialize các đối tượng JavaScript cho việc trao đổi dữ liệu bất đồng bộ. Đề cập công khai đầu tiên là tại trang JSON.org năm 2003. Crockford đã chỉ định nó chính thức là RFC 4627 vào tháng 7 năm 2006, một phần để chống lại một nỗ lực bằng sáng chế cạnh tranh vào cùng thời điểm. Tiêu chuẩn chuyển sang trạng thái STD 90 với RFC 8259 vào tháng 12 năm 2017.

Quyết định thiết kế lớn nhất của JSON là biến nó thành một tập con của JavaScript, để bất kỳ tài liệu JSON nào cũng có thể được eval'd trong một trình phiên dịch JS và mang lại giá trị chính xác. Điều này làm cho việc áp dụng trình duyệt không có ma sát nhưng cũng khóa cố định một số đặc thù của JS: không có kiểu số nguyên (tất cả các số đều là IEEE 754 double), không có kiểu ngày, không có NaN hoặc Infinity. Số nguyên lớn trên 2⁵³−1 cần serialize chuỗi ("id": "9007199254740993") để tránh mất độ chính xác im lặng.

Crockford cố ý bỏ qua những thứ bạn có thể nhớ: chú thích («Tôi đã loại bỏ chú thích khỏi JSON vì tôi thấy mọi người đang sử dụng chúng để chứa chỉ thị phân tích cú pháp, một thực tiễn sẽ phá hủy khả năng tương tác», tháng 5 năm 2012), dấu phẩy sau cùng, và ngôn ngữ schema (được thêm sau dưới dạng JSON Schema, được duy trì riêng biệt, bản nháp hiện tại 2020-12). Biến thể cộng đồng JSON5 khôi phục chú thích và dấu phẩy sau cùng nhưng không tuân thủ RFC; nó được sử dụng chủ yếu trong các tệp cấu hình (.babelrc, .swcrc) mà con người chỉnh sửa.

Các trường hợp sử dụng phổ biến

Lỗi phổ biến

  1. Sử dụng escape JavaScript không hợp lệ JSON. \x41 cho «A» và \012 cho xuống dòng có hiệu lực trong các literal chuỗi JS nhưng không hợp lệ trong JSON. JSON chỉ cho phép tám escape được đặt tên cộng với \uXXXX.
  2. Sử dụng dấu nháy đơn cho các chuỗi JSON. 'hello' hoạt động trong JavaScript nhưng JSON không hợp lệ. Các chuỗi JSON PHẢI sử dụng dấu nháy kép.
  3. Khóa đối tượng không có dấu nháy. {name: "Bob"} hoạt động trong JavaScript nhưng JSON không hợp lệ. Các khóa PHẢI là các literal chuỗi trong dấu nháy kép.
  4. Dấu phẩy sau cùng. [1,2,3,] hoạt động trong JS nhưng JSON không hợp lệ. RFC 8259 cấm chúng một cách rõ ràng.
  5. Chú thích inline. // foo/* foo */ không hợp lệ trong JSON tiêu chuẩn. Sử dụng JSON5 nếu bạn cần chú thích; mong đợi rằng không phải mọi trình phân tích cú pháp sẽ chấp nhận nó.
  6. Tự escape một emoji thành một \uXXXX duy nhất. Emoji trên U+FFFF cần một cặp surrogate UTF-16, hai \uXXXX liên tiếp.

Thêm câu hỏi thường gặp

Tôi có nên luôn escape gạch chéo về phía trước / không?

Không, gạch chéo về phía trước / được phép không escape trong JSON; escape \/ là tùy chọn. Trường hợp ngoại lệ là khi JSON được nhúng bên trong thẻ HTML <script>: escape / thành \/ ngăn chuỗi con literal </script> đóng thẻ trước thời hạn. Một số bộ mã hóa (JSON_HEX_TAG trong PHP, các thay thế JS tùy chỉnh) làm điều này; hầu hết thì không.

Tại sao JSON.stringify escape các ký tự non-ASCII của tôi?

Mặc định thì không. JSON.stringify("café") trong JavaScript tạo ra "café" với é literal. Những gì bạn có thể đang thấy là một thư viện khác: json.dumps của Python mặc định là ensure_ascii=True và escape mọi thứ bên ngoài ASCII thành \uXXXX; json_encode của PHP hoạt động tương tự trừ khi bạn truyền JSON_UNESCAPED_UNICODE. Cả hai hành vi đều là JSON hợp lệ, nhưng kích thước tệp và khả năng đọc khác nhau.

JSON có thể lưu trữ dữ liệu nhị phân không?

Không trực tiếp. Các chuỗi JSON là các chuỗi ký tự Unicode, không phải byte. Giải pháp tiêu chuẩn là mã hóa Base64 nhị phân trước, sau đó lưu trữ chuỗi ASCII kết quả như một giá trị JSON bình thường. Dữ liệu được mã hóa lớn hơn ~33% so với byte thô. Đối với nhị phân rất lớn, hãy sử dụng định dạng nhị phân như BSON, MessagePack hoặc CBOR, hoặc lưu trữ các byte riêng biệt và tham chiếu chúng theo URL.

Tại sao một số công cụ hiển thị \u00e9 thay vì é?

Cả hai đều là JSON hợp lệ cho cùng một ký tự. "caf\u00e9""café" giải mã thành các chuỗi giống hệt nhau. Một số bộ mã hóa escape non-ASCII để có độ an toàn cross-encoding tối đa (đầu ra là ASCII thuần túy nên mã hóa của người tiêu dùng không quan trọng), những bộ khác giữ nguyên UTF-8 gốc để dễ đọc. Chọn dựa trên những gì tiêu thụ JSON của bạn.

Văn bản của tôi có được tải lên đâu không?

Không. Công cụ sử dụng các API JSON.stringifyJSON.parse bản địa của trình duyệt hoàn toàn ở phía client. Không có cuộc gọi mạng, không có phân tích, không có ghi nhật ký. An toàn để escape các token API, dữ liệu nội bộ, hoặc bất cứ điều gì bạn sẽ không dán vào một công cụ escape phía máy chủ.

Công cụ liên quan

Công cụ Định Dạng & Xác Thực JSON Trực Tuyến Miễn Phí Trình Xem Cây JSON Trình Trích Xuất JSON Path Bộ mã hóa / Giải mã thực thể HTML