Base100 解碼會讀取一段位於 emoji 區段的 Unicode 符號串流，並還原出其背後原始的 UTF-8 文字，使用的是在 U+1F3F7 到 U+1F4F6（含）範圍內，一位元組對應一個碼點的對映關係。解碼器會從每個符號的碼點減去 U+1F3F7，以還原出一個介於 0 到 255 之間的位元組，依序收集這些位元組後，再執行嚴格的 UTF-8 驗證來重建原始字串。由於對映是按位元組且具確定性的，任何知道這個公式的人都能解碼一段 Base100 串流——沒有祕密金鑰、沒有填補、沒有校驗和，也沒有壓縮。因此 base100 解碼器有三項具體工作：只接受位於精確範圍內且未經修改的碼點；對任何超出 U+1F3F7 到 U+1F4F6 範圍的內容發出明確錯誤；以及在還原出的位元組無法構成有效的 UTF-8 序列時拒絕猜測。現代解碼器也是以完整的 Unicode 碼點而非 UTF-16 碼元來運作，因此能正確處理輔助平面符號，而不是將它們拆成錯誤配對的代理對半形。
Base100 是作為公開的位元組對 emoji 編碼器而推出，而 Adam Niederer Base100 儲存庫仍是這套對映的權威參考。Base100 編碼器／解碼器則在瀏覽器中套用相同的位元組算術，這也是為什麼這個工具能解碼別人使用原函式庫編碼的串流，而不需要任何額外的協商。
Base100 核心的位元組對碼點對映
在 Base100 字集中，每個 0 到 255 的位元組都對應到唯一一個 Unicode 碼點，公式非常簡單：碼點 = U+1F3F7 + 位元組值。位元組 0 變成 U+1F3F7，位元組 1 變成 U+1F3F8，位元組 255 變成 U+1F4F6。解碼則是其反向：從碼點減去 U+1F3F7 以還原原始位元組，再依輸入順序串接起來。由於字集使用的是連續的碼點，base100 解碼器可以透過檢查碼點是否落在這個含首尾的範圍內來驗證每個符號，而不是用模式比對固定表格的方式。
編碼永遠從將輸入字串轉成 UTF-8 開始，因為這是對映實際操作的位元組序列。一般 ASCII 字元各佔一個位元組，所以一串純字母會產生一個字元對應一個 Base100 符號。非 ASCII 文字通常會膨脹，因為一個 Unicode 字元可能需要好幾個 UTF-8 位元組——含附加符號的字母通常需要 2 個位元組，CJK 字元需要 3 個，輔助平面字元則需要 4 個。因此輸出的符號數計算的是編碼後的位元組，而不是字素叢集、字詞或原始 JavaScript 字串長度。例如，"Café" 這個字是 4 個字元，但有 5 個 UTF-8 位元組，因為 é 含附加符號會編碼成 2 個位元組；因此一段 Base100 串流會帶有 5 個符號。
這個格式沒有任何框定語法：沒有前綴、沒有分隔符、沒有長度標記，也沒有校驗和。嚴格的 base100 解碼器會把任何不是 U+1F3F7 到 U+1F4F6 之內碼點的字元視為錯誤，而不是當作可忽略的分隔符。這是原本 Base100 對映與許多允許在符號間填補或加入空白的聊天友善編碼之間一項重要的差異。
如何將 Base100 符號解碼回文字
如果你有一段從訊息、檔案或先前的編碼步驟複製來的 Base100 符號，Base100 編碼器／解碼器可以在你的瀏覽器中本地反解它。
- 開啟 Base100 編碼器／解碼器，並選擇 Base100 到文字的方向，讓表單預期接收 emoji 區段的符號而不是純文字。
- 將符號串流原封不動地貼到輸入區域。不要重新輸入、不要在符號之間插入空白，也不要加入換行。
- 執行轉換。工具會將每個符號讀為一個 Unicode 碼點，拒絕任何超出 U+1F3F7 到 U+1F4F6 範圍的內容，並減去 U+1F3F7 以還原出位元組值。
- 檢視解碼後的文字。如果底層位元組不是有效的 UTF-8 序列，工具會回報錯誤，而不是靜悄悄地替換成替代字元。
- 複製還原出的文字，並在目的應用程式中重複使用。
同一個工具在你選擇文字到 Base100 時會以相反方向執行：它會使用上面的位元組公式把你的 UTF-8 字串轉成符號串流，你可以複製結果來分享。若想更仔細了解這個格式在位元組層面的細節，請參考帶有範例演練的 Base100 編碼指南，介紹 UTF-8 位元組對映。
為什麼貼上的 Base100 串流有時會解碼失敗
因為 Base100 沒有校驗和，一段串流可能在形狀上看起來語法正確，實際上位元組卻是錯的，而嚴格解碼器的設計就是要把這種狀況暴露出來，而不是加以掩飾。最常見的失敗原因是變體選擇子（variation selector）。有些聊天應用程式、emoji 鍵盤與正規化流程會在 emoji 區段碼點上附加 U+FE0F（變體選擇子-16）或 U+200D（零寬連接子）來控制其呈現外觀。螢幕上看起來一樣，但碼點序列已經不再是精確的 U+1F3F7 到 U+1F4F6，任何強制檢查含首尾範圍的 base100 解碼器都會拒絕這段串流。
空白、換行、逗號或其他標點符號會造成同樣的拒絕結果。原始格式在符號之間不使用分隔符，所以任何你連同串流一起複製進來的空白都會變成落在字集之外的額外碼點。透過會自動重排換行的文書處理器、會將輸出切成多列的終端機，或擷取圖片轉文字的 OCR 層來複製，都可能引入不可見字元而使嚴格解碼失敗。
渲染上的怪癖也很重要。同一個碼點在不同的作業系統、字型、瀏覽器與通訊平台上，可能會顯示為彩色影像、單色字形、空方塊，或預期之外的圖像。渲染差異並不會改變一個合規字串內部的碼點，但會改變你在選取文字時實際複製到的內容。如果目的地需要能夠承受任何剪貼簿轉換的傳輸方式，通常 Base64、base64url、Base32 或十六進位會比 Base100 更具相容性。就十六進位而言，WHATWG 編碼標準定義了任何合規解碼器都必須遵守的 UTF-8 邊界。
Base100 vs Base64、Base32、Base58 與十六進位
Base100 是多種位元組對符號編碼之一，要在其中選擇多半取決於字集與傳輸方式。下表就當你透過聊天應用程式、程式碼檔案或僅限二進位的通道複製承載資料時，會在意的特性來比較這些格式。
| 格式 | 字集 | 填補 | ASCII 安全 | 最適合用途 |
|---|---|---|---|---|
| Base100 | 256 個 emoji 區段碼點（U+1F3F7–U+1F4F6） | 無 | 否（僅限 emoji 傳輸） | 在友善於 emoji 的情境中產生視覺上明顯不同的位元組串流 |
| Base64 | A–Z、a–z、0–9、+、/ | = 用於將長度湊成 4 的倍數 | 是 | 通用的二進位轉文字傳輸 |
| Base32 | A–Z、2–7 | = 用於將長度湊成 8 的倍數 | 是 | 區分大小寫、由人輸入的代碼 |
| Base58 | 去除 0、O、I、l 的 Bitcoin 字集 | 無 | 是 | 加密貨幣地址等短識別碼 |
| 十六進位 | 0–9、a–f（或 A–F） | 無 | 是 | 精確的位元組傾印、除錯、低階通訊協定 |
Base100 是這個比較中唯一字集完全位於 ASCII 之外的格式，因此它也是唯一依賴能夠不經修改地承載輔助平面符號之目的地的格式。這使得它在富含 emoji 的情境中視覺上很突出，但在純文字通道中卻很脆弱，那些情境下 Base64 或十六進位會傳輸得更可靠。
Base100 的適用之處——以及它的極限
Base100 是一種可逆的位元組編碼，不是安全工具。它不會隱藏資訊、不會為資訊簽章，也無法偵測竄改，因為它沒有校驗和且對映是公開的。任何知道位元組 b 會變成 U+1F3F7 + b 的人都能立即還原原始位元組，所以 base100 解碼器本質上也就是偽裝成解碼器的 base100 編碼器。如果你需要保護密碼、API 權杖、私鑰或任何機密訊息，請使用經過審核的加密方式搭配像 AES-GCM 這類有認證的模式與金鑰衍生函數——而不是 Base100。
同樣缺乏完整性檢查的特性，也意味著任何單一被替換掉的符號都會悄悄損壞一個位元組。由於 Base100 沒有長度標記、填補或校驗和，解碼器無法判斷一個看起來合理的變更究竟是不小心還是人為惡意，而還原出的位元組即使與傳送方的本意不再相符，仍可能解析為有效的 UTF-8。請將任何跨越不受信任邊界的 Base100 串流視為可疑，並在據以行動之前，透過另一個獨立管道驗證還原後的文字。
也有一些實際限制需要記得。瀏覽器端的工具將任一方向限制為 500,000 個位元組或符號，以免一不小心的巨大貼上讓網頁卡住。空白的輸入會被拒絕，輸出絕不會被靜默截斷，解碼器在還原出的位元組不是有效 UTF-8 時，會採用致命的 UTF-8 驗證，而不是插入替代字元。這些規則合在一起，讓 Base100 成為在友善於 emoji 的通道中傳遞 UTF-8 文字的一種實用且界線明確的方式，只要你能正確認識它是什麼、不是什麼。
如果你正在權衡各種選項，能處理 UTF-8、附加符號與 Emoji 的 Base64 轉換器對此有詳細介紹。