讓我建立這個工具的錯誤非常小。我正在將一個 HTML 電子郵件範本(幾百行帶有引號、換行符和奇怪的反斜線)填充到 JSON 欄位中以發送到 API,並且請求不斷以 400 的形式返回。該範本很好。 JSON 本身就很好。但當兩人相遇的那一刻,一個未轉義的雙引號三百個字符悄悄地提前關閉了字串,而解析器無法理解它變成垃圾之後的一切。我已將有效文字貼到有效容器中並產生無效文件。
這就是 JSON 逃脫解決的整個問題,值得理解而不是解決。本指南涵蓋了逃跑的實際作用、哪些角色必須逃脫以及原因、逃脫如何逆轉以及如何使用自由 JSON 逃生/逃避 用於在 JSON 字串中移入和移出任意文字的工具,而不會出現任何靜默故障。它與我在 中寫過的其他資料實用程式並存 JSON 工具終極指南.
TL;DR: JSON 字串不能包含原始雙引號、原始反斜線或原始控製字元(例如換行符和製表符)。轉義用反斜線序列替換每個 -
"成為\",換行符變成\n,一個選項卡變成\t並且低於 U+0020 的任何其他值都會變成\uXXXX. Unescaping 將這些序列變回原始字元。這 JSON 逃生/逃避 工具在瀏覽器中同時執行這兩種操作,並提供將結果包裝在引號中的選項,以轉義非 ASCII as\uXXXX,或逃脫前斜線。
為 JSON 逃避字串是什麼意思？
JSON 有一個精確的、已發布的語法 - 它的定義是 RFC 8259 根據 ECMA-404 標準,字串中可能出現的內容的規則是嚴格的。 JSON 字串是一系列用雙引號包裹的字元。因為雙引號標記了字串的開始和結束,所以雙引號 裡面 文字會過早結束它。因為反斜線開始轉義序列,所以原始反斜線會被誤讀為轉義序列的開始。而且由於 JSON 字串是文字的單一邏輯行,因此文字控製字元(換行符、製表符、回車符)不允許不轉義地位於其中。
逃脫是用 JSON 理解的兩個字元反斜線序列替換每個麻煩字元的過程。雙引號變成 \". 反斜線變成 \\. 換行符變成 \n. 結果是文字 看起來 稍微醜一點,但現在可以安全地在兩個引號之間掉落,而不會破壞周圍的文檔。含義是相同的 - JSON 解析器讀取 \n 再次產生真正的換行符 - 但現在該表示是合法的。
這與格式化 JSON 文件有著根本的不同。格式化程式排列整個物件的結構:縮排、按鍵排序、元素之間的空格。轉義操作向下一級 單一字串值的內容. 你伸手去拿 json 格式化程式 當您有一整份文件需要列印或驗證時,並且 JSON 逃生/逃避 當您有一塊原始文字時,您需要將其放入一個欄位中的工具。
哪些角色實際上需要逃脫?
JSON 規範在這裡非常具體。在字串內,恰好有兩個字元 必須的 始終逃脫,加上整個控製字元範圍。
兩個強制性的單字符轉義是雙引號 (\") 和反斜線 (\\).除此之外,JSON 還定義了五個常見控製字元的短逃:退格鍵 (()\b),表格提要(\f),換行符(\n)、回車(\r),以及水平選項卡(\t).任何 其他 控製字元 - 代碼點低於 U+0020 且沒有簡短表單的任何字元 - 必須寫為 a \u 轉義後面跟著四個十六進位數字,因此空位元組變為 \u0000 "單位分隔符號"成為 \u001F.
還有兩個角色 可選 為了逃避,這就是混亂蔓延的地方。前斜線可以寫成 \/,但它不一定是--平原 / 是完全有效的 JSON。以及 ASCII 範圍以上的任何字符,例如重音字符 é 或表情符號,可以按字面意思寫在 UTF-8 文件中,也可以轉義為 \uXXXX;兩者都是合法的。這 JSON 逃生/逃避 tool 始終處理強制轉義,並為您提供兩個可選轉義的切換,以便您可以匹配目標系統期望的任何內容。
我應該逃避前斜線和非 ASCII 字元嗎?
這兩個可選逃脫的存在有真正的原因,即使您很少需要它們。
前向斜線轉義在一種常見情況下很重要:當 JSON 嵌入到 HTML 中時 <script> 標籤。瀏覽器' HTML 解析器尋找文字序列 </ 要找到腳本區塊的結尾,因此字串包含 </script> 在 JSON 中,可以過早關閉標籤並破壞頁面。將斜線寫成 <\/script> - 仍然有效的 JSON,解析後仍然是相同的字串 - 避免了這一點。在內聯腳本之外,您可以單獨留下斜線,這就是為什麼該工具預設不保留前向斜線的原因。
轉義非 ASCII 字元為 \uXXXX 是關於可移植性而不是正確性。如果您的 JSON 可能經過一個破壞 UTF-8 位元組的系統 - 一個舊的日誌記錄管道、一個配置錯誤的代理、一個假設 ASCII 的通道 - 將 ASCII 範圍以上的每個字元變成純 ASCII \u 逃脫保證它完好無損地保存下來。輸出體積更大,人類可讀性較差,因此預設為關閉,但 "逃脫 Unicode"切換暫時就在那裡,您需要防彈運輸。一個代碼點,例如 é 成為 \u00e9,JSON 解析器在出路時重建原始字元。
逃脫是如何運作的?我什麼時候需要它?
Unescaping 是恰恰相反的:它穿過轉義字串並將每個反斜線序列轉回它所表示的原始字元。 \n 成為真正的換行符, \t 成為一個選項卡, \" 成為雙引號,並且 \uXXXX 成為該代碼點的字元。每當您處於接收端時,您就需要它 - 您直接從 JSON 檔案、日誌行或 API 回應複製了字串值,並且您想要讀取原始文本,而無需在螢幕上顯示反斜線。
一個好的逃亡者會做兩件事,而天真的尋找和替換則不會。首先,如果引用整個值,它會剝離周圍的一對雙引號,以便您可以貼上 "line one\nline two" 直接從 JSON 文件中取出乾淨的文字。第二,它 驗證 照常進行:無效的轉義序列,例如 \x,或者字串末尾的雜散反斜線,是一個真正的錯誤,並且 JSON 逃生/逃避 工具報告其位置,而不是猜測並默默地產生錯誤的輸出。獲得清晰的 "在位置 14" 處無效逃脫;擊敗獲得看起來幾乎正確但巧妙損壞的文字。
值得信賴的關鍵屬性是,轉義和轉義是精確的逆。轉義任何文本,然後轉義結果,然後您就可以準確地返回您開始的內容,逐個字元。這種往返保證使得將該工具用作管道中的常規步驟而不是您必須手動仔細檢查的危險轉換變得安全。
轉義操作與相關字串操作
JSON escaping 是 " 系列之一;使本文對於該上下文安全"轉換,它有助於保持它們正確。以下是它與開發人員最常混淆的鄰居的比較。
| 操作 | 防止 | 例子 | 工具 |
|---|---|---|---|
| JSON 逃脫 | 用引號、反斜線或控制字元打破 JSON 字串 | he said "hi" → he said \"hi\" |
JSON 逃生/逃避 |
| HTML 實體編碼 | 破解 HTML 或啟用 XSS <, >, & |
<b> → <b> |
HTML 實體 |
| URL 百分比編碼 | 使用空格或保留字元破壞 URL | a b → a%20b |
- |
| JSON 格式/驗證 | 整個文件的結構錯誤 | 縮小版 → 列印精美 | json 格式化程式 |
| JSON → YAML | 在序列化格式之間移動配置 | {"a":1} → a: 1 |
JSON 到 YAML |
需要注意的模式是每次逃跑的目標都是 a 不同的 容器。 HTML 實體防止文字破壞 HTML;百分比編碼可以防止它破壞 URL; JSON 轉義可以防止它破壞 JSON 字串。使用錯誤的方法 - 對需要 JSON 轉義的 HTML 編碼 - 不會解決真正的問題並添加新的噪音層。因為所有這些都在您可能不想交給第三方伺服器的文字上運行,所以我將這些工具中的每一個都保留在客戶端,這是我在 中完整提出的論點 線上工具的資料隱私指南.
在 JSON 中嵌入文字時常見哪些錯誤?
最常見的錯誤是讓我花了一個下午的時間:將帶有未轉義引文的多行文字直接貼到 JSON 欄位中,並假設因為兩個部分都有效,所以整個部分都有效。事實並非如此--容器有內容必須遵守的規則。
緊秒是 雙重逃脫。 如果字串已經轉義一次並且您又轉義一次,則每一次 \n 成為 \\n 你的換行符變成了一個字面的反斜線-n,沒有解析器會轉換回來。當一個值經過兩個系統時,通常會發生這種情況,每個系統都有幫助地逃脫它。如果您的輸出運行可疑 \\ 在你期望單反斜線的地方,你可能已經雙轉義了,一次轉義就可以修復它。第三個陷阱是忘記 Windows 路徑之類的東西 C:\Users\me 充滿了反斜線,每一個都必須變成 \\ - JSON 中一條未逃脫的路徑是 " 的經典來源;為什麼我的 JSON 無效"混亂。
這三個問題的修復是相同的:讓工具在原始文字與 JSON 交會的邊界處執行一次轉義,並讀取它顯示的字元計數摘要,以理智地檢查某些內容已更改。當您需要手動驗證時,使用 " 逃脫;換行引用和引用;啟用並將結果貼上到 json 格式化程式 - 如果它解析為有效字串,則您的轉義是正確的。
一個可行的範例:在 JSON 中嵌入 HTML 片段
讓我回顧一下開始這種情況的確切情況,因為看到這種轉變曾經使規則得以遵守。說你想把這個片段當作發送 body API 請求欄位:
<p>Hi "there",</p>
<p>Visit https://example.com/path</p>
該文本中的三件事將與 JSON 作鬥爭。兩個雙引號周圍 there 每個人都會嘗試結束字串。段落之間的換行符是字串中 JSON 禁止的文字控製字元。和 </p> 序列在普通 JSON 檔案中是無害的,但如果將此 JSON 列印在 HTML 中則很危險 <script> 標籤。將片段貼到 JSON 逃生/逃避 工具,開啟"換行引號,"您將獲得一個有效的 JSON 字串:引號變為 \",換行符變成 \n,並且與 "轉義斜線和引用;啟用結束標籤成為 <\/p>。 將整個報價直接放入您的 body 欄位並遍歷請求。
反向旅行也同樣例行公事。當隊友用 JSON 逃生器向您發送一條日誌行時 message 字段充滿 \n 和 \",將其貼到工具中,切換到 Unescape,然後閱讀原始多行文本,反斜線消失。由於這兩個操作是精確的逆運算,因此您可以將有效負載移出以編輯它並返回,而不必擔心損壞- 字元計數摘要確認轉換已運行,並且任何格式錯誤的轉義都會以其位置標記,而不是默默地損壞文字。這種往返安全將逃避緊張的手動步驟轉變為你可以連接到工作流程並忘記的事情。
常見問題
為 JSON 逃避字串是什麼意思？ JSON 字串值不能包含原始雙引號、原始反斜線或原始控製字元(例如換行符和製表符)。轉義用反斜線序列替換每個 - "變成&引用;,換行符變成 \n,製表符變成 \t - 因此文字可以放置在 JSON 字串內,而不會破壞周圍結構。
這與 JSON 格式化程式有何不同？ JSON 格式化程式漂亮地列印或縮小整個 JSON 文件並驗證其結構。 此工具向下工作一層，在單一字串的內容上：它使任意文字可以安全地嵌入 JSON 值，或將轉義值解碼回原始文字。 使用文件格式化程式和單一字串的此工具。
哪些角色被逃脫了？ 雙引號 (")、反斜線 (\)、退格鍵 (\b)、表單來源 (\f)、換行符 (\n)、回車鍵 (\r) 和製表符 (\t) 始終轉義,以及U+0020 以下的任何其他控製字元(如\uXXXX)。可選地,前斜線變為/,每個非 ASCII 字元變為\uXXXX。
我應該逃避前方的斜線嗎？ 它是可選的。 JSON 規範允許/和/,因此簡單的/是有效的。 /重要的地方位於 HTML 內
