隱藏訊息是否加密？

沒有。此對映關係已公開且容易檢測；若需要機密性，請使用真正的加密。

為何貼入後訊息消失了？

目的地可能進行了標準化或移除了零寬度字元。許多編輯器和平臺會自動清理這些字元。

其視覺呈現通常保持不變，但其底層的 Unicode 碼點序列會變得長得多。

文字隱寫透過插入零寬度 Unicode 字元，將一段短的 UTF-8 訊息藏於可見的覆蓋文字內。結果在許多介面中看起來與原始句子相同，而在揭露模式下會讀取文件中記載的不可見序列，並重建隱藏訊息。所有處理都在瀏覽器中完成，不會上傳任何覆蓋或秘密文字。

此工具使用明確的 Lizely 規範，而非聲稱與所有隱寫網站相容。一個不可見的分隔符標記載荷的起點，一個不可見的加號標記結束，零寬度空格代表二進位零，零寬度非連線符代表二進位一。每個隱藏的 UTF-8 位元組以恰好八個不可見位元的形式寫出。

帶框的序列會插入在第一個可見的 Unicode 碼點之後。揭露模式會找到這些標記，檢查每個載荷字元是否為兩種位元符號之一，要求位元數為八的倍數，將這些位元轉換回位元組，並拒絕無法驗證為有效 UTF-8 的位元組序列。同時也會回傳恢復的可見覆蓋內容。

可見的等同不表示位元組等同。隱寫結果包含許多額外的碼點，即使常見字型對這些碼點無寬度。一個字元計數器、差異工具、來源檢視器或安全掃描器可立即檢測到這些差異。這僅用於展示與謎題，並非加密通訊通道。

許多應用程式會進行標準化、過濾或重新序列化文字。社交平臺、電子郵件門檻、聊天客戶端、內容管理系統以及剪貼簿管理器可能會移除預設忽略的字元、替換換行符或拒絕標記碼點。若任一隱藏位元消失，載荷將可能變形或解碼為不同的位元組。

因此，僅透過已測試端到端的通路複製產生的字串。揭露前應先驗證傳遞結果。能精確保留 Unicode 的純文字編輯器較可能保留載荷，而會清理貼入內容的系統則可能導致資料損失。截圖或列印複製無法傳遞任何不可見的碼點。

隱藏訊息的限制為 10,000 UTF-8 位元組，覆蓋文字則為 100,000 碼點。這些限制確保了位元擴充套件與 DOM 呈現的響應性：每個隱藏的位元組會變成八個額外的碼點加上框架。表情符號和非拉丁文字可能佔據多個 UTF-8 位元組，因此隱藏字元數量可能小於位元組限制。

覆蓋文字中不得已存在此規範的起始或結束標記，因為接受一個將導致載荷邊界模糊。位於框架區域外的普通零寬度字元仍屬於可見覆蓋內容。揭露模式僅提取第一個有效的框架段，並將錯誤的框架視為錯誤，而非試圖猜測。

隱寫不提供機密性、真實性或完整性。任何知道或檢測到對映關係的人都可以解碼訊息，且任何人都可以修改它。在傳輸前，請使用合適且經過審查的加密系統加密敏感資訊；請勿使用此頁面來隱藏憑證、有害指令、個人資料或違反平臺規則的內容。

測試涵蓋 ASCII、CJK、表情符號、製表符、換行符、單碼點覆蓋、空輸入、保留標記、無載荷以及不完整的位元組。它們會驗證恢復的隱藏文字與覆蓋文字的精確還原。此往返測試證明此規範的實作正確性，而非透過外部服務的存活能力。

使用「隱藏模式」時，請輸入一個普通的覆蓋句子和一個獨立的隱藏訊息，然後複製結果。使用「揭露模式」時，請貼入精確的隱寫文字，且不得進行任何清理或重打。若傳輸後提取失敗，請比較原始碼點以找出哪個應用程式移除或改變了不可見字元。

保持期望值謹慎：此工具可用於學習 Unicode 如何傳遞非渲染資料、創造無害謎題以及測試清理行為。它明確說明每一個標記與限制，使轉換過程可檢視且可逆。對於需要長期資料交換的場景，建議使用可見編碼或經認證的檔案格式。

隱藏的 UTF-8 位元組以最高有效位為先擴充套件，對應至 U+200B 與 U+200C，並以 U+2063 與 U+2064 框架包圍，插入第一個覆蓋碼點之後。揭露模式會驗證框架、位元數量以及致命的 UTF-8 解碼結果。