Base100 編碼會將每個 UTF-8 位元組對應到一個 Unicode 碼位，做法是將位元組值加上 U+1F3F7，產生一段從 U+1F3F7（位元組 0）到 U+1F4F6（位元組 255）的符號流。轉換發生在位元組層級：編碼器先將你的文字轉成 UTF-8，然後逐位元組走訪位元組流，將每個位元組替換成位於輔助多語言平面的單一碼位。一個 7 位元的 ASCII 字元會變成一個 Base100 符號，而產生的字串在視覺上相當醒目，因為每個碼位都位於一個 emoji 區塊中。沒有填補字元、沒有分隔符號、沒有校驗和，也沒有壓縮，因此輸出長度可預測，每個輸入位元組對應一個符號。非 ASCII 文字會膨脹，因為一個 Unicode 字元可能需要好幾個 UTF-8 位元組，所以原始輸入中的重音字母、CJK 字形以及 emoji 都會各別產生多個 Base100 符號。因此輸出長度衡量的是編碼後的位元組數，而不是使用者感知的字元、字素叢集或詞。任何知道位移量的人都能反轉這個對應，這使得 Base100 是一種可逆的位元組編碼，而不是保密機制。Base100 編碼器／解碼器會在瀏覽器本地端處理 UTF-8 轉換、位元組到碼位的對應，以及嚴格的反向驗證，因此輸入內容從不離開你的裝置。
Base100 位元組到符號的對應如何運作
原始的 Base100 專案定義了 0 到 255 之間每個位元組與特定 emoji 範圍 Unicode 碼位的一對一關係。位移量是 U+1F3F7，因此位元組 0 變成 U+1F3F7，位元組 1 變成 U+1F3F8，位元組 255 變成 U+1F4F6。中間的位元組則依序填滿其餘範圍，沒有空缺。由於字元集恰好是 256 個碼位，每個可能的 UTF-8 位元組都有定義的目標位置，而每個目標位置也都能解碼回唯一的位元組。
這個對應完全是數學性質的。每個碼位實際顯示成哪個可見的 emoji 字形，取決於平臺、字型、瀏覽器或聊天應用程式。有些會渲染為彩色圖片，有些是單色外框，有些則是缺字方框。這些都不會改變符合規範字串中的底層碼位，但若透過會替換、移除或裝飾字元的系統複製，則可能改變位元組而破壞嚴格解碼。
| 位元組值 | 十進位 | 十六進位 | 碼位 |
|---|---|---|---|
| 最低對應位元組 | 0 | 0x00 | U+1F3F7 |
| 第二個位元組 | 1 | 0x01 | U+1F3F8 |
| ASCII 'A' | 65 | 0x41 | U+1F438 |
| ASCII DEL | 127 | 0x7F | U+1F476 |
| 第一個 UTF-8 續接位元組 | 128 | 0x80 | U+1F477 |
| 最高對應位元組 | 255 | 0xFF | U+1F4F6 |
邊界值很重要，因為它們定義了嚴格解碼器接受與拒絕的範圍。任何落在 U+1F3F7 到 U+1F4F6 之外的內容都會驗證失敗，包括常見的變體選擇器（如 U+FE0F）、前置空白、換行符、標點符號，以及外觀相似但位於不同區塊的 emoji。
如何將文字編碼為 Base100 符號
編碼方向是將位元組對應到符號。開啟 Base100 編碼器／解碼器，選擇「文字轉 Base100」模式，然後依照下列步驟操作：
- 在輸入欄位中輸入或貼上 UTF-8 文字。此工具接受瀏覽器能呈現的任何 Unicode 字元，包括原始輸入中的重音字、CJK 字元和 emoji。
- 執行編碼器，將字串轉換為 UTF-8 位元組，並透過將每個位元組的值加上 U+1F3F7，把每個位元組對應到一個 Base100 碼位。
- 讀取產生的符號流。輸出長度等於輸入的 UTF-8 位元組數，通常每個 ASCII 字元對應一個符號，而每個非 ASCII 字元則對應多個符號。
- 將確切的符號流複製到剪貼簿，不要插入空白、換行或變體選擇器。
- 如果需要將符號流透過其他應用程式傳送，請以純文字貼上，避免使用可能會裝飾 emoji 的所見即所得編輯器。
單一 ASCII 位元組的演算範例。以字元 'A' 為例，在 UTF-8 中它是十進位值 65 的單一位元組。Base100 公式為碼位 = U+1F3F7 + 位元組。代入數值：碼位 = U+1F3F7 + 65 = U+1F438。因此編碼器會將 'A' 替換為單一碼位 U+1F438。一個 N 字元的短 ASCII 字串會產生 N 個符號，而像歐元符號 '€' 這類佔 3 個位元組的 UTF-8 字元則會產生 3 個符號。你看到的總符號數就是編碼後的位元組數，而不是原始 JavaScript 字串長度。
如何將 Base100 解碼回 UTF-8 文字
解碼方向是反轉對應。使用同一個工具，但選擇「Base100 轉文字」模式：
- 將一段有效且未經修改的符號流貼到輸入欄位。每個碼位都必須落在 U+1F3F7 到 U+1F4F6 之間（含端點）。
- 執行解碼器，依 Unicode 碼位走訪輸入，從每個符號中減去 U+1F3F7 以還原其位元組值，並將位元組收集成串流。
- 解碼器會將位元組流送進嚴格的 UTF-8 驗證器。如果位元組構成有效的 UTF-8，工具就會回傳原始文字。
- 如果位元組不是有效的 UTF-8，工具會回報錯誤，而不會插入替代字元或假裝來回轉換成功。
- 讀取結果。空白的輸入會被拒絕、不完整的輸入會被拒絕，任何夾雜的空白、換行或變體選擇器都會讓整段符號流無法通過嚴格驗證。
以 Unicode 碼位而非 UTF-16 碼元來讀取輸入很重要，因為每個 Base100 碼位都位於輔助多語言平面。一個以 UTF-16 碼元逐一走訪的天真 JavaScript 解碼器，會把輔助平面碼位切成兩半，產生錯誤的位元組。此工具會在減去位移量之前先驗證範圍，以避免這種情況。
為什麼 Base100 不是加密或雜湊
Base100 是一種編碼，不是加密法、不是雜湊、不是簽章，也不是隱寫術。對應表是公開的：從有效範圍內的任何碼位減去 U+1F3F7，就會得到原始位元組。任何知道位移量的人都能用一行指令解碼 Base100 符號流，因此 Base100 既不提供保密性，也不提供身分驗證。
它也沒有校驗和、長度標記或防竄改偵測。被改動的符號會改變位元組，但解碼器無法判斷這個改動是有意還是意外。瀏覽器端的驗證器只會標記結構上無效的符號流（例如夾雜空白或超出範圍的碼位），而不會標記語意上遭竄改的內容。
如果要進行 ASCII 安全的傳輸並兼顧機密性，請選擇經過審視的替代方案。十六進位編碼只會產生 0 到 9 與 a 到 f，能在所有文字通道中存活。文字轉十六進位：以正確方式編碼 UTF-8 字串使用不同的字元集，走過相同的 UTF-8 邊界。若需要保密性，請使用你自己掌控金鑰的已驗證加密格式（例如 AES-GCM），或使用標準的密碼管理工具。請勿使用 Base100 來保護密碼、權杖、私鑰或機密訊息。
Base100 符號流解碼失敗的常見原因
大多數解碼失敗來自傳輸環節，而非編碼本身。有些聊天應用程式、鍵盤或正規化管線會在 emoji 後面插入像 U+FE0F 這樣的變體選擇器，以強制顯示彩色版本。這個選擇器不在 Base100 字元集內，因此嚴格解碼器會拒絕該符號流。會自動格式化文字的編輯器可能會插入不斷行空格、零寬連接器或零寬空格，這些東西看起來不可見，卻會增加位元組。有些平臺會把 emoji 替換成外觀相似但位於不同區塊的另一個 emoji，這會把碼位移出 U+1F3F7 到 U+1F4F6 的範圍。
因此，畫面上看起來相似的符號流，在位元組層級上可能與編碼器輸出不同。當互運性很重要時，請以純文字複製符號流，將其貼到十六進位檢視器或碼位檢查工具中確認每個符號都落在範圍內，並避免在編碼器與解碼器之間使用所見即所得編輯器。讓編碼器得以支援任何 Unicode 字元的同一條 UTF-8 界線，正是傳輸應用程式最常打斷來回轉換的地方。
Base100 與其他位元組編碼的比較
Base100 屬於一族位元組到文字的編碼，這些編碼在字元集大小、傳輸安全性與輸出膨脹率上有所不同。十六進位、Base32、Base58 與 Base64 都是為了能在僅限 ASCII 的通道中存活而設計；Base100 則是為了視覺上的醒目而設計，代價是犧牲傳輸安全性。
| 編碼 | 字元集大小 | 符號類型 | 輸出膨脹率（ASCII 輸入） | 備註 |
|---|---|---|---|---|
| Base100 | 256 | Emoji 範圍的碼位 | 1 位元組對應 1 符號 | 視覺醒目，非 ASCII 安全 |
| 十六進位 | 16 | 0-9、a-f | 1 位元組對應 2 字元 | ASCII 安全，易於閱讀 |
| Base32 | 32 | A-Z、2-7 | 5 位元組對應 8 字元 | ASCII 安全，大小寫不敏感 |
| Base58 | 58 | 去除相似字元的英數字元 | 每位元組約 1.37 字元 | 常用於加密貨幣地址 |
| Base64 | 64 | A-Z、a-z、0-9、+、/ | 3 位元組對應 4 字元 | 廣泛支援，ASCII 安全 |
取捨源自字元集大小。Base100 以 1:1 的完美膨脹率換來讓每個符號都移出 ASCII 範圍。十六進位、Base32、Base58 與 Base64 留在 ASCII 範圍內，並以較長的輸出作為相容性的代價。如果目的地接受 emoji 範圍的 Unicode，Base100 能提供最精簡且最易辨識的符號流。如果目的地僅接受 ASCII 傳輸，請改用 Base64、Base58、Base32 或十六進位。
此工具將任一方向的處理量限制為 500,000 位元組或符號，以免一次不慎貼上大量內容造成瀏覽器卡死。空白輸入會被拒絕，輸出絕不會被悄悄截斷，解碼則採用強制性的 UTF-8 驗證。所有處理都在本地端進行：編碼器、位元組到碼位對應器，以及嚴格解碼器都執行於此頁面內，不會上傳你的文字或符號。
想更深入了解，請參閱Linux 上的 Base64 解碼：指令與 UTF-8 注意事項。