Cookie 轉換器是一種工具，可將 HTTP Cookie 請求標頭的文字內容轉換為結構化格式(通常是 name 與 value 配對的 JSON 物件對應)，並將該對應轉回有效的標頭合規字串。與通用解析器不同，嚴格的 Cookie 轉換器會強制執行 RFC 6265 中的請求序列化規則:每一對都必須是 name=value，多對之間必須以一個分號加一個 ASCII 空白分隔，而每一對中第一個等號是唯一的結構分隔符。百分比序列、額外的等號以及帶引號的值都會以原樣保留，而不會進行解讀。真正的 Cookie 轉換器也會拒絕解析 Set-Cookie 回應標頭，因為 Domain、Path、Expires、Secure 和 HttpOnly 等屬性是由伺服器送出，絕不會出現在瀏覽器的請求欄位中。這一個差異，正是能協助你除錯連線工作區流量的工具，以及悄悄捏造不存在資料的工具之間的分界。
Cookie 轉換器實際在做什麼
Cookie 轉換器只處理一個特定欄位:瀏覽器傳送給伺服器的 HTTP Cookie 請求標頭值。它的任務是將該扁平的 name=value 配對字串，轉換成結構化表示方式——最常見的是 JSON 物件，其中每個 Cookie 名稱變成一個鍵，每個值變成一個字串。反向操作則接收扁平的字串 JSON 物件，輸出請求會攜帶的精確標頭文字。
當你在瀏覽器的網路分頁中檢查請求時，可以把 Cookie 值以純文字複製出來。該段文字不易閱讀、難以差異比對，也無法正確嘗試查詢。Cookie 轉 JSON轉換器 會讀取該欄位，根據 RFC 6265 的請求序列化規範進行驗證，並產生以兩個空白縮排的 JSON 物件，讓你可以閱讀或貼到其他程式碼中。反向操作在你從審查結果重建請求時很有用:拿審查過的 JSON 字串，重建伺服器會接受的標頭。若要對雙向轉換有更廣泛的說明，請參考 在瀏覽器中將 Cookie 標頭與 JSON 互轉 指南。
為什麼請求 Cookie 與 Set-Cookie 並不相同
這是最常見的混淆點，也是許多通用 Cookie 工具出錯的地方。
Cookie 請求標頭只包含瀏覽器送出的內容:一組或多組 name=value 配對，用於識別哪些 Cookie 適用於目前的請求。它不包含關於效期、範圍或安全性旗標的中繼資料，因為這些旗標是由伺服器在建立 Cookie 時設定，不會在後續請求中送回伺服器。
Set-Cookie 回應標頭則相反。它是伺服器傳送給瀏覽器用以建立或修改 Cookie 的內容，可包含 Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite、Partitioned、Priority 等屬性及延伸鍵。這些屬性會影響未來的 Cookie 請求，但它們不屬於任何 Cookie 請求欄位的一部分。
| 面向 | Cookie 請求標頭 | Set-Cookie 回應標頭 |
|---|---|---|
| 方向 | 瀏覽器 → 伺服器 | 伺服器 → 瀏覽器 |
| 是否攜帶 Domain、Path、Secure、HttpOnly 等屬性 | 否 | 是 |
| 格式 | 由 ; 串接的 name=value 配對 | name=value 加上屬性 |
| 是否由請求 Cookie 轉換器處理 | 是 | 否(明確錯誤) |
嚴謹的 Cookie 轉換器只處理 Cookie。貼上以 Set-Cookie: 開頭的一行會產生明確錯誤，而不是捏造一個假裝這些屬性存在於請求欄位的 JSON 物件。這項差異能保護你免於使用虛構資料進行除錯。
真正 Cookie 轉換器背後的嚴格解析規則
RFC 6265 定義了一套雖小但精確的序列化規範。遵守它的轉換器會檢查以下所有規則，詳細內容記載於 RFC 6265 — HTTP 狀態管理機制。
選用的欄位名稱若要包含，必須是完全相同的字串 Cookie，後面緊接著冒號。Cookie : 在冒號前有空白屬於格式錯誤。欄位名稱本身以不區分大小寫的方式比對，因此 COOKIE:a=1 可被接受。
每一對必須是一個名稱、一個等號和一個值，等號兩側不可有空白。等號只有在對中首次出現時才作為分隔符。像 abc==、簽署權杖或含有 = 字元的網址這類值，第一個等號之後的每個等號都視為資料。
配對之間必須以一個分號加一個 ASCII 空白分隔。兩個空白、沒有空白或結尾的分號會被拒絕，而不會悄悄修復。
名稱遵循 RFC token 規範且區分大小寫。SID 與 sid 是兩個不同的名稱。值遵循 cookie-octet 規範，或以雙引號包住相同的字元;原始空白、逗號、分號、反斜線、控制字元以及該規範以外的字元都會被拒絕。
百分比序列絕不會進行網址解碼。%2F 會保留為 percent、2、F 三個字元。JSON 跳脫會在 Cookie 驗證之前先解碼，因此 JSON 值中的跳脫換行會失敗，因為解碼後的控制字元不是有效的 cookie-value 資料。
重複的名稱會被拒絕，而非採用先出現者勝出或後出現者勝出的策略，因為 JSON 無法在不解碼的情況下保留兩個同名的成員。名稱 __proto__、prototype 與 constructor 會被拒絕，作為防範下游程式發生原型污染的縱深防禦界線，即使內部對應沒有原型。
輸入上限為 100,000 個 UTF-16 程式碼單位，輸出上限為 200,000 個。介面絕不會悄悄截斷;超過上限的下一個單位會被拒絕。
如何在瀏覽器中將 Cookie 標頭轉換為 JSON
Cookie 轉 JSON轉換器 圍繞這些規則建構，並完全在瀏覽器分頁中執行，因此你貼上的內容不會被上傳。
- 開啟 Cookie 轉 JSON轉換器，選擇 Cookie 轉 JSON 方向。
- 貼上裸的 Cookie 請求值(如 SID=abc; lang=en-US)，或精確帶前綴的形式 Cookie: SID=abc; lang=en-US。貼上內容外圍的 ASCII 空白會被忽略以方便使用。
- 轉換。輸出會以唯讀區域顯示，為以兩個空白縮排的 JSON 物件，每個保留字串與配對數量都清晰可見。
- 當你需要重建標頭時，切換到 JSON 轉 Cookie。貼上一個非空且所有值皆為字串的 JSON 物件，然後轉換。
- 使用內建按鈕複製完整輸出。若剪貼簿權限被拒絕，完整輸出仍會保持可見，供手動選取。
每次編輯或方向切換都會清除先前的結果、錯誤、配對數量與剪貼簿狀態。本工具不會嘗試存取 document.cookie，不會修改瀏覽器 Cookie 存放區，也不會發出 HTTP 請求。
嚴格 Cookie 轉換器會拒絕什麼，以及原因
嚴格轉換器的嚴格有其理由。以下輸入都會失敗，而不是產生誤導的結果:
| 輸入形式 | 結果 |
|---|---|
| SID=abc; lang=en-US | 接受 |
| Cookie: SID=abc | 接受 |
| COOKIE:a=1 | 接受 |
| a = b | 拒絕(等號兩側有空白) |
| a=b;c=d | 拒絕(缺少分隔空白) |
| a=b; c=d; | 拒絕(結尾的分號) |
| Set-Cookie: SID=abc; Path=/ | 拒絕(回應標頭) |
| JSON 模式下的 {"a": 1} | 拒絕(非字串值) |
嚴格的 Cookie 轉換器也會拒絕:含有空白、分隔符或控制字元的名稱;含有原始空白、逗號、分號、反斜線、控制字元或 cookie-octet 以外字元的值;任一方向上區分大小寫比較後的重複名稱;不是單一非空物件、或含有數字、布林值、null、陣列、巢狀物件、清空、尾端逗號或物件後文字的 JSON 輸入;解碼後不是有效 cookie-value 資料的跳脫字元，例如跳脫換行;以及 __proto__、prototype 與 constructor 這幾個鍵，即使其餘輸入是有效的。
隱私、限制，以及何時該使用其他工具
由於 Cookie 欄位經常承載使用中的工作階段識別符、簽署權杖與身分驗證狀態，請將貼上的文字視為隱私資料。在受信任的瀏覽器分頁中執行轉換器，避免將真實的正式環境 Cookie 貼到共用螢幕截圖中，並輪換任何已曝光的憑證。
Cookie 轉換器並不會嘗試成為工作階段解碼器。它不會推斷路徑、不會排序成員、不會對禁用字元進行百分比編碼、不會新增或去除引號，也不會產生 Set-Cookie 屬性。它也不會判斷 Cookie 是否安全——只有伺服器原始的 Set-Cookie 屬性能告訴你，而 Cookie 請求欄位無法提供此資訊。
針對一般 JSON 處理——格式化、驗證或壓縮無關的 JSON——專門的 JSON 處理工具更為合用。針對無關的標記清理，HTML 清理工具更為合適。了解哪個工具負責什麼，才能讓每次除錯工作保持誠實。