Base58 編碼解碼

一般文字會先轉成 UTF-8 位元組，再編碼為 Base58 或 Base58Check。

0 輸入字元

在瀏覽器中完成 Base58 與 Base58Check 編碼解碼，支援文字、檔案、自訂字元表與十六進位結果檢視。

相關推薦

十六進位轉換

Base32 編碼解碼

Base64 編碼

URL Safe Base64

Base85 編解碼器

檔案雜湊校驗

什麼是 Base58 與 Base58Check？

Base58 是一種人類閱讀和複製貼上的文字編碼。它會去掉 0、O、I、l 這類容易看錯的字符，因此常被用在短標識、邀請碼、錢包地址、離線分享碼等場景。

標準 Bitcoin Base58 字元表為 `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`。本頁同時支援 Flickr 版字母表，以及你自己定義的 58 字元字元表。

Base58Check 是在原始位元組後面追加 4 位元組校驗和，再整體做 Base58 編碼的方案。它常用於比特幣舊地址、WIF 私密金鑰匯出、邀請碼或需要手動抄寫的字串，目標是更早發現輸錯、漏字或順序錯亂。

如果你拿到的是二進位負載、位址載重或雜湊片段，解碼後的內容不一定是可讀文字。這時更適合切到十六進位查看，而不是把亂碼誤判為解碼失敗。

IPFS CIDv0 使用的是標準 Base58btc，而非 Base58Check；`bc1...` 這類比特幣位址屬於 Bech32，也不在本頁 Base58 範圍內。

適用場景

  • 校驗舊版比特幣地址、WIF 私鑰匯出字串或自訂 Base58Check 分享碼是否被輸錯。
  • 把小檔案、二進位片段或測試負載編碼成 Base58，方便在日誌、聊天或工單傳遞。
  • 把 Base58 字串先解碼成十六進位，繼續分析其中的版本位元組、雜湊或原始負載。
  • 在 Bitcoin Base58 與 Flickr Base58 之間比對輸出，排查同一組位元組為何在不同系統裡結果不同。
  • 為內部邀請碼、短標識或離線 token 設計自己的 58 字元字元表，並驗證雙端是否一致。

使用方法

  1. 選擇編碼或解碼模式；如需處理手動輸入容易出錯的字串，再開啟 Base58Check 選項。
  2. 選擇 Bitcoin、Flickr 或自訂字元表；如果是私有協議，先確保雙方使用的是同一套 58 字元順序。
  3. 編碼時輸入文字或上傳檔案；解碼時貼上 Base58 字串，必要時切換到十六進位結果查看原始位元組。
  4. 查看輸出後直接複製或下載；若是 Base58Check，頁面會同步提示校驗是否通過。

功能特點

  • 標準 Base58 與 Base58Check 雙模式：可直接做普通編碼，也可自動追加或校驗 4 位元組校驗和。
  • 文字與文件都能編碼：一般文字會依 UTF-8 處理，檔案則會依原始位元組編碼，適合離線傳遞二進位內容。
  • 解碼結果可切換文字或十六進位：遇到位址載重、雜湊片段或非 UTF-8 資料時，不會被亂碼卡住。
  • 支援 Bitcoin、Flickr 和自訂 58 字元字元表：適合相容已有系統，或偵錯私有短碼方案。
  • 瀏覽器本地處理與結果下載：編碼、解碼、校驗都在本機完成，輸出可直接複製或下載。

Base58、Base58Check、Base64 怎麼選？

它們都能把位元組轉成可傳遞的文本，但重點完全不同。關鍵不是“哪個更高級”，而是你是更重視人工抄寫、防輸錯，還是更重視緊湊和通用兼容。

方案更適合優勢注意點
標準 Base58短標識、手動輸入、複製分享去掉易混淆字符，肉眼更好辨認，適合邀請碼、離線碼、CIDv0 這類字串。沒有內建校驗和；如果需要自動驗錯，應改用 Base58Check。
Base58Check地址、匯出字串、人工抄寫後的再次校驗在 Base58 上再加 4 位元組校驗和，更容易發現漏字、錯字和順序錯誤。輸出會比標準 Base58 略長；它只負責驗錯，不負責解析位址類型或網路。
Base64 / Base64URL介面傳輸、前後端交換、需要更短輸出時同樣的資料通常比 Base58 更短，生態更通用，適合程式之間直接傳輸。字元裡可能包含 +、/、=；如果要放進 URL，應改用 URL-safe 變體。Base64 編碼Base64 URL Safe
Base32不區分大小寫、口頭傳遞或某些相容場景字元集較保守，有些系統裡輸入容錯較高。輸出通常比 Base58 更長；如果主要訴求是更短、更適合短碼，Base58 往往更合適。Base32 編碼

最佳实践

人工抄寫或客服轉述時優先開 Base58Check

只要字串會經過口述、截圖、聊天轉發或人工重輸，校驗和幾乎總是值得開。它不會阻止所有錯誤，但能明顯減少「看起來像對，其實少了一個字元」的情況。

解碼出來不是文字時先看十六進制

位址載重、雜湊、圖片頭、壓縮片段這類內容本來就不保證是 UTF-8。先切到十六進位確認原始字節，再決定後續是轉檔、繼續雜湊還是交給別的工具處理。

十六進位工具

大檔案不要把 Base58 當長期儲存格式

Base58 較適合短字串和中小載重。文件越大，輸出越長、複製越不方便，也更容易在富文本、聊天工具或日誌中被截斷。

自訂字元表時一定同步到所有生產端

只要有一個服務端、腳本或客戶端用了不同順序，編碼和解碼結果就會全部錯位。先固定 58 字元順序，再把它寫進協議或測試範例裡。

需要更短、更通用的介面傳輸時優先比較 Base64URL

Base58 的優點是易讀和防混淆，不是體積最省。如果字串主要在程式間傳遞，且不會人工抄寫，Base64URL 通常更緊湊也更常見。

Base64 URL Safe

常見問題

Base58 和 Base64 應該選哪一個？

如果字串要給人看、抄寫、給人輸，優先 Base58；如果主要是在程式、介面、JSON 或 URL 參數裡傳輸，通常 Base64 或 Base64URL 更緊湊。 Base58 的重點在於可讀性和防混淆，不是最短輸出。

Base58Check 到底在解決什麼問題？

它會在原始負載後追加 4 位元組校驗和，再整體做 Base58 編碼。這樣當使用者漏字、錯字或順序寫錯時，工具就更容易及時報錯，而不是靜悄悄地得到一串無意義結果。

這個頁面能校驗比特幣地址嗎？

可校驗 Base58Check 這一層是否正確，因此適合檢查舊版 Base58 位址或 WIF 匯出字串有沒有明顯輸入錯誤。但它不會進一步判斷位址用途、網路類型、腳本類型，也不支援 `bc1...` 這類 Bech32 位址。

為什麼解碼後面是亂碼，或是提示不是 UTF-8？

因為 Base58 解出來的是原始字節，不一定是可讀文字。位址負載、雜湊、圖片頭或任意二進位資料都可能出現這種情況。切到十六進制查看原始字節，通常就能繼續分析。

支援文件 Base58 編碼和解碼嗎？

支持。編碼時可以上傳文件，頁面會以原始位元組轉成 Base58；解碼後也可以把原始結果下載回來。檔案越大，輸出字串越長，因此更適合中小型負載或偵錯場景。

支援哪些字符表？

目前支援標準 Bitcoin Base58、Flickr Base58，以及你自訂的 58 字元字元表。只要編碼端和解碼端使用完全相同的字元順序，就可以互通。

能處理 IPFS CID 或別的鏈上字串嗎？

CIDv0 這類標準 Base58btc 字串可以直接編碼或解碼；但頁面不會繼續解析 multibase、multicodec 或具體鏈上語意。像 `bc1...` 這種 Bech32 字串，也不屬於 Base58 範圍。

上傳的內容會發到伺服器嗎？

不會。文字、檔案、Base58Check 校驗和結果都在瀏覽器本地處理，適合調試敏感負載、離線測試資料或不方便上傳的檔案片段。

故障排查

提示包含非法 Base58 字符

目前字符表不接受 0、O、I、l 這類被排除字符，也可能是你切錯了 Bitcoin / Flickr / 自訂字符表。先確認字串來源，再檢查字元表是否和對方一致。

Base58Check 校驗失敗

通常說明字串被少複製了、字元寫錯了，或者它本身就不是 Base58Check。先確認是否真的需要開啟 Base58Check，再回頭檢查原始內容是否完整。

自訂字元表無法保存

自訂字符表必須剛好 58 個字符，而且每個字符都只能出現一次。建議先從標準 Bitcoin 字元表開始修改，避免少字元或重複字元。

解碼結果不是文本

這不一定是錯誤。很多 Base58 字串本來承載的就是二進位負載。切到十六進位查看，或把解碼結果下載為文件，再決定下一步處理方式。

術語表

Base58
去掉 0、O、I、l 等易混淆字元的 58 進位文字編碼，適合人工輸入和複製分享。
Base58Check
在原始負載後追加 4 位元組校驗和，再整體做 Base58 編碼的方案，用來更早發現輸錯。
Payload
做 Base58 或 Base58Check 編碼前的原始位元組內容，可以是文字、檔案位元組、位址負載或任意二進位資料。
Checksum
用於快速驗錯的短指紋。 Base58Check 會對負載做雙 SHA-256，並取前 4 個位元組作為校驗和。
Bitcoin Base58 字元表
最常見的 Base58 字元表：123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz。
Flickr Base58
Flickr 使用過的另一套 Base58 排序，大小寫順序與 Bitcoin 版不同，因此同樣的位元組會得到不同輸出。

目前頁支援的字符表

同樣一組字節，只要字元表順序不同，最終 Base58 輸出就會不同。

字元表常見用途說明
Bitcoin Base58錢包位址、CIDv0、常見 Base58 工具預設字元表，相容於絕大多數 Base58 場景。
Flickr Base58舊 Flickr 短 ID 場景大小寫順序和 Bitcoin 版不同，不能混用。
自訂 58 字元表內部協定、短碼系統、私有相容層必須保證 58 個字元唯一且雙端順序一致。

什麼時候該切到十六進位查看

Base58 解碼的結果不是總是能直接讀成文字。

遇到的內容更適合的檢視方式原因
位址載重 / 版本位元組十六進位更容易看出前綴、校驗和和固定位元組結構。
哈希片段 / 二進位測試數據十六進位這些內容本來就不是 UTF-8 文本。
普通短文本 / UTF-8 字串UTF-8 文本可以直接看到原始內容，複製也更方便。
檔案或壓縮片段十六進位或下載結果更容易判斷檔案頭、魔數或後續處理路徑。

Authoritative References