本機 Cookie 轉換器可以將嚴格的 HTTP Cookie 請求標頭轉換成扁平 JSON 字串對應表，也能將經審閱的 JSON 字串物件轉換回 Cookie 請求標頭值。Cookie to JSON Converter 會在目前的瀏覽器分頁中處理兩個方向的轉換，因此貼上的標頭或 JSON 資料絕不會傳送給 Lizely 或其他服務。它不會從 document.cookie 讀取 Cookie，也不會變更瀏覽器的 Cookie 儲存區，且不會發出任何 HTTP 請求。此轉換器刻意採取嚴格模式，而非作為清理工具：它要求 name=value 形式的請求配對，使用完全一致的「分號加一個空格」分隔符，保留值中的字面百分比序列與額外的等號，並拒絕模稜兩可或不安全的輸入，而不是在未告知的情況下將其標準化。因此，它適合用於偵錯擷取到的 Cookie 欄位、將經審閱的字串對應表移至 JSON，或從經審閱的 JSON 字串產生請求標頭值。它不會轉換 Set-Cookie 回應標頭、重建回應屬性、解碼應用程式的工作階段格式，也不會判斷 Cookie 是否為安全 Cookie。請將它用於請求標頭本身的轉換，審閱完整輸出，並妥善保護任何有效的憑證。
選擇符合您輸入內容的轉換方向
依照您已有的資料選擇轉換模式。不同模式具有不同的輸入限制，因此從正確的模式開始，可避免將 JSON 物件與序列化的 Cookie 欄位混淆。
| 起始輸入 | 模式 | 結果 |
|---|---|---|
| 不含其他內容的 Cookie 請求值，或完全一致的 Cookie: 前置字串 | Cookie to JSON | 屬性值皆為字串的扁平 JSON 物件 |
| 單一非空的扁平 JSON 物件 | JSON to Cookie | 由 name=value 配對組成的 Cookie 請求標頭值 |
兩個方向都會在唯讀輸出區域中產生純文字。Cookie-to-JSON 的結果採用兩個空格的 JSON 縮排，反向轉換則使用完全相同的「分號加一個空格」分隔符來連接接受的配對。
將 Cookie 請求標頭轉換為 JSON
- 開啟轉換器並選擇 Cookie to JSON。 當您持有 HTTP Cookie 請求標頭的值時，請使用此模式。
- 貼上嚴格的請求值。 可接受 SID=abc; lang=en-US 這類不含其他內容的值。您也可以包含完全一致的 Cookie: 欄位名稱前置字串，且後方緊接著值。不要貼上 Set-Cookie 回應標頭。
- 選擇 Convert。 轉換器會先驗證整份輸入，再發布結果。接受的配對會成為扁平 JSON 物件中的字串屬性。
- 審閱每個保留的字串與所報告的配對數量。 確認名稱和值與請求欄位相符，然後複製完整輸出。如果拒絕剪貼簿權限，完整結果仍會顯示，供您手動選取。
Cookie 輸入： SID=abc; lang=en-US
等效的 JSON 對應表： { "SID": "abc", "lang": "en-US" }
為了方便使用，貼上內容最外側的 ASCII 空格會被忽略。選用的欄位名稱本身不區分大小寫，因此可接受 COOKIE:a=1，但冒號必須緊接在 Cookie 之後。Cookie : 這類格式則有誤。
將扁平 JSON 字串對應表轉換為 Cookie 值
選擇 JSON to Cookie，並提供恰好一個非空 JSON 物件。每個屬性值都必須是 JSON 字串。解碼 JSON 字串逸出字元後，轉換器會依照正向轉換所使用的相同 Cookie 設定驗證每個解碼後的名稱與值。
JSON 輸入： { "SID": "abc", "lang": "en-US" }
等效的 Cookie 值： SID=abc; lang=en-US
- 數字、布林值、null、陣列、巢狀物件、註解、尾端逗號，以及物件後的文字都會被拒絕。
- 逸出的換行會在驗證前解碼，因此會以控制字元的形式導致失敗，而不是隱藏在 JSON 文字中。
- 重複的解碼後屬性名稱會在序列化前導致失敗，而不是選擇第一個或最後一個作為勝出者。
- 轉換器不會對禁止的字元進行百分比編碼、新增或移除引號、排序成員、推斷路徑，或產生 Set-Cookie 屬性。
為了輸出方便，JSON 成員的順序會保留，但 Cookie 語義不應依賴序列化順序。伺服器也可能依照轉換器無法得知的應用程式專屬規則解讀 Cookie 值。
防止無聲變更的驗證規則
嚴格的驗證邊界在偵錯請求時很有用，因為它能區分有效的序列化內容，以及需要靠猜測才能修正的文字。
| 輸入情境 | 轉換器行為 |
|---|---|
| SID=abc; lang=en-US | 接受為兩個配對，並使用規定的分隔空格。 |
| SID=abc;lang=en-US | 拒絕，因為缺少分號後必要的 ASCII 空格。 |
| SID = abc | 拒絕，因為不會將等號周圍的空格標準化。 |
| SID=abc; | 拒絕，因為尾端分號會產生空白配對。 |
| preference= | 接受，因為空白的 Cookie 值是有效的。 |
| token=abc== | 接受，因為只有第一個等號會分隔名稱與值。 |
| a=1; a=2 | 拒絕，因為 JSON 物件無法保留重複名稱。 |
| Set-Cookie: a=1 | 明確回報錯誤並拒絕，因為回應標頭不在處理範圍內。 |
| __proto__=x | 拒絕，因為會封鎖有原型風險的名稱。 |
名稱與值會分別檢查
Cookie 名稱必須符合 RFC token 設定，且區分大小寫，因此 SID 和 sid 是不同的名稱。空白名稱或缺少等號的配對都會導致失敗。值必須是未加引號且由允許的 Cookie 八位元組組成的序列，或是將同一序列包在雙引號中。原始空格、逗號、分號、反斜線、控制字元，以及不符合 Cookie 八位元組設定的字元都會被拒絕。接受加引號的值時，會保留其外圍的引號字元，因為它們是序列化 Cookie 欄位值的一部分。百分比序列會保持原樣：%2F 會保留為 percent、2 和 F，而不會變成解碼後的斜線。
重複鍵與有原型風險的鍵會導致失敗
重複比對會區分大小寫，但比對也會在 JSON 逸出字元解碼後進行。因此，在一般 JSON 解析可能只保留其中一個項目之前，JSON-to-Cookie 掃描就能偵測出 a 和 \u0061 等等效拼寫。名稱 __proto__、prototype 和 constructor 在兩個方向中都被封鎖。Cookie-to-JSON 使用 null-prototype 的內部對應表，但這並不會使任意下游 JSON 指派變得安全；使用者仍須謹慎解析及合併不可信資料。
Cookie 請求欄位並非 Set-Cookie 回應
Cookie 請求標頭包含瀏覽器傳送的 name=value 配對。它不包含 Set-Cookie 中常見的回應屬性，例如 Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite、Partitioned、Priority 或擴充屬性。這些屬性是由伺服器在回應中提供，瀏覽器不會在 Cookie 請求欄位中傳回。
這種請求／回應的區分方式在 RFC 6265 和 IETF HTTPbis Cookie 規格中有說明。因此，Cookie 標頭無法顯示 Cookie 的到期時間、允許的主機、允許的路徑、僅限安全狀態或 HttpOnly 狀態。貼上完全一致的 Set-Cookie: 前置字串時，會明確回報錯誤，而不會產生誤導性的 JSON。
保護機密並檢查邊界
- 處理作業會留在瀏覽器中。 兩個轉換方向都會在目前的瀏覽器分頁中執行，不會向 Lizely 或其他轉換服務發出請求。
- 輸入邊界明確。 輸入最多可包含恰好 100,000 個 UTF-16 程式碼單位；該大小會被接受，但再多一個單位就會被拒絕。介面不會使用 maxLength 在未告知的情況下停止輸入。
- 必須產生完整輸出。 輸出限制為恰好 200,000 個 UTF-16 程式碼單位，剛好達到上限時會被接受，但再多一個單位就會被拒絕。轉換作業絕不會切片、設上限、取樣、略過或只傳回部分輸入，零長度或無效的輸出長度也會被拒絕。
- 會清除過時的結果。 發生錯誤時會移除先前成功的結果。編輯輸入或變更方向時，會清除輸出、錯誤、配對數量和剪貼簿狀態。
- 仍可使用剪貼簿備援方式。 複製是非同步作業，但權限遭拒時不會隱藏已完成輸出；您可以手動選取。
- Cookie 欄位經常包含有效的機密。 請保護轉換後的標頭，並輪替已公開的憑證。本機處理可避免上傳，但無法消除工作階段 Cookie 的敏感性。
在請求、偵錯筆記或交接文件中使用結果之前，請將所報告的配對數量與可見配對進行比對，並驗證每個值。當來源包含工作階段識別碼、簽署權杖、URL 或類似 Base64 的填補字元時，最後這項檢查尤其重要。