開發者工具 · Base64 編碼器和解碼器
為什麼貼上的 Base64 無法解碼：換行、換行和智慧引號
· 為什麼它很重要
base64 編碼
Base64 在運輸過程中很少中斷；它在剪貼簿中破裂。這篇文章對產生無效字元和長度錯誤的複製貼上錯誤進行了分類，以及如何快速發現每一個錯誤。
在終端中有效但在瀏覽器中失敗的密鑰 - 一個不可見的字元和兩個小時的搜索
工程師從終端複製 API 金鑰以在腳本中進行測試。此金鑰在終端機中運作正常，但在貼上到瀏覽器工具時因無效字元而失敗。兩個小時後，在搜尋程式碼、配置和檔案後，他們發現了一個看不見的字元。鍵末尾的換行符（透過 echo 新增或從終端提示行複製）成為破壞 Base64 解碼器的額外字元。鑰匙是正確的；剪貼簿不是。 Base64 資料在以電子方式傳輸、校驗和驗證時是可靠的。它幾乎只在手動複製和貼上過程中中斷。
終端中的換行、命令輸出中的尾隨換行符、富文字編輯器中的智慧引號替換以及不同應用程式之間複製貼上的隱藏 Unicode 字元都會引入錯誤，這些錯誤看起來像是 Base64 已損壞，而實際問題在於其複製方式。這篇文章列出了最常見的故障，並展示瞭如何快速發現和修復每個故障。 Base64 字母表由大小寫字母、數字、加號、斜線和填充字元（等號）組成。 RFC 4648 是特定的：標準 Base64 字串僅包含這些字元以及可選的空格（如果換行）。
來自終端、電子郵件用戶端和 PEM 格式的換行 - 為什麼 76 列中斷對於某些解碼器來說很好，而對於其他解碼器來說卻是致命的
許多工具可以容忍偏差：它們接受使用破折號和底線而不是加號和斜杠的 URL 安全變體，或者忽略換行符。遵循 RFC 的嚴格解碼器會拒絕任何超出預期字元集的內容，並因無效字元錯誤而失敗。錯誤訊息通常會指出有問題的字元或指出該字串根本無法解碼。當從電子郵件、終端機、聊天歷史記錄或格式化檔案貼上 Base64 時，不可見字元或字元替換經常會出現並導致解碼失敗。資料本身沒問題；剪貼簿傳輸損壞了它。
換行是貼上 Base64 失敗的最常見原因，也是最容易修復的原因。終端工具將輸出換行為每行 76 個字符，有時為 80 個字符，插入換行符並繼續下一行。許多編碼器（包括一些 Base64 編碼庫）將其輸出包裝在相同的 76 字元邊界處，以與 MIME 電子郵件相容。當您從終端複製包裝的 Base64 字串時，換行符號就會出現。
來自 echo 和剪貼簿工具的尾隨換行符 - 成為額外字元的額外位元組
一些解碼器會自動接受和忽略換行符。其他人則將它們視為無效字元而拒絕。修復方法是刪除所有換行符和空格。如果 Base64 字串在終端機中跨多行換行，請選擇所有行，將它們複製到編輯器中並刪除所有換行符。
複製產生的單行字串並將其貼上到解碼器中。這是貼上失敗時要嘗試的第一件事。來自 echo 和剪貼簿實用程式的尾隨換行符是另一個常見的罪魁禍首。命令 echo $API_KEY 列印密鑰，後面跟著換行符，這是命令標準行為。如果直接複製該輸出，換行符號將包含在副本中。某些終端機在複製時會增加額外的換行符，而某些剪貼簿管理器會保留或複製換行符。症狀與換行相同：字串末尾出現不屬於 Base64 的額外字元。
智慧引號、不間斷空格和零寬度字元 — 富文字編輯器如何重寫純文字
修復方法同樣簡單：在嘗試解碼之前修剪編輯器中貼上字串的末端。刪除前導和尾隨空格以及任何看起來像換行符的字元。如果字串夠短，您可以再次手動輸入，但對於長鍵，仔細的手動修剪會更快。智慧引號、不間斷空格和其他 Unicode 替換都是微妙的陷阱。 Word 等富文本編輯器會自動將直引號轉換為彎引號，將三個連字號轉換為長破折號，並將某些空格序列轉換為不間斷空格。如果有人將 Base64 字串貼到文件中，然後您將其從格式化文件複製到工具中，這些替換就會隨之而來。
直双引号 (") 變成一對左右卷曲，两者都不是有效的 Base64。不間斷空格 (U+00A0) 看起來與常规空格相同，但具有不同的字符代碼，並不會被所有解析器識別為空格。解决方案是首先粘贴到纯文字編輯器中，该編輯器會丢弃所有格式。如果從 Word 文件或格式化聊天中粘贴，请首先粘贴到纯文字編輯器或 HTML文字區域中，然後檢查對於奇數字符，然後從純文字版本複製以在您的工具中使用。
截斷和填充損失 — 長度模 4 檢查告訴您字元遺失
當複製或貼上過程中字串被截斷時，就會發生截斷。非常長的 Base64 字串可能會超出某些系統上的剪貼簿限制，或者由於應用程式錯誤而無法複製。結果是一個較短且不完整的字串。套用填滿後，Base64 字串的長度必須是四的倍數。如果長度不是四的倍數，則會被截斷或損壞。錯誤訊息通常指出字串長度無效或缺少字元。修復需要知道最初複製的內容。
如果您可以再次檢查來源，請仔細複製一遍。否則，截斷將無法恢復。填充損失是一個相關問題：帶有等號的 Base64 填充有時會被刪除以節省幾個位元組。有些應用程式省略填充，有些則需要填充。如果字串最初被填充並填充丟失，請將其添加回來。 Base64 字串應具有 0、1 或 2 尾隨等號，以便總長度為四的倍數。如果沒有且長度不是四的倍數，則填充可能已遺失。
工作範例：修復包裝和截斷的字串 - 逐步清理它直到解碼
一個工作範例逐步展示了這些修復。假設複製的 API 金鑰在編輯器中顯示如下：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==。從識別問題開始。尾隨的 Cg== 是奇數； Cg 是換行符號（十六進位 0A）的 base64，額外的 == 表示增加了某些內容。刪除尾隨的 Cg== 並嘗試僅 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0。這仍然是不對的；長度為 37 個字符，而不是四的倍數。再修剪：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0（35字符，仍然錯誤）。檢查原始來源。正确的字符串是 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 （32 字符），並具有适當的填充：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0。添加它：VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=。
在解碼器中測試。這解碼為 這並不是一個真正的秘密。在每個步驟中，使用 Base64 編碼器和解碼器測試目前字串，修復已識別的問題並再次測試，直到解碼。解碼器無法修復 Base64 位元組本身內部的損壞。如果位元組實際上在傳輸、傳輸或預存程序中損壞，Base64 本身無法偵測到。 RFC規定了有效字元；該集合之外的任何字元都是解碼器要捕獲的工作。任何字節损坏（例如 0 在 Base64 字符中間變成 1）都會產生完全不同的字符代碼，並僅由 Base64 無法檢测到。
這不包括 - 編碼位元組內部的損壞，Base64 本身無法偵測到
校驗和或數位簽章用於偵測這種損壞，並必須在 Base64 編碼之前對原始二進位資料進行計算。如果您解碼 Base64 字符串並結果是垃圾或與您的預期不同，則损坏發生在編碼之前或传輸期間，而不是複制粘贴步骤期間。這在實踐中很少見。大多數失敗都是像上面這樣的複製貼上問題。調試 Base64 複製貼上故障的系統方法是按順序測試每個潛在問題。首先，刪除所有空格和換行符。然後修剪前導和尾隨空格以及任何雜散字元。
然後檢查長度模四並根據需要添加填充。將每個版本貼到 Base64 編碼器和解碼器中並查看它是否解碼。如果長度檢查失敗，則詢問字串是否被截斷並從原始來源檢索它。如果字母表檢查失敗並您看到不尋常的字符，請查找智慧引號或 Unicode 替換並將其替換為 ASCII 等效項。使用線上工具按名稱顯示無效字符，以便您識別並刪除它們。 Base64 編碼器和解碼器對每個無效字元執行此操作，準確說明哪個字元不在字母表中。
重點：在歸咎於數據之前檢查長度和字母表 — Base64 編碼器和解碼器如何為您提供一個快速的本地位置來測試每個修復
使用該回饋來修復每個字元並繼續，直到字串解碼。預防比調試更容易。當您知道再次需要 Base64 字串時，請以保留格式的方式複製它。不要將其貼到富文字文件中。將其儲存在純文字檔案或不進行替換的指定文字區域中。如果有人在格式化訊息中向您發送 Base64 字串，請要求他們以代碼格式或純文字形式重新發送。如果必須從格式化來源進行複製，請先貼上到純文字編輯器中，並在使用之前驗證字串。
取得字串後，請在依賴它之前立即在 Base64 編碼器和解碼器中對其進行測試。如果失敗，您可以在仍可存取來源的情況下索取一份新副本。如果等到字串變舊或來源消失，修復截斷或損壞就變得不可能。 Base64 編碼器和解碼器為您提供了一個快速的本地位置，可以在提交使用之前測試任何字串。儘早測試並經常測試，以便立即發現複製貼上故障。