在 Mac 上的文字隱寫術，意指將一段隱藏的 UTF-8 訊息，透過插入零寬度 Unicode 字元(這些字元在顯示時沒有可見寬度)，嵌入到一個普通句子中，之後再於本機上執行的任何現代瀏覽器中將該訊息取出。在視覺上，掩護句子保持不變，但一段簡短的秘密訊息就藏在它底層的碼位序列中，由文件化的隱藏標記框住，以便「解碼」模式能定位出精確的酬載。在 macOS 上，這個工作流程特別容易取得，因為每台近期的 Mac 都內建 Safari、Chrome 或 Firefox，而且整個編碼與解碼的來回過程都在瀏覽器分頁內完成——不需要 Homebrew 套件、不需要簽署過的安裝程式、不需要 Terminal 工作階段，也永遠不會將任何檔案上傳到遠端伺服器。這個慣例是明確的，而不是神奇的:一個隱藏分隔符標記酬載的開始，一個隱藏加號標記結束，一個零寬度空格編碼二進位零，一個零寬度不連字元編碼二進位一。每個隱藏的 UTF-8 位元組會在第一個掩護字元之後展開為正好八個不可見的碼位，而解碼模式在還原的過程中會把原本的掩護碼位序列還原回來。渲染後的結果在大多數字型中看起來就像一個普通句子，但實際上是一條長得多的 Unicode 字串，這正是重點所在，也是 Mac 使用者在透過訊息、郵件、備忘錄或第三方聊天用戶端傳送任何內容之前，都應該了解的所有陷阱的根源。
為什麼 Mac 使用者通常會選擇瀏覽器而非原生應用程式
市面上存在少數原生 macOS 隱寫工具，包括歷史上曾維護過的 Steganography Tool、Text Secret 和 Natural Language Stegen 等，但它們大多已無人維護、最後一次更新都是針對較舊的 macOS 版本，而且都是以舊版二進位檔的形式發佈，不僅有公證上的阻礙，磁碟佔用空間也高達數百 MB。若要快速、可逆地將一段簡短註記嵌入普通句子中，基於瀏覽器的零寬度方法完全省去了安裝這一層:打開 Safari 或 Chrome，輸入掩護句子，輸入秘密訊息，複製結果。沒有東西需要編譯，沒有「隱私與安全性」的覆寫要點擊，也不會有 Gatekeeper 警告擋住這個一次性的工作。由於每個步驟都在單一分頁內完成，同一個工具也能在接收端的 Mac 上把酬載解回同一個瀏覽器，所以整個來回過程是對稱且自足的。
Mac 使用者傾向選擇這條路的另一個原因是資料本地性。掩護文字和隱藏訊息永遠不會離開這台機器，當酬載是私人註記、謎題答案或清理測試，而非你願意交給遠端服務的內容時，這點相當重要。原生 macOS 應用程式往往也會要求完整的磁碟或輔助使用權限，而瀏覽器分頁則不會，這使得受攻擊面與權限提示都維持在很小的範圍。對於只想示範 Unicode 如何承載不可見內容的 Mac 使用者來說，瀏覽器這條路是阻力最低、卻仍能產生真實且可檢視結果的選項。
慣例背後的四個碼位
文字隱寫工具所使用的編碼方案依賴正好四個 Unicode 碼位，每個都扮演單一、有文件記載的角色。它們合力讓同一套慣例能描述酬載邊界、編碼每個位元，並保持可逆性。
| 角色 | 碼位 | 功能 |
|---|---|---|
| 隱藏分隔符 | U+2063 | 標記隱藏位元組序列的開始 |
| 隱藏加號 | U+2064 | 標記隱藏位元組序列的結束 |
| 零寬度空格 | U+200B | 代表二進位 0 位元 |
| 零寬度不連字元 | U+200C | 代表二進位 1 位元 |
隱藏的 UTF-8 訊息會先轉成位元組，再轉成最高有效位在前的位元字串，接著轉成零寬度空格與零寬度不連字元的序列。該序列左邊以隱藏分隔符、右邊以隱藏加號包起來，整個框起來的序列會緊接在掩護文字的第一個可見碼位之後插入。解碼模式會搜尋這些標記，確認中間每個字元都是兩種位元符號之一，要求位元數為八的倍數，再將其轉回位元組，若這些位元組無法解碼為有效的 UTF-8 則會拒絕該序列。由於每個步驟都可檢視，這套慣例刻意公開其對應方式，而非將之隱藏。
第二張表格讓酬載大小與插入碼位數之間的關係更容易推敲，而不需要在多列之間做運算:
| 隱藏訊息 | 使用的位元組 | 新增的不可見碼位 |
|---|---|---|
| 像 hi 這樣的簡短 ASCII 標籤 | 2 位元組 | 16 個位元字元加上 2 個標記 = 18 |
| 單個 CJK 字元 | 3 位元組 | 24 個位元字元加上 2 個標記 = 26 |
| 像 👍 這類表情符號 | 4 位元組 | 32 個位元字元加上 2 個標記 = 34 |
| 接近上限的長詞組 | 10,000 位元組 | 80,000 個位元字元加上 2 個標記 = 80,002 |
計算範例:像 hello 這樣的五字元 ASCII 秘密訊息佔用 5 個 UTF-8 位元組。每個位元組展開為 8 個不可見位元，共得到 40 個位元字元。再加上分隔符與隱藏加號兩個標記，整個框起來的區域會在第一個可見的掩護字元之後插入正好 42 個不可見的碼位。
在 Mac 瀏覽器中隱藏與解開一段訊息
在 macOS 上，完整的來回過程只需三個簡短步驟，而且全部在同一個瀏覽器分頁內完成。不需要 Terminal、不需要 Python、不需要額外下載。
- 在 Mac 上用 Safari、Chrome 或 Firefox 開啟文字隱寫頁面。在可見文字欄位中輸入一段看似普通的掩護句子，在秘密訊息欄位中輸入一段簡短的隱藏 UTF-8 訊息，然後觸發編碼動作以產生隱寫字串。
- 透過能保留零寬度 Unicode 字元的管道，複製精確的隱寫結果——例如，以純文字模式開啟的 TextEdit 本機純文字檔、你剪下後貼到另一份本機文件的剪貼簿，或是你先前已端對端驗證過的管道。不要重新輸入結果、不要用螢幕擷圖，也不要透過會正規化空白字元或移除預設可忽略碼位的服務來貼上。
- 在接收端的 Mac 上開啟同一個頁面(或把結果貼回同一台 Mac 上的一個新分頁)，切換到解碼模式，並在不做任何清理的情況下貼上隱寫字串。該工具會回報還原出的隱藏訊息，並還原出精確的可見掩護文字。若解碼模式回報錯誤，代表不可見字元在傳輸過程中遺失了，而非在編碼端損壞。
若你的傳遞管道比本機檔案更特殊——例如 AirDrop 傳給另一台 Mac、USB 隨身碟、或 Notes.app 中的快速備忘錄——請先用一個已知的秘密訊息測試完整的來回過程。編碼是容易的部分;真正會變動的是傳輸環節。
macOS 應用程式與剪貼簿會對不可見碼位做些什麼
在 Mac 上，最常見的失敗模式就是不可見字元遺失。這套慣例使用了屬於「預設可忽略」Unicode 類別的碼位，這意味著 macOS 端的許多軟體會把它們視為裝飾性質而悄悄移除。已有文件指出，郵件用戶端、聊天用戶端和內容管理系統會在輸入或輸出時對文字進行正規化、過濾或重新序列化。社交網路在這方面特別激進，會積極地將其剝除。甚至 macOS 上某些剪貼簿管理程式、終端機模擬器和 RTF 編輯器，也會重寫貼上的字串，將 U+200B 與 U+200C 字元連同所有框住用的標記一起丟掉，在這種情況下，解碼模式看到的會是空酬載，而不是損壞的酬載。
螢幕擷圖與列印副本根本無法承載不可見碼位，因為像素緩衝區並不儲存 Unicode 字串。由螢幕擷圖產生的 PDF 也會失去這些字元，除非保留了文字圖層。這正是這類隱寫術的用途在於示範 Unicode 如何承載不可見內容、製作無害的謎題，或稽核傳遞管道，而不是用來承載任何必須在未知或敵對傳輸環境中存活的內容的原因之一。
在 macOS 端，最能保留框住序列的路徑為:在 TextEdit 中將格式設為純文字(而非 RTF)的純文字檔、以 Unicode 乾淨的編輯器(如 BBEdit 或 VS Code)開啟的 UTF-8 檔案、把原始字串以 AirDrop 投送到另一台 Mac 上的一則純文字備忘錄，或是直接複製到剪貼簿後，中間不經任何編輯器就直接貼到解碼模式。最脆弱的路徑則包括:任何 RTF 目的地、會在你輸入時自動套用格式的聊天用戶端，以及任何在 JavaScript 清理器執行後才接受輸入的網頁表單。
限制、清理風險，以及何時應加上真正的加密
隱藏訊息的上限為 10,000 個 UTF-8 位元組，掩護文字的上限則為 100,000 個碼位，這些上限並非任意設定:每個位元組會額外增加八個碼位，再加上兩個框住用的標記，而龐大 DOM 的渲染成本若不設限，將會主宰整個頁面。表情符號與非拉丁字元每個可能佔用數個 UTF-8 位元組，因此你能隱藏的可見字元數通常會小於位元組上限所暗示的值。掩護文字本身不得包含這套慣例的開始或結束標記，因為若接受了其中之一，將使酬載邊界變得模糊;然而，框住區域外的一般零寬度字元仍屬於掩護文字的一部分，會在來回過程中被保留。解碼模式也會拒絕格式不正確的輸入，而不是產生「文字上看似正確但實際錯誤」的資料:缺少標記、位元數不是八的倍數，或無法解碼為有效 UTF-8 的位元組序列，這些情況都會以明確錯誤呈現，而不是悄悄替換。
隱寫術本身並不提供機密性、真實性或完整性。其對應方式已有文件記載，任何偵測到的人都能解碼，任何人都能加以竄改。Unicode 安全考量技術報告明確警告，預設可忽略的碼位可能承載隱藏內容，處理器應對這類字元的意外出現抱持懷疑態度。若是憑證、個人資料，或任何平台條款禁止的內容，在嵌入之前請先以經過審核的系統對酬載進行加密，然後再決定這套慣例是否適合作為該特定管道的一層額外保護。
Verifying the Round Trip Before You Trust the Channel
Before sending a real secret through any new macOS path, send a known test message first. A simple test is a three-character ASCII tag hidden inside a cover sentence such as Meeting at noon. Encode it on Mac A, transport the result through the channel you intend to use, decode it on Mac B, and confirm that reveal returns exactly the expected tag and a cover that matches Meeting at noon. byte-for-byte. If the recovered cover has different line endings, missing zero-width spaces, or extra whitespace, the channel sanitized your payload and you need a different transport.
A second useful test is to count the code points of the recovered string with a Unicode inspector. The encoded string should contain the cover length plus the framed payload plus the markers; if the count is shorter, characters were stripped. Because every bit is one of two well-known code points and every byte is a valid UTF-8 sequence, any deviation from the documented shape is the channel's fault, not the encoder's. This convention deliberately publishes every marker, every bit symbol, and every limit so the transformation stays inspectable and reversible end to end, which is the only honest promise a steganography tool can make on macOS today.
For readers who want to compare this browser-only path against Terminal-based approaches for related text work on macOS, the Binary to Text on Mac without using Terminal guide walks through a similarly local workflow that also runs entirely inside Safari or Chrome.
Related reading: Binary to Text: Decode Strict 8-Bit UTF-8 Bytes.