瀏覽器本機的 Base100 編碼 API 替代方案，是指任何在用戶端執行的工具，執行相同的位元組到符號對應——將每個 UTF-8 位元組加上 U+1F3F7——而不需要發送網路請求、註冊帳號，或支付請求配額。Adam Niederer 的原始 Base100 專案定義了一套公開對應規則，將每個 0 到 255 的位元組值，轉換為落在 U+1F3F7 到 U+1F4F6 這個含首尾範圍內的恰好一個 Unicode 碼位，而且由於公式只是單一次加法，編碼或解碼都不需要任何外部服務。像是 Base100 編碼器 / 解碼器 這類瀏覽器型替代方案，在本機執行相同的加法，並依據 WHATWG 編碼標準 在文字邊界進行嚴格的 UTF-8 驗證，且會回傳符號流或精確的錯誤，而不是靜默地進行替換。對於相同的位元組會產生完全相同的輸出，實際上的好處則是任何資料都不會離開裝置：沒有 API 金鑰、沒有用量計量，也不會有遠端端點改寫、記錄或限流你正在檢查的符號流的風險。
為什麼要尋找 Base100 編碼 API 的替代方案？
當格式是封閉的、規則是專有的，或伺服器必須持有金鑰時，API 呼叫才有意義。Base100 不屬於上述任何一種。對應規則已在 Adam Niederer 的開源專案中公開，公式只是一行算術，只要位元組流能保留，往返轉換就是無損的。人們提到 API 的每個理由——速率限制、可用性、地區可用性、計費、JSON 包裝——都只在確實需要服務時才適用。一旦瀏覽器工具在你的分頁中執行加法與減法，API 就會從工作流程中消失，卻不會移除任何功能。
尋找替代方案的實際觸發情境包括：想在不將位元組傳送給第三方的情況下檢查一個流、除錯一個貼文出錯的傳輸管線，以及在遠端端點離線或被限流時需要一個備援方案。用戶端工具也能避免 API 在遇到無效 UTF-8 時靜默替換為替代字元、卻仍回傳「成功」回應的失敗模式。遵循 WHATWG 行為的瀏覽器型替代方案會以嚴格方式拒絕無效序列，而不是假裝它們是有效的。
瀏覽器型 Base100 替代方案的運作方式
Base100 格式會將輸入視為位元組序列，前提是字串已先轉換為 UTF-8。範圍 0..255 中的每個位元組 b，會透過計算 U+1F3F7 + b 對應到恰好一個 Unicode 碼位。這就是完整的編碼規則。位元組零會變成 U+1F3F7，位元組一會變成 U+1F3F8，位元組 255 會變成 U+1F4F6，因此輸出永遠是 256 種可能的 emoji 範圍符號中連續的一段。解碼則是反向的減法：每個輸入碼位會減去 U+1F3F7 以還原為位元組，接著將得到的位元組序列送入嚴格的 UTF-8 解碼器。若這些位元組無法構成有效的 UTF-8 序列，解碼會明確失敗。沒有填補、沒有校驗和、沒有長度前綴、沒有壓縮，也沒有語意解讀。
| 位元組值 | 碼位 | 在範圍中的角色 |
|---|---|---|
| 0x00 | U+1F3F7 | 256 個符號對應的下界 |
| 0x01 | U+1F3F8 | 下界之上的第一個位置 |
| 0x41 | U+1F438 | ASCII 字母「A」(下方有計算範例) |
| 0x7F | U+1F476 | 最高的 ASCII 位元組值 127 |
| 0xFF | U+1F4F6 | 256 個符號對應的上界 |
由於對應關係是每個位元組對應一個符號，ASCII 字元會恰好變成一個 Base100 符號，而非 ASCII 字元則會依其 UTF-8 位元組長度按比例變成多個符號。例如，編碼 ASCII 字母「A」會直接套用公式：其 UTF-8 位元組為 0x41(十進位 65)，因此編碼後的碼位是 U+1F3F7 + 0x41 = U+1F438。反向過程也使用相同的算術：給定有效流中的 U+1F438，解碼器減去 U+1F3F7 以還原 0x41，再經 UTF-8 步驟重建出「A」。任何能執行加法與嚴格 UTF-8 解碼的人，都能重現與原始 Rust 參考實作相同的輸出，這也是為什麼純瀏覽器工具足以完全取代 API。
在瀏覽器中編碼與解碼 Base100
- 開啟 Base100 編碼器 / 解碼器，選擇 Text to Base100 方向進行編碼，或選擇 Base100 to text 進行解碼。
- 編碼時，將 UTF-8 文字貼上或輸入到輸入欄位。工具會在記憶體內將字串轉換為 UTF-8 位元組，並對每個位元組加上 U+1F3F7，每個位元組產生一個符號。
- 點擊執行按鈕以產生輸出的符號流。該頁面在任一方向上都限制為 500,000 位元組或符號，以避免意外貼上大量內容而導致瀏覽器凍結。
- 複製完全相同的符號流。請勿插入空格、換行、標點符號或變體選擇器；任何這些內容都會破壞嚴格解碼，因為它們在原始格式中並非框架語法的一部分。
- 解碼時，切換到 Base100 to text，貼上未經修改的符號流，然後執行轉換。每個碼位會減去 U+1F3F7，接著重組位元組，再由嚴格的 UTF-8 解碼器重建文字。
- 查看結果或錯誤。空輸入會被拒絕，工具絕不會靜默截斷輸出；無效符號、超出範圍的碼位或格式錯誤的 UTF-8 序列都會被回報，而不是以替代字元取代。
Base100 與其他位元組編碼的比較：選擇正確的替代方案
Base100 是將原始位元組透過 Unicode 感知文字欄位傳遞的其中一種方式。彼此之間的選擇通常取決於三個問題：輸出必須有多精簡、目的端是否接受非 ASCII 碼位，以及是否需要嚴格解碼。下表概述了每種選項在位元組層級的字元集與大致長度行為，協助你判斷 Base100 是否為合適的替代方案，或是否其實有其他編碼更符合該傳輸需求。
| 編碼方式 | 輸出字元集 | 100 個 ASCII 位元組的長度 | 傳輸注意事項 |
|---|---|---|---|
| Base100 | U+1F3F7 到 U+1F4F6(256 個 emoji 範圍碼位) | 100 個符號 | 對 ASCII 而言相當精簡；需要支援 emoji 的目的端。 |
| Base64 | A–Z、a–z、0–9、+、/(以及 = 填補) | ~136 個字元 | 幾乎在所有 8 位元乾淨的文字通道中都安全。 |
| 十六進位 | 0–9、a–f | 200 個字元 | 到處都安全；易於逐位元組檢查。 |
| Base58 | 排除 0、O、I、l 的 58 個英數字元 | ~143 個字元 | 常見於比特幣風格識別碼；便於人工複製。 |
對於純 ASCII 輸入，Base100 異常精簡，因為符號流長度等於位元組數；然而一旦來源文字包含變音符號、CJK 字元或 emoji，每個 Unicode 字元會依其 UTF-8 位元組寬度按比例展開成數個符號。若傳輸通道無法保證這 256 個對應碼位會原封不動地通過——例如 SMS 閘道、舊式資料庫欄位，或僅支援 ASCII 的檔案格式——那麼明確的十六進位表示法或 Base64 會是更寬容的替代方案。反過來說，若目的端是現代聊天應用程式或 UTF-8 資料庫欄位，且獨特的 emoji 外觀正是需求的一部分，那麼 Base100 就是合適的工具。
限制、錯誤與互通性風險
瀏覽器型替代方案中的嚴格解碼器並非風格選擇，而是保證往返轉換能保留精確位元組序列的唯一方式。此工具會拒絕任何落在 U+1F3F7..U+1F4F6 範圍之外的碼位，拒絕忽略空格、換行、標點符號或變體選擇器，也拒絕將格式錯誤的 UTF-8 位元組序列強行轉為帶有替代字元的「盡力而為」字串。因此，螢幕上看起來相似的流，在位元組層級可能不同而導致解碼失敗，而這通常是正確的行為：它會告訴你是管線中的某個環節修改了符號流，而不是原始文字。
Emoji 的呈現也會因作業系統、字型、瀏覽器和訊息平台而異。有些對應到的碼位會呈現為彩色圖像，有些則是單色字形，少數則可能顯示為方框或預期之外的圖示。視覺差異屬於外觀層級，並不會影響符合規範字串內部的數學對應，但若複製經過會替換、移除或裝飾字元的系統，就可能受影響。若互通性很重要，請從已知能精確保留碼位的來源複製符號，並在依賴結果之前，先以往返編碼與解碼進行驗證。Base100 編碼器 / 解碼器同樣採用此嚴格檢查，這也是它會產生原始文字或明確錯誤、而非悄悄損壞字串的原因。
隱私與安全：本機工具能做到與不能做到的事
在瀏覽器中執行編碼與解碼步驟，代表位元組與符號流在轉換過程中都不會離開裝置，進而消除了 API 呼叫所帶來的其中一類洩漏。但這並不會讓 Base100 變成一種保密機制。任何知道公式的人都能還原文字，沒有校驗和可以區分意外符號置換與惡意符號置換，「加密的 Base100」串流讀起來和普通 emoji 串流一樣容易。對於密碼、個人資料、權杖或任何其他機密內容，請使用經過審核、具備真實金鑰的認證加密格式，而不是可逆的位元組編碼。
在 UTF-8 邊界的行為由 WHATWG 編碼標準規範，原始對應規則記載於 AdamNiederer/base100 儲存庫，因此公式、含首尾的 256 個碼位範圍，以及嚴格的 UTF-8 解碼器全部由外部明定，而非工具自創。這種組合——公開對應、嚴格驗證、本機執行——正是純瀏覽器 Base100 編碼器得以成為任何公開相同格式的託管 API 之完整替代方案的原因。
若想進一步了解，請參閱 Base64 解碼 API 替代方案：在本機執行解碼器。