根據使用者名稱和密碼生成 HTTP Basic 認證請求頭，提供可直接貼上的 curl 命令，並支援把已有的 Basic 令牌解碼回憑據。
生成 HTTP Basic 認證請求頭，或把已有的解碼回來。 輸入使用者名稱和密碼，即可得到 Authorization 請求頭、原始 base64 令牌，以及可直接粘進終端的 curl 命令。下方的解碼器可以反向還原已有令牌。
所有計算都在你的瀏覽器中完成，不會傳輸任何資料。即便如此，也請不要把生產環境憑據貼上到任何網頁，包括本頁。
Basic 認證由 RFC 7617 定義，是 HTTP 中最簡單的認證方案。客戶端用冒號把使用者名稱和密碼連線起來，對結果做 base64 編碼，然後放進請求頭：
Authorization: Basic YWxpY2U6czNjcjN0當伺服器需要憑據時，會返回 401 Unauthorized 並帶上 WWW-Authenticate: Basic realm="..."，瀏覽器隨即彈出原生登入框。整個過程沒有握手、沒有隨機數、沒有有效期 —— 每個請求都攜帶同一個請求頭。
這一點必須刻進腦子裡。base64 是一種可逆的傳輸編碼，既沒有金鑰也沒有秘密可言。任何看到這個請求頭的人都能瞬間解出內容，本頁的解碼器做的正是這件事。因此 Basic 認證本身提供的機密性是零，只能在 HTTPS 之上使用，由 TLS 保護整個請求。跑在明文 HTTP 上，它等價於直接傳送明文密碼。
使用者名稱中不能包含冒號，因為第一個冒號就是分隔符。密碼裡想有多少冒號都可以 —— 解碼器只在第一個冒號處切分，其餘全部算作密碼。如果你的使用者名稱確實需要冒號，那麼 Basic 認證不可用，得換方案。
最初的規範對 ASCII 之外的字元語焉不詳，歷史上導致非 ASCII 密碼在客戶端與服務端之間頻繁出錯。RFC 7617 增加了 charset="UTF-8" 引數，讓伺服器可以宣告自己的預期；實踐中現代技術棧一律使用 UTF-8。本工具在 base64 之前先編碼為 UTF-8 位元組，與當前瀏覽器行為一致。
Basic 認證在這些場合依然合理：內網中的機器對機器呼叫；用 nginx 或 Apache 快速給預釋出環境加一道門；需要簡單憑據的 CI 任務；以及作為 API Key 的載體 —— 把 key 放進使用者名稱欄位，密碼留空或填一個佔位符如 x。多家支付和郵件 API 用的正是這種模式。
它不適合公開站點的終端使用者登入：沒有登出機制，瀏覽器會在會話期內快取憑據，彈框無法定製樣式，也沒法加多因素認證或按會話限流。這類場景應改用令牌或會話方案。
寫在 URL 裡的憑據 —— user:pass@example.com —— 已被廢棄，多數瀏覽器會攔截或剝離，因為它會洩漏進歷史記錄、日誌和 referrer 頭。給 curl 傳 -u user:pass 同樣會把密碼寫進 shell 歷史和程序列表，機器上的其他使用者能直接看到；更好的做法是隻寫 -u user 讓 curl 提示輸入，或者從環境變數讀取。