編碼與字元集
Base64 裡是什麼？查看原始內容
使用工具
API 回應或設定檔裡，是否出現過一長串看不懂的字元？你可能以為它已經加密，因而停止排查。但有時它只是以 Base64 形式表示的資料。
本指南先還原公開的小範例，再逐項改變條件。學習操作不需要貼上實際憑證。分清原始資料、編碼後的表示與輸出方式，再長的字串也能依序檢查。
YWJj 還原後是什麼？
開啟 Base64 工具，選擇解碼、標準 Base64 與 UTF-8 輸出。只輸入下方四個字元再執行，不包含引號或說明文字。
YWJj結果是 abc。切換為編碼並輸入 abc，輸出應回到 YWJj。這樣就完成了原始資料與編碼表示之間的往返，全程沒有使用金鑰或解密密碼。
編碼是依規則改變表示方式，解碼是從該表示取回資料。看起來難讀，並不代表別人無法還原。檢查實際資料時，應始終保留這個區別。
為什麼要把資料變得難讀？
abc 直接傳送似乎更簡單。但若要透過以文字為主的格式傳遞圖片或任意檔案，情況就不同了：並非每種位元組都能直接放入該格式。
Base64 以有限的字元集合表示原始位元組。它解決的是表示問題，而非保密問題。API 若定義了 Base64 欄位，可以理解成用文字形式攜帶位元組，而不是已保護了內容。
同樣是 abc，結果為什麼不同？
在編碼模式下比較 abc 和末尾帶一個 LF 換行的 abc。後者得到 YWJjCg==，而非 YWJj。字母後的不可見位元組也是資料，結果並非隨機變化。
YWJj
YWJjCg==若解碼文字看起來一樣，改用 Hex 輸出。無換行為 616263，帶 LF 為 6162630a。來自其他環境的資料也可能使用 CRLF，不能只憑顯示相似就認定位元組相同。
中文也能還原，但要留意字元編碼
試試三個字元『日本語』。SheepDev 先將文字轉成 UTF-8 位元組，再編碼為 Base64，得到 5pel5pys6Kqe。以 UTF-8 輸出解碼，可還原同樣三個字元；介面語言不會改變此範例的結果。
Base64 本身不理解中文、日文或韓文。文字轉位元組、位元組轉 Base64 是兩個不同步驟。來源若使用 Shift_JIS 等其他編碼，即使 Base64 合法，也不一定能作為 UTF-8 文字讀取。
此時可查看 Hex，並以資料產生方確認的編碼繼續檢查。不要不斷切換編碼，只求錯誤消失。即使出現可讀文字，也不能單憑這點斷定正確還原了原文，應與已知內容核對。
輸出變長並非失敗：Base64 不是壓縮
abc 占 3 個 UTF-8 位元組，YWJj 是 4 個 ASCII 字元。Base64 通常將 3 個位元組表示成 4 個字元，較長資料約變為原來的 1.33 倍。將圖片改成 Base64，並不等於減少傳輸量。
| 原文 | 標準 Base64 |
|---|---|
| a | YQ== |
| ab | YWI= |
| abc | YWJj |
短輸入受補位影響，表面倍率可能更大。依序試 a、ab、abc，末尾等號數量會改變。等號是與長度有關的補位，不是損壞字元或複製產生的雜質。能否省略，要看使用方格式的規定。
Base64url 有什麼不同？
標準 Base64 使用 + 與 /，Base64url 在對應位置使用 - 與 _。SheepDev 編碼 Base64url 時也省略末尾補位。應依接收格式的規定選擇，而非因應用程式在網頁上就自動選 Base64url。
只用 abc 看不出全部差異，因為某些輸入在兩種方式下相同。改用 ????：標準結果為 Pz8/Pw==，Base64url 為 Pz8_Pw。還原時選擇對應方式，手動替換字元前先檢查設定。
解碼後不一定是文字
Base64 不只承載文章。圖片、壓縮資料或密文在解碼後未必是合法 UTF-8。Base64 格式錯誤，與還原出的位元組不能當成 UTF-8 讀取，是兩種不同問題。
可用 /w== 練習。依標準 Base64 解碼為 Hex 得到 ff，但單一 FF 位元組不是合法 UTF-8 文字。因此 UTF-8 報錯不代表 Base64 一定有錯。Hex 用來觀察位元組，不是顯示原始圖片的功能。
無法還原時，依什麼順序檢查？
- 確認來源明確規定為 Base64。只憑一長串英數字，無法與 ID 或雜湊區分。
- 檢查是否複製了完整的值，而非引號、註解或 data: URL 標頭，也要檢查是否遭截斷。
- 核對標準 Base64 與 Base64url 選項。SheepDev 不會自動刪除所有內部空白與換行，也要確認來源格式是否會主動折行。
- 格式能解碼後，再確認內容類型。文字要檢查字元編碼，其他資料要檢查原始檔案格式，不應將無意義輸出當作正確還原。
看不懂，不代表保密
想想一開始不需要金鑰就把 YWJj 還原為 abc。密碼或個人資訊編碼後仍有此特性。提交問題報告時，若將編碼值當成已遮蔽的內容，可能暴露原始資訊。
雜湊的用途不同，不能像 Base64 那樣解碼雜湊值來還原原文。讀出 JWT 內容也不代表簽章或可信性已被驗證。應查看對應指南，依想取得的證據選擇工具。
如何用於實際排查？
有用的排查紀錄不只是『解碼成功』。應記錄來源規定的格式、輸出方式，以及預期與實際內容的差異。例如『標準 Base64 可還原，Hex 是 FF，但不是 UTF-8』，就能將下一步引向資料類型或字元編碼。
先確認格式，再取出值，最後確認原始資料類型。養成這個順序後，轉換工具不只是改變字串，也能協助縮小問題範圍。能讀出內容，從不代表可以安全執行或公開它。