Header parser：把 HTTP 標頭整理成表格與 JSON
這個 header parser 會把原始的 HTTP 標頭，或電子郵件的標頭區塊，整理成一張排序好、可篩選的表格，每個標頭一列。像 Set-Cookie 這種重複出現的標頭會合併成一列，每個值各自列出，整組結果也能複製成 JSON。它只會整理你貼上的文字，不會查詢、檢查或解碼任何內容。
Header parser 使用步驟
- 複製標頭：可以從瀏覽器開發者工具的 Network 分頁、
curl -i的輸出，或電子郵件原始碼的最上方取得。只貼上標頭那幾行，後面的本文不要貼。 - 貼到原始標頭。輸入框最多可接受 5 MB（5,000,000 個字元）。
- 在解析模式選擇電子郵件 / RFC 5322（預設）或嚴格 HTTP。兩者的差別會在下方說明。
- 按下解析標頭。解析結果畫面會開啟，顯示名稱與值兩欄的表格，依名稱由 A 到 Z 排序，不分大小寫。像 DKIM 簽章這類很長的值，可以在表格內左右捲動。
- 在依名稱或值篩選輸入文字就能縮小列數。下方的數量會從「12 個標頭」變成「12 個標頭中的 3 個」，篩選同樣不分大小寫。
- 按下複製為 JSON，就會把所有已解析的標頭放進剪貼簿。編輯標頭會回到貼上的文字，內容仍然保留，所以你可以修正某一行後再解析一次。
範例：貼上原始標頭，輸出 JSON
範例區塊包含一行回應狀態列（HTTP/1.1 200 OK）、三個一般標頭、兩行 Set-Cookie（其中一行是小寫），以及折到第二行的 Received 標頭。
在預設的「電子郵件 / RFC 5322」模式下，會得到四列。兩個 Cookie 共用一列，折行的 Received 值會接成一行，而狀態列因為冒號前沒有名稱，會被列為略過。「複製為 JSON」的結果如下：
{"Cache-Control": "no-store", "Content-Type": "text/html; charset=utf-8", "Received": "from mail.example.com by mx.example.net; Tue, 1 Oct 2024 09:00:00 +0000", "set-cookie": ["id=a3fWa; Path=/", "theme=dark"]}
合併後的列保留最先出現的寫法 set-cookie，並因為這個標頭出現了兩次而變成陣列。只出現一次的標頭則是一般字串。
嚴格 HTTP 與電子郵件 / RFC 5322：該選哪個模式
兩種模式的差別，只在於遇到以空格或 Tab 開頭的那一行時怎麼處理。
- 電子郵件 / RFC 5322：這一行會用一個空格接到上一行。適合電子郵件標頭，因為 Received、DKIM-Signature 這類很長的值常被折成好幾行。
- 嚴格 HTTP：這一行會被拒絕並列為略過，不會接起來。適合 HTTP 請求與回應，因為縮排的行並不是上一行的延續，你會想看到它被標示出來。
如果不確定，就維持預設。它是兩者中比較寬鬆的。
解析時會略過、合併與保持原樣的內容
- 以第一個冒號切開。冒號前面是名稱，後面是值，所以值裡含有冒號（例如日期或網址）也不會被截斷。
- 略過的行：冒號前沒有名稱的行不是標頭。這包括 HTTP 狀態列（
HTTP/1.1 200 OK）、請求列（GET /index.html HTTP/1.1）和零散的文字。表格上方的提示會統計略過的行數，並顯示前五行。 - 虛擬標頭：以冒號開頭的 HTTP/2 名稱，例如
:authority和:method，會被接受並排在最上面。 - 重複的名稱：比對時不分大小寫。每個值在表格中各自保有一行，依出現順序排列。
- 空值：冒號後面什麼都沒有的標頭，會顯示為「（空白）」。
- 空白行會被忽略，但不會結束標頭。之後只要有一行含有名稱和冒號，即使是電子郵件本文裡的內容，也會變成表格的一列，所以請只複製標頭區塊。
這個工具不做的事
它只整理文字結構，沒有別的功能。它不會追蹤郵件的傳遞路徑，不會驗證 SPF、DKIM 或 DMARC，不會判斷郵件是垃圾信還是正常信件，也不會解碼任何值：像 =?UTF-8?B?…?= 這樣的編碼字詞和 Base64 字串，都會照你貼上的樣子顯示。如果你想從電子郵件讀出寄件者、驗證結果和逐台伺服器的路徑，請改用「電子郵件標頭分析器」。
解析在你的瀏覽器內執行，貼上的標頭不會上傳或儲存。這一點在這裡很重要，因為標頭區塊常含有工作階段 Cookie、API 金鑰和電子郵件地址。
常見問題
在 Chrome 怎麼複製請求標頭？
開啟開發者工具，切到 Network 分頁，然後重新載入頁面。在該請求上按右鍵，從選單選擇複製請求標頭（或回應標頭）的項目。把結果貼到「原始標頭」，再按「解析標頭」。Firefox 的 Network 分頁在請求上也有相同的複製選單。如果使用 curl -i，只貼標頭那幾行，不要貼後面的回應本文。
HTTP 標頭有分大小寫嗎？
名稱不分大小寫：Content-Type、content-type 和 CONTENT-TYPE 是同一個標頭，所以工具會用最先出現的寫法把它們合併成一列。值會照原樣保留，只會去掉前後的空格，因為有些值（例如 Cookie 的值和權杖）是分大小寫的。
同一個回應可以有多個 Set-Cookie 嗎？
可以。回應會為每個 Cookie 各送出一行 Set-Cookie，而 Set-Cookie 正是無法安全地用逗號合併的標頭的典型例子。工具會把每個 Set-Cookie 值各列一行，放在同一列之內，「複製為 JSON」則會把那一列變成陣列。電子郵件中的 Received 標頭也是同樣的重複方式，每經過一台伺服器就一行。
像 :authority 這種 HTTP/2 虛擬標頭是什麼？
虛擬標頭是 HTTP/2 用名稱以冒號開頭的標頭來表示的請求欄位：:method、:scheme、:authority 和 :path，回應中另外還有 :status。:authority 帶有主機名稱，作用就像 HTTP/1.1 的 Host 標頭。工具把開頭的冒號視為名稱的一部分，所以它們會以一般列顯示，並排在其他標頭前面。
怎麼把 HTTP 標頭做成 JSON？
貼上標頭，按「解析標頭」，再按「複製為 JSON」。你會得到一個以標頭名稱為鍵的 JSON 物件。只出現一次的標頭是字串，像 Set-Cookie 這種重複出現的標頭則是依出現順序排列的字串陣列。即使篩選正在隱藏部分列，JSON 仍然包含所有已解析的標頭。
電子郵件標頭該用哪個解析模式？
使用預設的「電子郵件 / RFC 5322」。它會把以空格或 Tab 開頭的行接到上一行，Received 或 DKIM-Signature 這類很長的值就會合成一行。如果是 HTTP 回應，想看到縮排的行被標示出來，請選「嚴格 HTTP」。
把 Cookie 和權杖貼到線上的工具安全嗎？
解析在你的瀏覽器內進行，你貼上的內容不會被上傳或儲存，所以這個頁面不會把標頭區塊裡的 Cookie 和權杖送到任何地方。不過，仍然要把還在使用的工作階段 Cookie 或 Authorization 標頭當成密碼看待：在把標頭或 JSON 分享給別人之前，先替換掉這些值。
