開發者工具 · JSON 格式化程式和驗證程序
JSON 字串轉義解釋：\n、\uXXXX 和控製字符
· 工作原理
json 開發人員工作流程 驗證
JSON 字串中的原始換行符號無效，製表符也是如此。這篇文章介紹了八個轉義序列、\u 轉義和代理對如何工作，以及為什麼貼上的段落會使整個檔案無效。
破壞有效負載的段落
破壞有效負載的段落 - 將可見換行符貼到引用的描述中會將控製字元直接插入 JSON 字串中。第一行看起來很完整，但開頭引號仍然需要字串內容或結尾引號。當解析器到達原始換行符時，它會在那裡停止，因為 JSON 字串不能以這種方式跨越物理行。只要解碼值需要換行符，文字就必須包含兩個字元轉義 `\n`。
從檔案或電子表格複製的製表符會導致同類故障，即使編輯器可能會將它們呈現為無害的間距。將文字製表符替換為 `\t`，將回車符號替換為 `\r`，並將其他禁止的控制項替換為其命名或 Unicode 轉義符。
八種轉義 JSON 允許
JSON 允許的八種轉義符 - 在反斜線之後，縮寫形式為 `"`、`\\`、`\/`、`\b`、`\f`、`\n`、`\r` 和 `\t`。它們表示引號、反制約槓、斜線、退格、換頁、換行、````````分裝配位表詞也可能沒有斜線/斜線1/2/2``````````s(Marft）也可能未換行、`````(/``````如果/假線/假線。的存在主要是為了與曾經專門處理結束腳本序列的上下文相容。
JSON 反斜線後面不能有其他字母。程式語言中常見的序列（例如 `\v`、`\0`、`\x41` 或反斜線後接實體換行符）在這裡無效。當不存在短轉義時，請使用 `\u` 後面跟著四個十六進位數字。這個小的固定詞彙表使 JSON 字串保持可移植性：消費者不需要 JavaScript、Python 或特定於 shell 的轉義規則來確定有效文字表示的字元。
為什麼文字製表符無效但文字 é 可以
為什麼文字製表符無效，但文字 é 可以 - JSON 禁止字串內從 U+0000 到 U+001F 的未轉義代碼點。此範圍包含分頁、換行符和其他控件，其不可見效果可能會破壞框架或顯示。字母 `é` 是 U+00E9，遠遠超出了控制範圍，因此 UTF-8 JSON 可以將其直接包含在引號之間。對於大多數腳本、符號和表情符號也是如此。
因此，轉義普通 Unicode 是可選的，而不是清理要求。 `"café"` 和 `"caf\u00e9"` 解碼為相同的字元序列。直接文字通常更容易讓人閱讀，而轉義可以幫助僅 ASCII 傳輸或使特定代碼單元可見。控製字元不同：它們的轉義是強制性的。
\uXXXX 如何轉義工作
`\uXXXX` 轉義如何運作 - `u` 後面必須緊跟著四個十六進位數字，在任何情況下都使用 0–9 或 A–F。 `\u00E9` 表示 `é` 的 UTF-16 代碼單元，`\u000A` 表示換行。較少的數字、大括號（例如 `\u{1F600}`）或非十六進位字母會使 JSON 無效，即使另一種程式語言接受該表示法。
U+FFFF 以上的字元在此轉義形式中表示為代理對。表情符號 😀 可以寫為 `\uD83D\uDE00`：高代理和低代理在解析為一個 Unicode 標量值後組合在一起。 JSON 語法可以攜帶不成對的代理轉義，但下游編碼器和應用程式可能會拒絕或替換它，因為它不能識別完整的 Unicode 字元。
工作範例：轉義 Windows 路徑和 HTML 片段
工作範例：轉義 Windows 路徑和 HTML 片段 - 預期路徑 `C:\Temp\report.txt` 需要在 JSON 來源中將每個反斜線加倍：`"C:\\Temp\\report.txt"`。如果不加倍， `\T` 是無效的轉義，並諸如 `\r` 或 `\t` 之類的序列可以默默地成為控製字元而不是路徑分隔符。根據預期值建立 JSON，而不是透過猜測哪些顯示的斜線已經屬於外部語言。
HTML 片段（例如 `<a title="Report">Open</a>`）可以按字面意思保留其尖括號和斜杠，但屬性引號必須在 JSON 字串內變為 `\"`。如果換行符號分隔兩個標籤，請將其編碼為 `\n`。可以驗證產生的 JSON 成員並將其解析回原始 HTML 文字。
逃跑次數加倍的地方
轉義符加倍的地方 - 每個封閉的文字語法都有自己的機會來解釋反斜線。包含解碼字串 `line1\nline2` 的 JSON 檔案必須轉義該反斜杠，產生 `"line1\\nline2"`。如果 JSON 文字本身儲存為 JSON 字串，則其引號和兩個反斜線需要另一層轉義。明顯的混亂記錄了多種表示形式，而不是 JSON 的特殊擴展形式。
shell 和程式語言文字在 JSON 解析器看到參數之前加入自己的引用規則。從內到外診斷：首先寫入準確的解碼值，將其編碼為 JSON 一次，然後為周圍的 shell 或原始語言編碼完整的 JSON 文字。在每個邊界，檢查下一個解析器實際接收到的位元組或字元。
這不包括什麼
這不包括 - HTML 實體（例如 `"`）和 URL 百分比編碼（例如 `%20`）是針對單獨語法上下文的單獨轉換。 JSON 解析器不會解碼任何一種形式。字串 `"""` 解析後包含六個文字字符，而不是引號，而 `"%20"` 包含一個百分號後跟兩位數字，而不是空格。僅當資料跨入 HTML 或 URL 元件時才套用這些編碼。
此討論也不會取代輸出編碼。從不受信任的來源接收的有效 JSON 仍然可以包含 HTML、類似腳本的文字或終端控制序列作為普通字串資料。稍後呈現或執行命令的應用程式必須安全地處理該目的地。 JSON 轉義保護 JSON 結構；這不是普遍的消毒。
重點：逃避語法所禁止的內容，僅此而已
重點：轉義語法所禁止的內容，僅此而已 - 雙引號、反斜杠和 U+0020 下面的代碼點需要在 JSON 字符串內引起注意。普通 Unicode 可以保持可讀性，而 `\uXXXX` 提供精確的四位數字替代，代理對代表 U+FFFF 以上的字元。明顯空白位置的診斷通常會標識文字換行符、製表符或其他必須用其文字轉義符替換的控製字元。
計算編碼層數，而不是透過視覺計算斜線。從應用程式應接收的值開始，對 JSON 進行一次編碼，然後才為任何外殼、原始檔案或第二個 JSON 字串引用產生的檔案。驗證呈現給 JSON 解析器的文字，並在正確性很重要時檢查解碼後的字串。