命令列 cookie 轉換器通常是一小段指令碼或 shell 管線，把 Cookie 請求標頭以分號切開並修剪空白；線上 cookie 轉換器則是一個網頁，在你的瀏覽器中或在遠端伺服器上剖析同樣的文字。兩者之間的選擇很少關乎剖析能力；重點在於這個標頭會傳到哪裡、剖析器對RFC 6265 請求序列化規則的執行有多嚴格，以及該工具是默默把格式不正確的輸入正規化，還是直接拒絕。命令列管線可重現、可寫成指令碼，但往往會寬容地接受破損的分隔符、等號前後多餘的空白，並在遇到重複名稱時默默保留最後一個值。線上轉換器則差異很大：有些會把標頭送到後端剖析，有些完全在用戶端執行，只有嚴格的本機工具才會真正拒絕處理不符合請求格式的輸入。對於需要偵錯一段擷取到的 Cookie 標頭、又不想洩漏工作階段機密的開發者來說，最安全的做法是使用一個嚴格的瀏覽器端轉換器，讓它在目前的分頁中執行、驗證每一組名稱值對，且絕不傳送這個值。

cookie converter command line vs online
cookie converter command line vs online

命令列 Cookie 剖析的實際情況

當開發者轉向終端機時，他們很少會安裝專用的 cookie 工具。他們通常把標頭導入 tr、sed、awk，或幾行以 ; 切分、修剪並重組的 Python 程式。一個典型的單行指令看起來像 echo "$COOKIE" | tr ';' '\n' | sed 's/^ //'，它會產生一份 name=value 的快速清單，接著可用 jq 或一小段 Python 呼叫把它轉成 JSON。這種做法快速、在不同機器上都可重現，而且資料留在磁碟上；整個過程都不會碰到任何第三方服務。

這種便利性的代價是寬容。大多數 shell 管線都會接受等號前後有空白的 SID = abc、接受缺少分隔空白的 a=1;b=2，也會接受結尾多一個分號。它們很少檢查名稱是否符合 RFC 6265 的 token 格式，也幾乎從不對重複名稱提出警告。如果兩組名稱值對共用同一個鍵，指令碼通常會保留最後出現的那一個，並默默覆蓋前一個。對於一次性的偵錯片段來說，這通常沒問題。但對於理應忠實描述一段擷取到的請求的剖析器而言，這就是潛在錯誤的來源。

命令列作業也缺少能抓出錯誤的視覺檢視步驟。你看到的只有你印出來的位元組，而不是保留換行與空白的原始行。當你想確認一個 cookie 值中的 %2F 究竟是字面資料，還是被解碼過的斜線，或是 abc== 是否保留了兩個補齊字元時，shell 不會告訴你；它只會把它修剪規則決定出來的結果丟給你。

為什麼大多數線上 cookie 轉換器都不夠好

以網頁為基礎的 cookie 工具有三種類型，其中只有一種真正適合開發者使用。第一種是通用的 JSON 格式化工具，它接受你貼上的任何內容並試著剖析。這類工具會很樂意接受 Cookie: SID=abc;lang=en，並依剖析器的寬容程度，產生錯誤或一個不完整的 JSON 物件。它不理解 Cookie: 這個欄位名稱，也不會強制執行嚴格的 ;（分號加空格）分隔規則。

第二種類型是伺服器端轉換器：你貼上標頭、按一下按鈕，網頁就會把這個值送到後端，再回傳格式化後的 JSON。這是最常見的一種線上工具，也是對即時工作階段資料而言風險最高的一種。Cookie 請求欄位通常包含工作階段權杖、已簽署的 JWT，或 SSO 識別碼。把它送到一台不明伺服器，等於把這些憑證交給任何運行該伺服器的人，而且這個請求還可能被記錄在代理快取、CDN 或分析管線中。現行的 RFC 6265 修訂版 並不會替你解決這個隱私問題；它只是描述這個標頭允許包含什麼內容。

第三種類型是嚴格的用戶端轉換器，整個轉換過程都在 JavaScript 中執行，且絕不上傳輸入內容。對於可能帶有工作階段機密的標頭來說，這是唯一值得使用的線上模式，也是Cookie to JSON Converter 所採用的模式。它同時也是唯一一種能合理地拒絕格式錯誤的分隔符、重複名稱，以及 Set-Cookie 回應屬性、而不是默默把它們改寫掉的工具。

嚴格的瀏覽器端轉換器如何補上這個落差

Cookie to JSON Converter 會把正向（Cookie 轉 JSON）與反向（JSON 轉 Cookie）兩個方向的轉換，完全在你目前的瀏覽器分頁中執行。沒有任何內容會被上傳；輸出區域是唯讀的純文字，需要你手動複製。此剖析器會執行命令列指令碼通常會略過的嚴格 RFC 6265 請求序列化規則：每一組都必須是 name=value 的形式，多組之間必須以剛好一個分號後接一個 ASCII 空格分隔，而選用的欄位名稱前綴必須是 Cookie:，且冒號前不能有空格。

這種嚴格正是重點所在。等號前後的空格、缺漏或重複的分隔空格、結尾的分號，以及空的名稱值對，全部都會被拒絕而不是被正規化，因此你看到的是明確的錯誤，而不是一個容易誤導的 JSON 物件。像 %2F 這樣的百分比序列，會被保留為 percent、二、F 這三個字面字元。每組中的第一個等號才是唯一具結構意義的等號；多出來的等號會留在值裡，這代表像 abc== 這樣的 Base64 補齊字元能在往返過程中完整保留。Cookie 名稱是區分大小寫的，因此 SID 與 sid 仍是兩個不同的鍵。如果你經常處理 Cookie 標頭，這套嚴格規則本身就值得記下來，而嚴格 RFC 6265 名稱值對速查表 一目了然地整理了分隔符、token 字元與拒絕規則。

反向方向沿用相同的規則。JSON 轉 Cookie 只接受剛好一個非空物件，其解碼後的鍵與字串值都必須符合 Cookie 格式規則。它不會對禁用字元做百分比編碼、不會對成員排序，也不會發明像 Secure 或 HttpOnly 這樣的 Set-Cookie 屬性，因為那些是伺服器提供的回應標頭，而不是瀏覽器送出的請求名稱值對。

在本機轉換 Cookie 標頭：逐步說明

  1. 在瀏覽器中開啟 Cookie to JSON Converter。不需要登入、安裝或上傳。
  2. 選擇 Cookie 轉 JSON 的方向，並貼上一個嚴格的裸請求值，例如 SID=abc; lang=en-US。如果你的文字已經以欄位名稱開頭，請完全依照 Cookie: SID=abc; lang=en-US 的格式貼上，冒號要緊接在名稱之後。
  3. 點擊 Convert。此工具只會在每組中的第一個等號處切分，把名稱驗證為 RFC token，把值驗證為 cookie-octet 或以雙引號括起的 cookie-octet，並以區分大小寫的方式拒絕重複名稱。
  4. 在唯讀的輸出區域中閱讀 JSON。結果是一個扁平物件，使用兩個空格縮排，且沒有原型鏈，因此即使你輸入了 __proto__、prototype 或 constructor 這類名稱，它們也不會出現在結果中。
  5. 用 Copy 按鈕複製完整輸出。剪貼簿寫入是非同步的，並針對過時的回應做了防護，因此即使你之後編輯了輸入內容，舊的權限對話框也無法讓「Copied」標記重新出現。
  6. 若要反向操作，切換到 JSON to Cookie，貼上剛好一個非空物件（其中每個值都必須是 JSON 字串），再按 Convert。結果會是使用正向方向所要求的同一種 ;（分號加空格）分隔符所組成的單一標頭值。

如果此工具拒絕了你的輸入，請修正它回報的具體問題——通常是缺少分隔空格、名稱中含有不合法的 token 字元、原始控制位元組、Set-Cookie: 前綴，或重複名稱——然後再試一次。任何錯誤都會清除先前的結果，因此唯讀區域永遠只會顯示最新被接受的轉換結果，或最新的錯誤訊息。

需要事先規劃的限制與邊界情況

此轉換器把輸入上限設定為剛好 100,000 個 UTF-16 碼元，輸出上限為剛好 200,000 個碼元。這些都是精確的上限：第 100,001 個碼元會被拒絕，第 200,001 個碼元也會被拒絕，介面絕不會默默截斷或取樣。如果你的標頭更大，請在貼上前先切分或去除雜訊。輸出長度為零或無效同樣會被拒絕，因此你永遠不會拿到一個被當成成功結果的空 JSON 內容。

Set-Cookie 是你最常會遇到的拒絕情況。Set-Cookie: 帶有 Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite、Partitioned 與 Priority 等回應屬性。瀏覽器在 Cookie 請求欄位中不會回傳任何這些屬性，因此此轉換器無法重建它們，寧可拒絕輸入，也不會產生容易誤導的 JSON。如果你需要檢視 Set-Cookie 屬性，你需要另一個工具。

重複名稱在兩個方向都會被拒絕。JSON 物件天生無法保留兩個解碼後名稱相同的成員，而默默採用「先出現者優先」或「後出現者優先」，會把你原本想看到的重複狀況隱藏起來。正向方向以區分大小寫的方式比對名稱。反向方向會在序列化之前執行一次能感知重複的詞法掃描，因此像 a 與 \u0061 這樣經過跳脫的拼法，即使一般的 JSON.parse 會默默只保留其中一個，這裡也會被辨識為同一個鍵。

與原型相關的三個名稱 __proto__、prototype 與 constructor，在兩個方向都會被封鎖。內部的正向對應表在建立時就不含原型，因此這些鍵無法透過轉換器本身外洩，但在輸入邊界就封鎖它們，也能保護任何把產生出的 JSON 指派到一般物件的下游程式碼。

命令列 vs 線上：快速比較

面向典型 CLI 管線伺服器端線上工具Cookie to JSON Converter（瀏覽器）
標頭傳送到哪裡留在磁碟與 stdout上傳到遠端後端留在目前的瀏覽器分頁中
嚴格分隔符處理通常寬鬆，會修剪空白依實作而異只接受分號加一個空格，其餘一律拒絕
Set-Cookie 輸入常被誤判為請求資料常被誤判為請求資料以明確錯誤拒絕
重複名稱行為默默採用最後一個值默默採用最後一個值以明確錯誤拒絕
原型鍵處理不做驗證不做驗證在輸入邊界封鎖
工作階段機密隱私強，僅限本機弱，取決於後端強，僅限本機
可檢視的輸出只有指令碼印出的內容格式化後的 JSON格式化後的 JSON，外加複製按鈕

這種取捨模式相當一致：命令列管線在隱私上與瀏覽器工具相當，但在嚴格性上落後；伺服器端線上工具在視覺檢視上勝出，卻同時在隱私與嚴格性上都落後；而瀏覽器端轉換器在隱私上與 CLI 相當，同時保有一個線上工具所需要的嚴格規則。

延伸閱讀：13 個可直接複製使用的 Linux 基本指令安全範本。