Windows 上的文字隱寫術，是指將一段隱藏的 UTF-8 訊息嵌入到外觀普通的掩護文字中，做法是在可見字串裡插入零寬度的 Unicode 字元，而所有編碼與解碼作業都在現代瀏覽器內本機執行。掩護句子在人眼閱讀時仍然一模一樣，但其底層的代碼點序列如今在 U+2063 與 U+2064 標記之間，於第一個可見代碼點之後，夾帶了一組由 U+200B 與 U+200C 位元所構成的有框承載內容。由於完全不需要安裝或上傳任何東西，因此這項技術可在任何執行 Edge、Chrome 或 Firefox 的 Windows 10 或 Windows 11 機器上運作，包括沒有系統管理員權限的受限帳戶。其限制在於傳輸:Windows 應用程式處理隱形字元的方式差異極大，而大多數聊天、郵件及富文字系統會在訊息送達收件者之前就剝除承載內容。本文將逐步說明 Windows 上的具體作法:如何隱藏訊息、Windows 上哪些複製通道能保留零寬度 Unicode，以及如何解出結果，讓你在依賴它之前先驗證整個來回過程。
Windows 瀏覽器中的文字隱寫術如何運作
這套基於瀏覽器的文字隱寫術工具採用的是一套明確且有完整文件的慣例，而非某種不公開的專有格式。隱藏的 UTF-8 訊息會一次展開一個位元組，從最高有效位元開始，並將每個位元分別寫成兩個零寬度字元之一:U+200B 代表二進位 0,U+200C 代表二進位 1。整段位元串會被包裹在一個隱形分隔字元 (U+2063) 與一個隱形加號 (U+2064) 之間，然後插入掩護文字中第一個可見代碼點之後。由於每個隱藏位元組都會轉換成八個額外的代碼點，再加上兩個框式標記，因此最終字串會遠比原始文字長得多，即便大多數字型賦予這些字元的寬度為零。
解出模式以相反順序執行相同的邏輯。它會搜尋 U+2063/U+2064 框，檢查框內每個字元是否都是兩個位元符號之一，要求位元數必須為八的倍數，將位元轉回位元組，並拒絕任何不是有效 UTF-8 的位元組序列。任何步驟一旦失敗，工具會回報錯誤，而不是自行猜測。解出的掩護文字會與隱藏訊息一併回傳，讓你能夠確認還原結果逐位元組相符。如果想更深入了解為何挑選這些特定的代碼點，零寬度 Unicode 基礎逐步解說也以同樣的慣例進行說明。
三步驟隱藏並解出訊息
- 輸入掩護文字與秘密訊息，然後產生結果。在 Edge、Chrome 或 Firefox 中開啟文字隱寫術頁面。輸入或貼上一段普通的掩護句子(最多 100,000 個代碼點)，以及一段獨立的隱藏 UTF-8 訊息(最多 10,000 位元組)。按下產生動作，並完全照原樣複製所產生的隱寫字串，不要重新輸入。
- 透過能保留零寬度字元的通道複製。在 Windows 上，最安全的做法是使用以 UTF-8 編碼檔案開啟的純文字編輯器，例如 Notepad、Notepad++ 或 Visual Studio Code，或是採用 Set-Clipboard 的 PowerShell 工作階段。請避免使用 Word、Outlook、Teams、Discord、社群網路，以及任何會開啟富文字編輯器的系統。
- 貼入解出模式並驗證兩項輸出。在同一個工具中切換到解出模式，不經任何清理直接貼上收到的字串，確認解出的隱藏訊息與你送出的內容一致，且可見的掩護文字與你原始句子逐位元組相符。如果解出失敗，幾乎可以肯定是所使用的通道剝除了隱形字元。
Windows 上能保留或會破壞承載內容的通道
Windows 內含異常多元的文字處理管線，而每一種對「預設可忽略」代碼點的處理方式都不同。下表根據工具文件中對清理行為的描述，將常見的 Windows 通道粗略分入不同風險層級;請把它當作起點，不要當作保證，在實際依賴某個通道傳送真實資料之前，務必自行執行端對端測試。
| Windows 上的通道類別 | 是否可能保留 U+200B / U+200C / U+2063 / U+2064 | 備註 |
|---|---|---|
| 以 UTF-8 編碼的純文字編輯器(Notepad、Notepad++、VS Code) | 會 | Windows 上最安全的選項。以 UTF-8 儲存並重新載入，不需要 BOM。 |
| Windows 10/11 上的 PowerShell Set-Clipboard | 通常會 | 短字串可正常運作;較長的承載內容可能會被截斷或正規化。 |
| 瀏覽器在兩個分頁之間的複製與貼上 | 通常會 | 在沒有富文字目標介入時，Edge 與 Chrome 會保留零寬度字元。 |
| 富文字編輯器(Word、Outlook 新郵件、OneNote) | 很少會 | 格式化的處理過程，常常會在儲存或傳送時移除「預設可忽略」的代碼點。 |
| 聊天與郵件閘道(Teams、Outlook 網頁版、Gmail 撰寫介面、Discord) | 很少或絕不會 | 伺服器在訊息遞送前會對標記代碼點進行正規化、篩選或拒絕。 |
| 社群網路、CMS 編輯器、帶有清理機制的 pastebin | 絕不會 | 「預設可忽略」字元會在接收時被剝除。 |
| 螢幕擷圖、畫面分享、列印副本、OCR | 絕不會 | 隱形代碼點沒有像素可供擷取。 |
Windows 上最常見的單一失敗模式，就是把內容貼入富文字編輯器後再複製出來:格式化引擎會悄悄移除它認定為隱形的字元，導致收件者看到的只是一段沒有承載內容的掩護句子。Unicode Security Considerations技術報告同樣列出了這類清理問題，並說明為何內容系統經常會剝除「預設可忽略」的代碼點。如果你別無選擇必須透過高風險通道傳送隱寫文字，請把結果視為一次探測:如果另一端的解出模式能還原你的訊息，代表這個通道可用;如果不行，就換一個通道。
限制、驗證，以及解出步驟所能抓到的問題
該工具強制設有兩項硬性上限，這在 Windows 上特別重要，因為極長的字串會拖慢 DOM 渲染速度。隱藏訊息上限為 10,000 位元組的 UTF-8，掩護文字上限為 100,000 個代碼點。表情符號與 CJK 字元每個可能佔用數個 UTF-8 位元組，因此你秘密訊息的可視字元數通常會小於位元組上限。掩護文字本身不得含有 U+2063 或 U+2064 標記，因為一旦接受，承載內容的邊界就會變得模糊;落在框式區域之外的一般零寬度字元則會被視為可見掩護文字的一部分，並會在來回過程中原樣保留。
解出模式刻意設計得很嚴格。當起始或結束標記缺失、框內任何字元不是 U+200B 或 U+200C、位元數不是八的倍數、或所得位元組序列不是有效的 UTF-8 時，它都會回報錯誤。工具只會取出第一個有效的框式區段，因此當掩護句子剛好以錯誤的順序同時含有兩個標記時，仍會遭到明確拒絕，而不是發生靜默損毀。可見的一致永遠不等於位元組的一致:兩段字串可以呈現完全相同的樣貌，代碼點序列卻相差數百個隱形字元，這正是這套慣例的目的，也正是為什麼只要有人知道該從何處著手，字元計數器、差異比對工具或十六進位檢視器都能立刻揭穿承載內容。
當你需要的是真正的加密，而不是單純隱藏
隱寫術隱藏的是訊息的存在，而不是其含義。任何知道 U+200B / U+200C / U+2063 / U+2064 對應關係的人，都能解出承載內容;任何擁有編輯權限的人，也能在不被察覺的情況下竄改隱藏的位元。若是密碼、API 權杖、個人資料，或任何在傳輸過程中必須保密的內容，請先使用經過審查的加密原語(例如 AES-256-GCM 或公開金鑰系統)加密訊息，若同時還需要合理的否認空間，再用本工具嵌入加密後的密文。請勿使用本頁面來隱藏憑證、具傷害性的指示，或違反平台規定的素材;許多能保留承載內容的通道，往往也是最可能遭到監控的通道，而框式標記本身對自動化掃描器來說，看起來就像是一條隱蔽通道。
具體到 Windows，實務上的建議很簡短:讓掩護文字保持在你可逐一檢查的長度，優先選用你親自測試過的純文字檔案或直接剪貼簿傳輸，並在收到字串後，一律先執行解出模式再相信傳送結果。若需要持久的資料交換，請改用可見的編碼方式，例如 Base64 或經過身分驗證的檔案格式;工具的文件已明確指出，來回測試只能證明此實作的正確性，而無法保證通過任何特定外部服務時仍能存活。
想更深入了解，請參閱二進位對應文字圖表:讀取 8 位元 UTF-8 位元組。