iPhone 上的文字隱寫術指的是使用不可見的零寬度 Unicode 字元，將一段簡短的 UTF-8 訊息隱藏在看似普通的掩護文字中，然後在同一個 Safari 分頁裡再將其解讀出來 — 無需安裝應用程式、無需建立帳號，也無需將掩護文字或秘密訊息傳送到任何伺服器。文字隱寫術所使用的慣例，會將你隱藏訊息的每個位元組寫成八個不可見的碼位（二進位 0 使用零寬度空格，二進位 1 使用零寬度不連字），以一個不可見的起始與結束標記框住整段序列，並將整個框好的區塊插入掩護文字的第一個可見字元之後。在 iPhone 螢幕上呈現的句子與原本看起來一模一樣，即使其底層的 Unicode 序列已經多了數十甚至數百個碼位。因為每一步都只在瀏覽器中於本機執行，所以掩護文字、隱藏訊息以及產生的字串絕對不會離開裝置。唯一的限制在 iOS 本身：郵件、訊息、備忘錄、WhatsApp、社群應用程式以及剪貼簿管理工具經常會把預設可忽略的字元進行正規化或移除，所以在 iPhone 上正確的使用方式，是在把任何重要內容交付出去之前，先對傳遞管道進行端對端的測試。
文字隱寫術在 iPhone 上能做什麼
文字隱寫術是一個完全在 Safari 內執行的單頁工具。你提供兩個輸入 — 一段可見的掩護句子與一段隱藏的 UTF-8 訊息 — 它會回傳一串文字，對一般讀者來看就像掩護文字本身，但實際上在不可見的碼位中承載著隱藏訊息。其編碼遵循一份有明確文件的 Lizely 慣例，而不是模糊的「隱寫術」說法：
- U+200B（零寬度空格）代表一個二進位零。
- U+200C（零寬度不連字）代表一個二進位一。
- U+2063（不可見分隔符）標記承載內容的起始。
- U+2064（不可見加號）標記承載內容的結束。
- 每個隱藏的 UTF-8 位元組都恰好以八個不可見的位元表示，採用最高位元優先的順序。
- 框好的序列會插入掩護文字中第一個可見碼位之後。
在 iPhone 上，呈現出來的文字看起來沒有變動，因為在一般字型中，這些碼位的寬度都是零。Unicode 聯盟的 Unicode 安全考量報告正好把這類字元歸類為「預設可忽略」，這正是為什麼大多數讀者看不到多餘內容 — 卻也是為什麼許多軟體的處理流程會悄悄把它們移除。
為何瀏覽器路徑在 iOS 上勝過原生應用程式
在 iPhone 上透過 Safari 進行文字隱寫術，比起安裝專用的隱寫應用程式，有多項實際的好處。不必等待 App Store 審核通過、不必授權使用相機或麥克風、不會有遙測 SDK 把你的掩護文字與秘密傳給開發者，也沒有背景服務在執行。你只要在分頁中開啟網址、貼上掩護文字與隱藏文字、複製結果、關閉分頁 — 裝置上不會留下任何安裝的東西。對只是偶爾需要這項功能的人來說，瀏覽器路徑比起尋找、審查並授權第三方應用程式要更快。這也代表你可以在 iPhone、iPad、Mac 與 Windows 上使用同一套工具，不用擔心手機上安裝的應用程式是否為最新版本。代價在於你沒有應用程式圖示、沒有分享擴充功能、也沒有小工具 — 你用便利性換來了可攜性與更小的隱私足跡。
如何在 iPhone 上於文字中隱藏訊息
- 在 iPhone 上開啟 Safari，並前往文字隱寫術頁面。
- 若工具尚未處於隱藏模式，請切換至隱藏模式。
- 在掩護欄位中輸入一段普通的掩護句子 — 例如「Coffee at 3 on Tuesday, usual spot.」。
- 在隱藏欄位中輸入簡短的 UTF-8 隱藏訊息。請保持遠低於 10,000 個 UTF-8 位元組的限制；表情符號與非拉丁文字各會佔用數個位元組，因此「字元」預算可能比看起來更為吃緊。
- 點擊 Generate（產生）。頁面會在輸出框中回傳一串隱寫過的字串。
- 長按輸出內容，然後選擇 Copy（複製）。請勿重新手動輸入；iOS 的螢幕鍵盤無法顯示或保留零寬度字元，手動重新輸入會悄悄地把承載內容銷毀。
- 將複製的結果原封不動地貼到你要傳送的目標位置 — 不要清理、不要「聰明」的格式化，也不要套用自動校正。
若要更確實地保證掩護文字與秘密不外洩給任何遠端服務，整個工作流程都在本機執行；文字隱寫術的純瀏覽器路徑已確認在任何環節都不會上傳資料。
如何在 iPhone 上解讀隱藏的訊息
- 在 Safari 中開啟同一個文字隱寫術頁面。
- 將工具切換到 Reveal（解讀）模式。
- 開啟收到的訊息，全選整段隱寫字串並複製。請使用 Select All（全選），而不是拖移選取範圍，因為不可見的碼位可能會干擾 iOS 的選取邏輯。
- 將該字串原樣貼到 Reveal 模式中。請勿先貼到備忘錄中「清理」，也不要在貼上時讓自動校正介入。
- 點擊 Reveal（解讀）。工具會找出起始與結束標記、檢查每個承載字元是否為兩個位元符號之一、要求位元數為八的倍數，並拒絕任何不是有效 UTF-8 的內容。
- 讀取還原出來的隱藏訊息與可見的掩護文字。兩者都會一併回傳，且兩者都應該與原本輸入的內容相符。
若 Reveal 回傳錯誤而非隱藏訊息，代表承載內容在傳送過程中已損壞 — 而非在工具內部遺失。在斷定輸入內容有問題之前，請先跳到下方的疑難排解章節。
iPhone 上的傳遞管道及其對零寬度字元的處理方式
iOS 應用程式對預設可忽略的碼位並沒有一致的處理方式，而 Apple 也未公開相關的對照表。下表整理了把一段隱藏的文字隱寫字串貼到常見 iPhone 目的地時所觀察到的典型行為。請把每一列當作起點，並在依賴於不能承擔損失的內容之前，先以你自己的裝置、iOS 版本與接收端設定進行完整的端對端測試。
| iPhone 上的傳遞管道 | 對零寬度碼位的典型處理 | 未重新進行端對端測試是否安全 |
|---|---|---|
| Apple 備忘錄（以純文字貼上） | 傾向於完整保留原始 Unicode | 通常安全 |
| 郵件草稿（iCloud 帳號） | 通常會保留；某些閘道會重新編碼 | 請先測試 |
| 訊息（iMessage 對 iMessage） | 通常會保留不可見的碼位 | 請先測試 |
| 訊息（SMS / RCS） | 電信業者的處理流程常會移除預設可忽略的字元 | 不安全 |
| 已知會移除預設可忽略的字元 | 不安全 | |
| 社群網路（X、Instagram、Facebook、TikTok） | 通常會對貼上的文字進行清理 | 不安全 |
| 第三方剪貼簿管理工具 | 寫入剪貼簿時常會移除 | 不安全 |
| 螢幕擷圖、AirPrint、相機翻拍 | 完全無法承載不可見的碼位 | 絕對不行 |
iPhone 工作階段的容量計算
每多一個隱藏的 UTF-8 位元組，就會在掩護文字中插入八個不可見的碼位，再加上兩個框住用的標記。以下是針對一段典型簡短秘密（也就是你真的可能從 iPhone 貼到聊天中的那種訊息）所做的計算。
假設隱藏訊息是「open 1234」，也就是九個 ASCII 字元。
- 「open 1234」的 UTF-8 大小：9 個 ASCII 位元組 × 每字元 1 個位元組 = 9 個位元組。
- 插入的不可見位元數：9 個位元組 × 每位元組 8 個位元 = 72 個位元。
- 承載內容所使用的不可見碼位數：72 個位元 × 每位元 1 個碼位 = 72 個碼位。
- 框住用的標記：2 個不可見碼位（起始 + 結束）。
- 插入的不可見碼位總數：72 + 2 = 74。
整個 74 個字元的不可見區塊會附加在你掩護文字的第一個可見字元之後。因此若你的掩護文字是 35 個字元的句子「Coffee at 3 on Tuesday, usual spot.」，呈現出來的字串讀起來仍然是該句子，但其底層的 Unicode 序列會變成 35 + 74 = 109 個碼位。若掩護文字本身已超過 100,000 個碼位，或是隱藏的承載內容會讓隱藏訊息超過 10,000 個 UTF-8 位元組，工具將會拒絕處理。以表情符號為主的秘密訊息會比可見字元數所顯示的更快觸及位元組上限，因為單一表情符號就可能佔用四個 UTF-8 位元組。若要取得特定訊息精確的上限，請把數值代入實際的工具中計算，而非自行估算。
iOS 上常見的失敗模式與其偵測方式
iPhone 上大多數「沒成功」的回報，都屬於少數可預測的類型。依序檢查通常在一分鐘內就能找到原因。
- Reveal 回傳空白的隱藏訊息。起始或結束標記已被目的應用程式移除。可將收到的文字貼到 Reveal 模式中，並觀察驗證錯誤來確認 — 當框標記格式錯誤時，工具會拒絕猜測。
- Reveal 回傳亂碼位元組或替換字元。有些位元存活下來、有些沒有，因此承載內容不再是八的倍數位元。工具的嚴格 UTF-8 檢查會將其拒絕，而不是悄悄替換。
- 掩護文字的第一個字母不見了。由於慣例會將框好的區塊插入第一個可見碼位之後，因此若第一個字母看起來不見了，代表目的地從前端進行了截斷。請嘗試一個能保留原始 Unicode 的管道。
- Reveal 解讀出的訊息與預期不同。原本的掩護文字在框選區域之外就含有其中一個有文件的標記碼位。慣例會拒絕模糊不清的承載內容，而不是猜測。
- 貼上的文字「看起來沒問題」，但 Reveal 卻說裡面沒有內容。iOS 的自動校正或智慧標點在貼上時改寫了字串。請長按貼上的結果，並選擇「替換」為原始版本，或從來源重新貼上一次。
- 為了留存紀錄所拍攝的螢幕擷圖完全看不到承載內容。螢幕擷圖是像素 — 不可見的碼位無法在被點陣化之後存活下來。若需要可還原的副本，請把原始字串保存在備忘錄中。
若要快速查閱所有標記、限制與步驟，文字隱寫術速查表以精簡形式整理了同一套慣例。
Honest Limits of This Approach on iPhone
Text steganography on an iPhone is concealment for demonstrations, puzzles, and sanitization testing — not a confidential channel. The mapping is documented, so anyone who finds or guesses the convention can decode the message, and anyone who finds it can alter it. Apple does not guarantee that any specific app will preserve default-ignorable characters, and the iOS clipboard can apply transformations you did not ask for. For anything sensitive, encrypt the hidden message with a reviewed system before steganography, and treat the steganographic string as a public envelope rather than a secret one. Used with those expectations, the tool is a clean, inspectable way to learn how Unicode can carry non-rendering data and to verify which of your favorite iPhone apps silently rewrite the strings you paste.