Base100 編碼在 Mac 上完全在瀏覽器內執行，無需安裝，只要透過 Safari、Chrome、Firefox 或任何其他現代 macOS 瀏覽器造訪 Base100 編碼 / 解碼頁面即可使用。編碼器會將您的 UTF-8 文字轉成位元組流，然後將每個位元組對應到介於 U+1F3F7 到 U+1F4F6 之間(包含兩端)的單一 Unicode 碼位，方式是將位元組值加上基底碼位，產生由 256 個不同表情符號範圍符號所組成的流。解碼則反向進行，減去 U+1F3F7 以還原每個位元組，再將還原後的位元組透過嚴格的 UTF-8 解碼器處理，最後輸出原始文字，或在輸入無效時回報錯誤。每個步驟都由 JavaScript 在您 Mac 的 CPU 上執行，因此輸入內容永遠不會被上傳、記錄，或透過網路分頁離開裝置。由於對應方式純粹是位元組對碼位的公式，macOS 上唯一需要留意的是字型呈現、剪貼簿行為，以及當您將符號貼回時，目的端應用程式是否會悄悄插入變體選擇符。
為什麼瀏覽器分頁在 macOS 上勝過原生 CLI
原始的 Base100 實作是一個 Rust 二進位檔，封裝於 GitHub 上的 Cargo crate;在 macOS 上這代表必須先安裝 Rust 工具鏈、複製儲存庫、執行建置指令，才能產生第一個表情符號。以瀏覽器為基礎的工具則完全免去這些步驟:沒有 Homebrew 相依性、不需要設定 PATH、不會出現 Gatekeeper 警告，也無需在格式演進時持續更新二進位檔。編碼演算法本身小到可用數 KB 的 JavaScript 封裝，因此即使在 MacBook Air 上透過計量付費網路，頁面仍能快速載入。Safari、Chrome、Firefox 與 Arc 皆以相同方式執行同一段 JavaScript 流程，因為 WHATWG 編碼標準在各瀏覽器引擎上以一致的方式定義 UTF-8 邊界，詳情記載於 encoding.spec.whatwg.org。
對於偶爾的單次編碼任務，這個權衡毫無模糊空間:開啟單一分頁所花的時間比安裝 Rust 工具鏈更少，而且結果逐位元組完全相同，因為底層公式就是上游專案所公布的對應方式。對於已備妥 Rust 或 Go 環境、並希望在建置管線中以腳本執行 Base100 的進階使用者，則以 AdamNiederer/base100 儲存庫中所記載的命令列路徑為合適選擇，但大多數讀者搜尋「base100 encode on mac」時，尋找的並非該工具。
在 macOS 的 Safari 或 Chrome 上進行 Base100 編碼
- 啟動 Safari(預設的 macOS 瀏覽器)或 Mac 上安裝的任何其他現代瀏覽器，例如 Chrome、Firefox、Brave 或 Arc。
- 前往 Base100 編碼 / 解碼頁面，讓轉換用的 JavaScript 載入一次，並在本次工作階段中保持離線可用。
- 點選「Text to Base100」分頁以展開編碼面板;解碼面板位於其側，在您切換之前會維持未啟用狀態。
- 在輸入框中輸入或貼上您的 UTF-8 文字。標準的 Cmd+A 再 Cmd+V 在此欄位中與任何 macOS 文字輸入的運作方式相同，而且輸入內容並不會透過網路外傳。
- 點選 Run 或 Encode 按鈕以觸發逐位元組對應。結果面板會填入代表您文字中每個 UTF-8 位元組的符號流。
- 在結果面板上按下 Cmd+C，或點選頁面所提供的 Copy 按鈕，將精確的碼位放上 macOS 剪貼簿。請勿按下 Return、新增空格，或插入換行:對應是位置性的，任何多餘字元都會在解碼時成為無效位元組。
- 將符號貼到目的端 — 例如聊天應用程式、檔案，或另一個編碼器(如 Base64 編碼 / 解碼工具)— 並在實際用於正式環境前先將其解碼回來，以驗證整個往返流程。
在 Mac 上將 Base100 符號解碼回文字
反向操作與編碼同樣重要，因為複製貼上管線幾乎都會經歷往返。在同一頁面上，點選「Base100 to text」分頁，從剪貼簿貼上未經修改的符號流，然後執行解碼器。該頁面會從每個碼位減去 U+1F3F7，收集所得位元組，並透過嚴格的 UTF-8 解碼器進行處理。若任何字元落在 U+1F3F7 到 U+1F4F6 之外 — 包括空格、換行、一般標點、變體選擇符，或落在 256 符號視窗外的對應碼位 — 工具便會拒絕輸入，而不是靜默地以 U+FFFD 替代。這種嚴格性可保護您不會從訊息對話中複製到一個外觀相似、但逐位元組不同的流。
嚴格解碼器會攔下的情況
- 編輯器在複製貼上過程中可能插入的空格、Tab 與換行字元。
- macOS Messages 在貼上時有時會附加到表情符號的變體選擇符 U+FE0F。
- 落在 Base100 視窗外的碼位，包括 U+1F4F6 以上的所有標準表情符號。
- 位元組無法構成有效 UTF-8 序列的截斷或填充流;解碼器會回報錯誤，而不是產生亂碼。
Mac 專屬的陷阱:變體選擇符、字型與剪貼簿行為
Base100 的對應是數學式的，但您在 Retina 顯示器上看見的內容，則取決於 macOS 內建的 Apple Color Emoji 字型、macOS 版本，以及目的端應用程式是否套用自身的表情符號替換。在 Sonoma 與 Sequoia 上，某些對應碼位會呈現為彩色圖像，其他則可能在較舊版本上顯示為單色字形、後備方框，或未預期的符號。呈現差異並不會改變底層碼位，因此複製一個看起來像青蛙的符號，所攜帶的位元組仍如您所預期;但若透過會悄悄插入 U+FE0F 的聊天應用程式複製該符號，則會在下游的嚴格解碼中造成破壞。
三個習慣能避免大多數 macOS 上的往返失敗。第一，使用頁面的 Copy 按鈕複製 Base100 輸出，而不是用滑鼠選取;因為手動選取在非常長的流上可能會漏掉尾端的碼位。第二，先貼到純文字目的端(例如純文字模式的 TextEdit 或 BBEdit)，再將符號轉發到任何可能對其進行正規化的地方。第三，在同一台 Mac 上將結果解碼回原始文字，然後再將此次往返視為可靠;若解碼失敗，問題出在複製管線，而非編碼器。
Mac 使用者的逐位元組對應參考
了解精確公式，有助於您在貼上之前預測流的大小。下方表格列出幾個錨點;其他每個位元組皆位於其相對於 U+1F3F7 的偏移處。
| 輸入位元組 | 對應碼位 | 計算方式 |
|---|---|---|
| 0 | U+1F3F7 | 基底偏移，無加法 |
| 1 | U+1F3F8 | U+1F3F7 + 1 |
| 65(ASCII 'A') | U+1F438 | U+1F3F7 + 65 |
| 128 | U+1F477 | U+1F3F7 + 128 |
| 255 | U+1F4F6 | U+1F3F7 + 255(範圍頂端) |
由於對應為一位元組一符號，因此像「hello」這種純 ASCII 訊息，會剛好產生五個 Base100 符號。含有變音符號、CJK 字元或表情符號的非 ASCII 訊息，則會產生比字元數更多的符號，因為每個 Unicode 字元通常會展開為多個 UTF-8 位元組，而每個位元組都會成為一個符號。例如，「é」的雙位元組 UTF-8 編碼會將單一字元轉為兩個符號;一個四位元組的表情符號會將單一字元轉為四個符號。當您的目的端有長度上限時，請據此規劃貼上預算。
實作範例:在 Mac 上編碼「Hi」
若想看公式實際運作，請在瀏覽器工具中編碼兩個字元的 ASCII 字串「Hi」。該字串會以 UTF-8 轉成位元組 [0x48, 0x69]。位元組 0x48 為十進位 72，對應到碼位 U+1F3F7 + 72 = U+1F43F。位元組 0x69 為十進位 105，對應到碼位 U+1F3F7 + 105 = U+1F460。因此，無論 macOS 為這兩個碼位繪製多少字形，符號流都剛好包含兩個碼位;解碼器只要反向執行兩次減法並重新解碼該 UTF-8 位元組對，即可還原原始的「Hi」。符號數永遠等於位元組數，而非字元數，這是初次使用者最容易感到意外的一點。
限制、安全性，以及何時該選擇不同的編碼
瀏覽器實作將任一方向的單次操作上限設為 500,000 位元組或符號，以避免一次意外的大貼上讓分頁當機。空白輸入在兩側皆會遭到拒絕，輸出永遠不會被靜默截斷，而解碼則採用嚴格的 UTF-8 驗證，會回報錯誤，而不是以 U+FFFD 取代錯誤位元組。這些防護是有意為之:此編碼旨在保持精確，因此工具拒絕假裝一個被竄改的流是有效的。
Base100 同時也不是加密、雜湊、簽章或身分驗證。任何持有對應表的人都能在數秒內還原文字，且沒有任何校驗和可用來偵測竄改。當機密性或防竄改偵測至關重要時，請使用經審核的加密格式，例如 AES Encryption Online 工具。同樣地，若目的端僅接受 ASCII 傳輸，請改用 Base64、十六進位或 Base32，而非 Base100，因為 Base100 符號位於輔助多語言平面上，許多較舊的傳輸通道會將其破壞。
Mac 使用者的快速工作流程摘要
在 macOS 上最短且可靠的路徑為:在 Safari 中開啟 Base100 Encoder / Decoder，編碼文字，使用頁面的複製按鈕複製，貼到純文字欄位，在同一頁面上將結果解碼回來以確認往返，然後再將符號轉送至目的端。跳過「解碼回來驗證」這一步，是「看起來正常但位元組錯誤」回報最常見的原因，因為 macOS 剪貼簿行為與接收應用程式的文字處理，是整條管線中編碼器無法掌控的唯一環節。
若想進一步了解，請參閱 在 iPhone 上進行二進位轉文字:無需 App，直接使用 Safari。
若想進一步了解，請參閱 CRC32 計算器 API 替代方案:在瀏覽器中本機執行。