文字隱寫術對於示範、解謎以及教學 Unicode 如何承載不顯示的資料是安全的，但作為機密或經驗證的管道並不安全。零寬度字元與位元之間的對映關係已完整記載，因此任何辨識出標記的人都能解讀訊息，任何人也都能在不被察覺的情況下竊改它。文字隱寫術工具會在您的瀏覽器中本機處理每個位元組，因此您的掩護文字與隱藏訊息絕不會離開您的裝置 — 這部分的安全性確實是真的。它無法保證的是訊息能在您與讀者之間的聊天程式、郵件閘道、內容管理系統或剪貼簿管理員中存活下來，因為這些系統大多會以悄悄移除 default-ignorable 編碼點的方式來正規化、篩選或重新序列化文字。在您將結果用於無害練習之外的任何用途之前，請將其視為需要端對端測試的脆弱物件。
「安全」對零寬度隱寫術的意義
「安全」可拆成三個常被混為一談的獨立問題。第一個是本機安全：工具在您準備資料時是否會洩漏您的資料。第二個是傳輸安全：隱藏訊息是否能存活於您傳送的管道。第三個是密碼學安全：該技術是否真正能保護訊息本身的機密性。零寬度文字隱寫術在第一項表現良好，在第二項表現不佳，而在第三項則完全沒有。
本機端很單純。工具使用已記載的慣例將您的掩護文字與隱藏訊息編碼為零寬度編碼點，並將結果直接交還給您。不會上傳任何內容，不需要帳號，也沒有任何遙測會將酬載從頁面帶走。對於學習、浮水印示範與解謎工作流程，這正是大多數讀者想要的安全特性。
僅在瀏覽器中處理也消除了整個類別的洩漏：沒有伺服器端日誌記錄您編碼了什麼，因此您的掩護或秘密不會存放在您無法控制的資料庫中。然而，當您將結果複製到第三方服務時，這層保護便立即失效。工具能保證的事與管道能保證的事是兩種不同的承諾，將它們混為一談正是人們受害的原因。
密碼學安全方面則完全相反。由於從位元到編碼點的對映是公開的，且標記是固定的 Unicode 字元（U+2063 與 U+2064 框住酬載，U+200B 代表 0，U+200C 代表 1），任何發現此模式的人都能在數秒內讀取隱藏的位元組。沒有金鑰、沒有密碼、也沒有完整性檢查。如果訊息很重要，請先使用經驗證的加密工具，最多將隱寫層視為裝飾。
隱藏訊息在哪裡消失
實務上最大的安全失效就是靜默清理。產生的字串充滿 default-ignorable 編碼點，幾乎沒有人會注意到，但許多軟體系統會主動移除它們。郵件閘道會重寫行尾結尾並可能去除隱形字元；聊天程式會正規化貼上的文字；內容管理系統會重新序列化為 HTML；某些平台的剪貼簿管理員會將連續的零寬度字元折疊為空。只要遺失一個位元，酬載就會變成格式錯誤，解碼器便拒絕解出，更糟的是會解出錯誤的位元組。
依據 Unicode 標準的安全性考量報告，default-ignorable 字元正是多數平台認為有理由清理的編碼點類別。這使得它們在乾淨的管道中對隱寫術很有用，在繁忙的管道中則非常危險。螢幕擷圖與列印副本根本無法承載它們，因此在您信任傳遞結果之前，端對端測試是不可省略的。
另一種靜默失效是部分傳遞。將長訊息分割成區塊的聊天程式，或截斷過長行的郵件閘道，可能只傳送了框定序列的一部分。解碼模式接著會看到不完整的酬載並回報框定錯誤，而非自行猜測，這是安全的行為，但如果您沒閱讀約定，可能會以為是程式錯誤。以人工重新輸入字串是最糟的回應：人類的手指根本無法保留隱形字元，因此復原的文字必定會失敗。
如何安全地傳送隱藏訊息
請以兩階段使用此工具：先在本機編碼，然後在測試傳送後於本機驗證。請將第二階段視為工作流程的一部分，而非可有可無的步驟。
- 在隱藏模式中開啟文字隱寫術工具，輸入一句本身具有意義的一般掩護句子，加上您想嵌入的簡短 UTF-8 訊息。請將隱藏訊息長度遠低於 10,000 位元組的上限，以免表情符號與 CJK 字元使您超過該限制。
- 產生隱寫字串，並透過您已測試過的管道複製。能精確保留 Unicode 的純文字編輯器比支援所見即所得或 HTML 的目的地更安全。請避免使用螢幕擷圖、列印機，以及任何會重寫字元的「智慧型」貼上輔助工具。
- 將完全相同的字串傳送到第二個帳號或裝置，並在收到的文字上執行解碼模式，不要重新輸入。如果復原的隱藏訊息與您嵌入的內容相符，且復原的掩護與您的原始掩護相符，則此管道對該工作流程而言是安全的。
- 若解出失敗，請檢查掩護與酬載交界處的原始編碼點，找出是哪個應用程式移除或變更了隱形字元。請切換到更合理的傳輸方式（通常是附加於郵件的純文字檔，或能保留 Unicode 的程式碼貼上服務），並在傳送真實訊息之前重複測試。
影響安全性的硬性限制
以下限制直接來自此工具的約定。一旦觸及其中任何一項，就會改變操作是否能完成，或是否能以降低的安全性完成，因此值得牢記在心。
| 輸入或屬性 | 值或符號 |
|---|---|
| 隱藏的 UTF-8 訊息 | 最多 10,000 位元組 |
| 可見的掩護文字 | 最多 100,000 個編碼點 |
| 酬載框定起始 | U+2063 |
| 酬載框定結束 | U+2064 |
| 二進位 0 | U+200B（零寬度空格） |
| 二進位 1 | U+200C（零寬度不連字） |
| 每隱藏位元組的位元數 | 恰好 8 個，最高位元優先 |
| 處理位置 | 僅在瀏覽器中，不上傳任何內容 |
由於每個隱藏位元組會變成 8 個隱形編碼點，再加上 2 個框定標記，儘管大多數字型讓這些字元沒有寬度，渲染後的文字仍可能在不知不覺中增長一個數量級。字元計數器、差異工具、原始碼檢視器或安全性掃描工具會立刻揭露多出的編碼點 — 這正是重點所在，同時也是為什麼「安全」不能等同於「無法偵測」。
結果實際上對讀者呈現的樣貌
| 輸出的面向 | 變化之處 |
|---|---|
| 可見的渲染結果 | 通常與原始掩護完全相同 |
| 底層編碼點 | 大幅增加，框定標記出現在第一個可見字元之後 |
| UTF-8 位元組長度 | 隨酬載大小增加 |
| 密碼學機密性 | 完全沒有 — 對映關係是公開的 |
| 防竊改能力 | 完全沒有 — 沒有完整性檢查 |
| 通過清理器的存活率 | 無法預測，必須依各管道進行測試 |
可見的相等並不意味著位元組相等。請將輸出視為一個碰巧在許多介面中以相同方式渲染的不同字串。任何對原始編碼點進行操作的工具 — 從支援 Unicode 的編輯器到十六進位傾印工具 — 都會立即向您顯示隱藏的結構。實作在解出時也強制執行多項硬性測試：框定必須完好無損；每個酬載字元必須是兩種位元符號之一；位元計數必須恰好為 8 的倍數；復原的位元組必須解碼為有效的 UTF-8。任何破壞框定、位元符號有效性、位元計數或 UTF-8 解碼的偏差都會被回報為錯誤，而非強行通過，這讓來回過程保持可檢查。請注意，單一位元損壞但仍通過這些格式檢查時，會改變解碼後的位元組，因此損壞也可能產生悄悄不同的輸出，而不僅僅是造成硬性失敗。
何時應選擇隱寫術以外的方案
隱寫術隱藏的是訊息的存在，而非保護其內容。對於憑證、個人資料、有害的指示，或任何平台條款禁止的內容，請先使用經驗證的加密工具，最多將隱寫層視為裝飾。這同樣適用於任何需要在傳輸過程中證明未遭竊改的內容，因為零寬度隱寫術沒有校驗碼、沒有簽章、也沒有重播保護。
如果您需要的是持久的交換，而非一次性的解謎，請偏好可見的編碼方式或可攜的經驗證檔案格式。編碼類別列出多個僅在瀏覽器中運作的選項，例如 Base64 編碼 / 解碼，它會產生自我描述的輸出，您可以複製、附加並驗證，完全不需要任何隱形字元。對於必須順利傳遞的長訊息，校驗碼工具能提供獨立的指紋供您在收到時確認，而強大的加密工具則能提供隱寫術無法給予的機密性。
如需一份與本安全指南搭配良好的可列印參考資料，文字隱寫術速查表將相同的標記代碼與限制彙整於一處，能讓您更容易保持合理的期望，並讓您的傳輸測試誠實可靠。
以此方式使用 — 本機編碼、端對端測試、保持合理的期望 — 文字隱寫術對於解謎、學習、浮水印示範與清理研究便已足夠安全。若漫不經心地使用，則既脆弱、可被偵測，且完全不提供機密性。
如需更深入的探討，請參閱 Binary to Text Cryptii：本機 UTF-8 位元組轉換器。