字元集是第一道關
編碼前確認原文是 UTF-8，這是現代系統的通用預設。如果原文來自老系統（例如 Big5 編碼的純文字檔），先轉成 UTF-8 再編碼，否則解碼端看到的中文會是亂碼。
解碼時也要用同樣的字元集還原。跟協作對象先約定好「一律 UTF-8」，能省掉九成以上的亂碼糾紛。
換行與空白是隱形殺手
從郵件、PDF、聊天記錄複製 Base64 字串時，經常混入換行或空格。貼上前先把字串貼到純文字編輯器，刪掉所有換行與多餘空白，確認是一整串連續字元再解碼。
有些系統會把長字串自動折行（例如每 76 字元換行），這是 RFC 規範允許的，但解碼前最好先把換行去掉，避免某些嚴格的解碼器報錯。
複製時保持完整
解碼失敗最常見的原因其實最無聊：沒複製完整。長按選取容易漏掉頭尾，特別是結尾的 = 符號。貼上後快速掃一眼頭尾，確認跟來源一致。
傳遞編碼結果給別人時，建議用程式碼區塊或附件傳送，避免聊天軟體自動截斷、或把 + 號之類的字元轉義掉。
常見問題
為什麼同樣的字串昨天能解、今天不行？
通常是複製過程出了差異：今天可能多貼了空白、少貼了結尾，或經過了會改寫字元的軟體。重新從來源完整複製一次，多半就正常了。
編碼結果裡出現 + 和 /，傳給對方要注意什麼？
這兩個字元在網址與部分系統裡有特殊意義。走網址時請先做 URL 編碼，或改用 Base64URL 變體，避免傳輸過程被改寫。
怎麼驗證編碼結果是正確的？
立刻解碼一次比對：把剛產生的 Base64 字串解回來，跟原文逐字對照。養成這個習慣，傳出去前就能抓到問題。