文字隱寫術使用四個不可見的 Unicode 碼點——U+2063、U+2064、U+200B 和 U+200C——將一段簡短的 UTF-8 訊息隱藏在看似普通的掩護文字中,而產生的字串在大多數渲染介面中看起來與原始句子完全相同。文字隱寫術工具所採用的慣例是明確且可檢驗的:每個隱藏的 UTF-8 位元組會展開為八個零寬度碼點,由一個不可見的起始與結束標記框住,並插入到掩護文字的第一個可見碼點之後。解碼模式會讀回這些完全相同的碼點,驗證框記、位元數與 UTF-8 位元組的有效性,並重建出原始的隱藏訊息與原始的可見掩護文字。由於此技術完全依賴於預設可忽略的 Unicode,任何知道對應關係的人都能解碼訊息,而任何會清除這些碼點的清理工具也會將其徹底銷毀。所有處理都在瀏覽器中進行,因此掩護文字與密文在任何階段都不會上傳到伺服器。
四個不可見碼點一覽
在此慣例中,文字隱寫術正是由這四個碼點構成。它們在一般字型中都不會產生墨痕,但在框內片段中各自扮演明確的角色。把這張表記住,後續的工作流程就能順利接上。
| 碼點 | 名稱 | 在框內酬載中的角色 |
|---|---|---|
| U+2063 | 不可見分隔符 | 標示框內酬載片段的起始位置。 |
| U+2064 | 不可見加號 | 標示框內酬載片段的結束位置。 |
| U+200B | 零寬度空格 | 代表酬載中的二進位 0 位元。 |
| U+200C | 零寬度非接合符 | 代表酬載中的二進位 1 位元。 |
此慣例定義每個隱藏位元組使用八個酬載位元,並採最高位元優先順序書寫,因此單一個 ASCII 字元會展開成連續八個零寬度碼點。兩個框記標記在整段位元串的前後各出現一次,而不是圍繞每個位元組。若你在非預期的位置看到這些碼點,請將其視為慣例的一部分,而不是一般文字。落在框內片段之外的普通零寬度字元仍屬於可見掩護的一部分,不會被解讀為酬載位元;解碼模式只會取出第一個有效的框內片段,而不是在框記看起來模糊不清時任意猜測。
在掩護文字中隱藏 UTF-8 訊息
開啟文字隱寫術工具並選擇隱藏模式。該工具會對每次提交執行三項動作,全部都在瀏覽器中完成:將隱藏訊息編碼為 UTF-8 位元組、依上表將每個位元組展開為八個零寬度碼點,並將框內片段插入到掩護文字的第一個可見碼點之後。掩護文字中不得已包含起始標記 U+2063 或結束標記 U+2064,因為接受任一者會使酬載邊界變得模糊。
- 在掩護欄位中輸入可見的掩護文字。請保持夠短以預留展開空間;工具會拒絕超過 100,000 個碼點的掩護文字。
- 在密文欄位中輸入隱藏的 UTF-8 訊息。隱藏訊息上限為 10,000 個 UTF-8 位元組;表情符號與 CJK 字元通常各佔數個位元組,因此可見字元數會小於位元組數。
- 產生隱寫字串並複製精確的輸出結果。請勿重新輸入,也不可讓編輯器對結果進行正規化、自動校正或重新排版。
- 在傳送之前,先在本地將結果貼回解碼模式進行驗證。若還原出的隱藏訊息與掩護文字皆與原本一致,則此機器的來回測試是乾淨的。
從貼上的文字中解出隱藏訊息
解碼模式是隱藏模式的反向操作,使用相同的四個碼點。它會掃描貼上的文字以尋找起始標記,檢查每個酬載字元是否為兩個位元符號之一,要求位元數為八的倍數,將位元轉回位元組,並拒絕任何無效的 UTF-8 位元組序列。框記格式錯誤時會產生明確的錯誤,而不是猜測酬載內容,這能在傳輸過程中有一或多個不可見字元遺失時,避免發生靜默毀損。
- 將文字隱寫術工具切換到解碼模式。
- 將收到的隱寫字串原樣貼上。請勿修剪、重新排版、執行搜尋取代,也不要先送進「清理文字」之類的工具處理。
- 讀取還原後的隱藏訊息與掩護文字。還原後的掩護文字應與原始可見句子逐字元一致。
- 若解碼失敗,請比較傳送端與接收端字串的原始碼點,以找出哪個應用程式移除或變更了不可見字元。字元計數器、差異比對工具或原始碼檢視器會立即顯示出遺失的位元。
酬載與掩護限制一覽
兩項硬性上限讓渲染後的 DOM 保持流暢,也讓位元數可預期。它們適用於單次隱藏/解碼操作,而非整個工作階段。
| 限制 | 數值 | 存在的原因 |
|---|---|---|
| 隱藏訊息大小 | 10,000 UTF-8 位元組 | 限制位元數,以保持 DOM 渲染的流暢度。 |
| 掩護文字大小 | 100,000 碼點 | 限制可見字串長度與框內插入的位置。 |
| 位元展開 | 每個隱藏位元組展開為 8 個不可見碼點 | 每個位元對應一個不可見碼點,採最高位元優先。 |
| 框記成本 | 每段酬載 2 個不可見碼點 | 一個起始標記 (U+2063) 與一個結束標記 (U+2064)。 |
| 掩護限制 | 掩護中不得存在 U+2063 或 U+2064 | 既有的標記會使酬載邊界變得模糊。 |
計算範例:長度為 5 個 ASCII 字元的隱藏訊息會成為 5 個 UTF-8 位元組。以每個位元組 8 位元計算,位元串為 5 × 8 = 40 個不可見碼點。加上兩個框記標記後,共 40 + 2 = 42 個不可見碼點,插入到掩護文字的第一個可見碼點之後。這就是底層 Unicode 序列的總成長量,即便一般字型讓這 42 個碼點完全不佔寬度。若同樣的訊息改用表情符號或 CJK 字元書寫,每個可見字元通常會展開成數個 UTF-8 位元組,使可見字元數遠低於位元組上限。
清理風險與如何驗證來回一致性
上述四個碼點皆為預設可忽略,這代表許多文字處理系統會將它們視為可移除的雜訊。根據Unicode 安全考量報告,預設可忽略的碼點在正規化、複製/貼上、編碼轉換與安全掃描過程中會經常被移除。而這恰恰是隱寫酬載所棲身之處,因此對此技術而言,傳輸失敗是常見的風險。
依可靠程度排序的實務傳輸管道類別:
- 單一機器上的純文字編輯器與終端機複製/貼上——通常能從頭到尾保留完整的 Unicode 序列。
- UTF-8 檔案在機器之間以原樣進行檔案傳輸——通常能保留,前提是兩端都沒有對檔案進行正規化。
- 社群網路、電子郵件閘道、聊天程式與內容管理系統——經常會移除預設可忽略的碼點或置換換行符號,即便可見文字看起來完全相同。
- 螢幕截圖、螢幕照片與列印副本——完全無法承載不可見碼點,因為這些碼點並沒有可被擷取的渲染形式。
在依賴某次傳遞之前,請務必在接收端機器上執行最終的解碼。若還原出的隱藏訊息與掩護文字與原本一致,即代表傳輸成功。若不一致,即表示中介應用程式移除或重寫了某些不可見碼點,訊息已遺失。
文字隱寫術做不到的事
本工具僅提供已公開文件記載之酬載的隱藏功能,僅此而已。UTF-8 位元組與零寬度碼點之間的對應關係已於上方公開;任何偵測到框記與位元符號的人皆可解碼訊息。隱寫術並不提供機密性、真實性或完整性,第三方也能在不留任何可見痕跡的情況下竄改隱藏的位元組。對於敏感性資料,請先以經過審核的系統進行加密——同類別中的AES 加密線上工具可在瀏覽器內處理經認證的 AES-256-GCM——再僅使用本工具將密文包裹於掩護文字中,以用於謎題、展示或清理測試。請勿用於隱藏憑證、危害性指令、個人資料或違反平台規範的內容。若需可靠的資料交換,請優先採用可見編碼或具認證機制的檔案格式。
如需更深入的說明,請參閱如何將文字轉換為二進位代碼:逐位元組精確的 UTF-8。
如需更深入的說明,請參閱大量文字轉十六進位:安全地編碼大型 UTF-8 文字。