一份 Cookie 轉換器的速查表，把 HTTP Cookie 請求標頭嚴格的序列化規則濃縮成一份在除錯工作階段、檢視日誌、或將真實 cookie 字串移轉成 JSON 以供工具使用時可快速掃讀的參考。這份速查表之所以有效，是因為 Cookie 請求格式已被完整定義:以 name=value 撰寫配對，多組配對之間以恰好一個分號加一個 ASCII 空白分隔，名稱採用 RFC token 規範。一個嚴格的本地轉換器會強制執行這些界線，而不是悄悄地把格式錯誤的輸入標準化，這也使它成為速查表的理想形狀 —— 每一列都代表一個被接受或被拒絕的輸入。下方各列涵蓋裸 Cookie 值、選用的 Cookie: 前綴、空白規則、百分號序列、base64 風格的填補、引號包裹的值、空值，以及原型風險的鍵。當你需要確認某個特定輸入的精確行為時，可將 Cookie to JSON 轉換器 與本速查表搭配使用。
Cookie 請求格式速查表
一個嚴格的 Cookie-to-JSON 轉換器會在每次貼上時檢查四個層次:選用的欄位名稱前綴、配對層級的分隔符、名稱與值的語法，以及重複鍵規則。下表列出開發者最常貼上的模式、嚴格轉換器回傳的判定，以及每個判定背後的規則，讓你在提交輸入之前就能預測結果。
| 輸入片段 | 判定 | 原因 |
|---|---|---|
| SID=abc; lang=en-US | Accepted | 裸 Cookie 請求值，兩組配對，精確的 `; ` 分隔符 |
| Cookie: SID=abc; lang=en-US | Accepted | 精確的 Cookie: 前綴，配對符合嚴格序列化 |
| COOKIE:SID=abc | Accepted | 欄位名稱比對不區分大小寫 |
| Cookie : SID=abc | Rejected | 名稱與冒號之間的空白屬於格式錯誤 |
| SID=abc; lang=en-US | Accepted | 整行周圍的外部 ASCII 空白會被忽略 |
| SID = abc; lang=en | Rejected | 結構等號周圍的邊界空白不會被標準化 |
| SID=abc;; lang=en | Rejected | 分隔符之間出現空配對屬於無效 |
| SID=abc;lang=en | Rejected | 分號分隔符之後缺少一個空白 |
| SID=abc; lang=en | Rejected | 分隔符之後出現兩個空白不會被標準化 |
| SID=abc; | Rejected | 結尾的分號後面沒有接續的配對 |
| =abc | Rejected | 空名稱不符合 RFC token 規範 |
| SID | Rejected | 配對缺少結構等號 |
| SID=abc; SID=def | Rejected | 重複的名稱採用區分大小寫的比較 |
| Set-Cookie: SID=abc; lang=en | Rejected | 回應標頭不是 Cookie 請求欄位 |
| __proto__=x; a=1 | Rejected | 原型風險鍵在兩個方向上都會被阻擋 |
| constructor=x; a=1 | Rejected | 原型風險鍵在兩個方向上都會被阻擋 |
| token=%2Fpath; a=1 | Accepted | 百分號序列按字面保留，保留三個字元 |
| sig=abc==; a=1 | Accepted | 結構等號之後多出的等號仍視為值資料 |
| pref=; a=1 | Accepted | 空值屬於有效的 Cookie 配對 |
| pref="quoted"; a=1 | Accepted | DQUOTE 包覆的值，前後引號會被保留 |
兩個方向共用同一套界線檢查。JSON-to-Cookie 會驗證輸入可解析為恰好一個非空 JSON 物件，接著對每個解碼後的鍵套用相同的 RFC token 規則，並對每個解碼後的值套用相同的 cookie-value 規則。JSON 跳脫字元會在 Cookie 驗證之前先解碼，因此任何解析為禁用字元的字面跳脫都會被拒絕 —— 例如一個跳脫後的換行會失敗，因為解碼後的控制字元並非合法的 cookie-value 資料。重複的解碼鍵會在任何序列化開始之前被偵測出來，因此像 a 和 \u0061 這種跳脫後拼法會被視為相同的鍵，即便一般 JSON.parse 只會悄悄保留其中一個。
三步驟轉換 Cookie 標頭
嚴格轉換器只會在當前的瀏覽器分頁內執行。輸出為唯讀區域中的純文字，不會傳送至 Lizely 或任何外部服務。可用於除錯 Cookie 請求欄位、將審核過的字串對應移轉成 JSON，或從審核過的 JSON 字串產生請求標頭值。
- 選擇 Cookie to JSON 方向，並貼上嚴格的裸 Cookie 請求值，例如 SID=abc; lang=en-US，或加上精確的 Cookie: 欄位名稱前綴。欄位名稱比對不區分大小寫(因此 COOKIE: 也可使用)，但 Cookie : 在冒號前帶有空白屬於格式錯誤，會被拒絕。整行周圍的外部 ASCII 空白會被移除以利使用。
- 或切換至 JSON to Cookie 方向，提供恰好一個非空 JSON 物件，其解碼後的鍵為 RFC token，且解碼後的值為 JSON 字串。數字、布林值、null、陣列、巢狀物件、註解、尾端逗號，以及右大括號之後的任何文字都會被拒絕。跨跳脫的解碼重複項目，包括 a 和 \u0061，會在 join 步驟執行前失敗。
- 轉換後，檢視每一個保留的字串與配對數，然後複製完整的本地輸出。剪貼簿寫入是非同步的，每次複製嘗試都帶有世代識別碼，因此較舊的權限回應無法在編輯、重試或切換方向後恢復「已複製」狀態。剪貼簿遭拒時，完整輸出仍會保持可見以便手動選取，而不是回報一個假的成功。
JSON-to-Cookie:反向方向規則
反向方向以相反順序遵循相同的 Cookie 規範。被接受的配對會以精確的分隔符 `; ` (分號後接一個 ASCII 空白)進行串接，解碼後的鍵會重新驗證為 RFC token，解碼後的值會重新驗證為可接受的 cookie-value。轉換器不會對禁用字元進行百分號編碼、不會自動加上引號、不會移除輸入原本帶有的引號、不會排序成員、不會推論路徑，也不會產生任何 Set-Cookie 屬性。成員順序會依詞彙配對掃描保留以便輸出使用，但 Cookie 語意不應依賴序列化順序 —— 伺服器可以使用此轉換器所不知道的應用程式專屬規則來解讀 cookie 值。
兩個方向都會在序列化之前阻擋 __proto__、prototype 與 constructor 這些原型風險鍵。正向方向使用一個 null 原型的內部對應，搭配兩個空格的 JSON 縮排，因此那些名稱永遠不會成為輸出物件上的自身屬性。反向方向會在 join 步驟之前拒絕它們，因此輸出的 Cookie 值絕不會以配對形式帶有它們。即使 JSON 文字能夠表示這些字串，且內部正向對應沒有原型，仍然會發生拒絕 —— 這道界線是用來防止下游程式碼把產生的輸出當成安全的指派來源。本工具並未聲稱任意下游 JSON 處理是安全的，消費者仍必須安全地解析與合併未受信任的資料。
為何 Set-Cookie 輸入會被拒絕
本轉換器僅處理 Cookie 請求標頭。它不會解析 Set-Cookie 回應標頭，也不會把 Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite、Partitioned、Priority 或任何其他擴充屬性視為請求 cookie。這些屬性是由伺服器在 Set-Cookie 中提供，瀏覽器不會在 Cookie 請求欄位中將其回傳。因此，Cookie 標頭無法揭露 cookie 的到期時間、允許的主機、允許的路徑、僅限安全連線狀態，或 HttpOnly 狀態。貼上精確的 Set-Cookie: 前綴會產生明確的錯誤，而不是誤導性的 JSON;沒有值的裸名稱(例如 HttpOnly)會因為缺少結構等號而以配對形式失敗;而語法上有效的 name=value 配對(例如 Path=/ 或 Domain=example.com)則會因為轉換器並未對屬性名稱特別處理，而被當作一般的 Cookie 請求配對接受。
本轉換器強制執行的嚴格剖析規範來自 RFC 6265，即 HTTP 狀態管理機制，當中定義了 cookie 名稱 token 規範、cookie-octet 值規範，以及請求序列化格式。後續的 draft-ietf-httpbis-rfc6265bis 在同一道界線周邊精煉了這些定義，上方速查表的各列追蹤的正是該界線，而非任何瀏覽器專屬的標準化方式。
限制與轉換器不會做的事
輸入上限為恰好 100,000 個 UTF-16 碼位，完整輸出上限為 200,000 個碼位。恰好等於上限會被接受，超過一個單位則會被拒絕，因此界線是可預期的。介面並未使用 maxLength 來悄悄阻擋輸入，轉換過程也絕不會切片、截斷、取樣、略過，或部分回傳輸入。長度為零或無效的輸出長度會被拒絕，因此空白的轉換絕不會顯示為成功。任何錯誤都會在發布訊息之前先移除前一次的成功結果，編輯輸入或切換方向會清除先前的輸出、錯誤橫幅、配對數、剪貼簿狀態與剪貼簿計時器。
| 工作或問題 | 本工具是否處理 |
|---|---|
| 將嚴格的 Cookie 請求標頭剖析成扁平 JSON 字串對應 | Yes |
| 從扁平的 JSON 字串物件產生嚴格的 Cookie 請求標頭值 | Yes |
| 剖析 Set-Cookie 回應標頭或還原其屬性 | No —— 那些屬性不在請求欄位中 |
| 進行 URL 解碼、百分號解碼，或以其他方式解讀百分號序列 | No —— 三個字面字元會被原樣保留 |
| 揭露 cookie 是否為 Secure、HttpOnly 或僅限工作階段 | No —— 請求欄位並未帶有此類訊號 |
| 悄悄標準化格式錯誤的分隔符空白或加引號的配對 | No —— 以嚴格拒絕取代標準化 |
| 讀取 document.cookie 或修改瀏覽器的 cookie 存放區 | No —— 除了貼上的文字之外，不會讀寫任何內容 |
| 將貼上的文字傳出裝置 | No —— 兩個方向都完全在當前分頁內執行 |
| 在分享前作為憑證清理工具 | No —— 應將貼上的文字視為已屬敏感 |
若要在嚴格 Cookie 規範之外處理一般 JSON 工作，JSON Formatter 與 JSON Validator 涵蓋可讀格式與精確的錯誤位置，JSON Minifier 則在不引入 cookie 規則表面的情況下產生嚴格的精簡形式。
處理即時 Cookie 的安全注意事項
Cookie 標頭通常包含即時的工作階段密鑰。請僅貼上您打算處理的內容，將複製的輸出視為機密資料，並輪換任何已透過螢幕擷圖、記錄檔或共用輸出而外洩的憑證。轉換器會非同步地將資料寫入剪貼簿，且每次複製嘗試都會收到一個世代識別碼，由掛載狀態守衛強制執行，因此舊提示的權限回應無法在編輯、方向變更、重試或卸載後還原「已複製」狀態。剪貼簿遭拒時，完整輸出仍會保持可見以供手動選取，而不會回報偽成功;複製是此頁面唯一與網路相關的副作用 — 並沒有 fetch、XHR、WebSocket 或 postMessage 呼叫。
編輯輸入內容或切換方向會清除先前的輸出、錯誤橫幅、配對計數、剪貼簿狀態與剪貼簿計時器，因此陳舊的結果不會被誤認為是新的轉換結果。轉換器不會從 document.cookie 讀取任何內容，絕不會修改瀏覽器的 Cookie 存放區，也絕不會發出 HTTP 請求。請將其用於偵錯 Cookie 請求欄位、將已審核的字串對應轉為 JSON，或從已審核的 JSON 字串產生請求標頭值;請勿用於檢查瀏覽器儲存空間、建立 Set-Cookie 回應、保留屬性、解碼應用程式的工作階段格式、判斷 Cookie 是否安全，或在共用前清理憑證。
如需更深入的說明，請參閱 Excel 公式速查表：常用公式的替代方案。
如需更深入的說明，請參閱 ASCII 速查表：4 種標記法中的全部 128 個代碼。