親手測試 Base64、中文十六進位、截斷資料與無效 UTF-8；分清楚編碼格式正確和內容可讀是兩回事。
解碼要過兩關：格式正確，內容也要是文字
拿到一串看不懂的字元時，先問來源：它是 Base64、十六進位，還是原本就不是編碼？光靠字串長相不能確認。本站的解碼工具處理 UTF-8 文字，不是圖片還原器，也不是所有檔案格式的檢視器。
Base64 把位元組表示成另一組字元；UTF-8 定義文字如何對應到位元組。第一關能還原出位元組，不代表第二關就能讀成文字。這也是為什麼有些 Base64 沒有非法字元，本站卻仍拒絕解碼。
正常案例：先建立可核對的基準
SGVsbG8= 解碼得到 Hello；e4 b8 ad e6 96 87 以 UTF-8 十六進位解碼得到「中文」。後者是六個位元組，每兩個十六進位數字表示一個位元組。空白在這裡只是分隔符號。
先在下方跑這兩個正常範例，確認選對格式。再換自己的資料。若正常範例可用而資料失敗，優先檢查來源與截斷；不要反覆點擊期待同一份錯誤資料得到不同結果。
三種失敗，修法不同
e4 b8 a 有奇數個十六進位數字，最後一個位元組不完整。應回到來源重新取得完整內容，不能隨便補一個 0。%%% 含非 Base64 字元，則要確認是不是貼錯欄位或選錯格式。
/w== 是可以還原出位元組 FF 的 Base64，但 FF 不是有效 UTF-8 文字的起始位元組，所以本工具會拒絕。這不是要求你刪掉某個字元，而是在提醒內容可能是二進位或其他字元編碼；請回原始檔案和產生工具查證。
哪些情況應該停止猜測？
若來源是 Big5 或 GBK 檔案，應使用明確支援該字元編碼的檔案工具開啟原檔。若貼上後已出現替代字元「�」，部分資訊可能已丟失，不能承諾靠這個網頁還原。此頁不提供自動辨識所有編碼或檔案修復。
Base64 不是加密，不要用它保護密碼。回報問題時，附不含私人資料的最小範例、選用格式及預期文字即可；不要把 API Key、帳密或原始客戶文件貼進公開回報。瀏覽器錯誤原文可能不同，本頁以「成功輸出」或「拒絕」記錄可驗證的行為。
實測紀錄：輸入與引擎輸出
使用本站安裝的 opencc-js 1.4.1 與原生 UTF-8 解碼實測。下表納入回歸測試，但不是語言品質評分；字典或依賴更新後，結果可能改變。
窄螢幕可左右捲動表格，查看完整欄位。
| 案例／模式 | 輸入 | 實際輸出 |
|---|---|---|
正常 Base64：還原 Hellobase64 decode | SGVsbG8= | Hello |
正常 UTF-8：還原中文hex decode | e4 b8 ad e6 96 87 | 中文 |
錯誤：最後半個位元組hex decode | e4 b8 a | 拒絕解碼（格式或 UTF-8 錯誤） |
錯誤：非 Base64 字元base64 decode | %%% | 拒絕解碼（格式或 UTF-8 錯誤） |
格式可解，但不是 UTF-8 文字base64 decode | /w== | 拒絕解碼（格式或 UTF-8 錯誤） |
親手測試，不只看答案
按下按鈕才會執行目前的本機轉換引擎。可修改範例（每次最多 10,000 字元）；文字不會上傳或儲存，字典會按需下載。
整理方式、來源與訂正
本文與功能由 AI 輔助整理，並以本機可執行範例核對。未宣稱經獨立語言專家審訂。範例可重現，但人名、文風與作者意圖仍須由理解原文的人確認。