個資遮罩工具

兩層偵測：規則與模型

多數敏感資料都有固定格式，而格式可以驗證。卡號用 Luhn 檢查碼驗證，IBAN 用 ISO 13616 的 mod 97 檢查，IPv4 位址逐段檢查，IPv6 位址則使用與子網路計算工具相同的解析器。API 金鑰依發行者公開的前綴辨識：GitHub、AWS、Stripe、Slack、Google、npm，以及 AI 服務常用的 sk- 形式金鑰；另外也涵蓋私鑰區塊、Authorization 標頭，以及 DB_PASSWORD= 這類設定值。這一層每次輸入都會執行，不需要下載任何東西。

姓名、門牌地址和各種證號則沒有固定格式。「志明」是人名還是店名，只能從上下文判斷，所以第二層用的是模型而不是規則。這裡使用的是 National Design Studio 以 CC BY 4.0 授權釋出的小型詞元分類模型 Rampart：六層 Transformer、約 15 MB，訓練來辨識名字、姓氏、街道地址，以及稅籍、護照與駕照號碼。只有在你開啟後，它才會在裝置上的背景 Worker 中執行。

兩層對同一段文字判斷不同時，以規則為準。通過檢查碼的號碼，比模型的推測更可靠。而且數值一定整段替換——留下半個電子郵件位址，比哪一種結果都糟。

它會漏掉什麼

沒有任何自動遮蔽是完整的，這個工具也不例外。模型本身公開的評估顯示，在拉丁字母測試資料上的召回率約為 98%，也就是說即使文字和訓練資料相近，每大約 60 筆個資仍會有 1 筆漏網。對非拉丁字母書寫的姓名，表現差得多：模型說明文件指出，日文姓名約 46%、韓文 15%、中文只有 9%。規則層對任何語言都有效，但姓名不是規則能描述的。

有些可識別個人的資訊根本不是一個「值」。職稱、一個小鎮的名字加上日期，就可能指向特定的人，而其中沒有任何可以遮蔽的字詞。另一個盲點是組織內部的識別碼：客戶編號、案件編號、主機名稱、專案代號都只在你的組織裡有意義，外部工具無從辨認。這些請在使用本工具前後自行替換。

所以結果會加上標示。每一處替換都有記號，模型找到的部分則以虛線框起來，因為那是判斷而不是比對。貼到任何地方之前請先讀過一遍——這個工具的用意是讓檢查變快，而不是讓檢查變得不必要。

如何選擇替換方式

預設使用編號標籤，因為它能讓文字保持可讀。相同的值（不分大小寫）永遠得到相同的標籤，所以日誌的脈絡還在：[EMAIL_1] 登入失敗三次，接著 [EMAIL_2] 從同一個 [IP_1] 登入成功。讀取遮蔽後文字的 AI 助理，仍然能推論誰做了什麼；如果所有位址都變成同一個詞，就做不到了。

不編號的標籤會連這層對應也拿掉。當「重複出現的模式」本身就敏感時——例如一次事故牽涉多少位不同的客戶——或你只想留下最少資訊時，就用這種。

星號會保留原本的長度與排版，適合固定寬度的輸出和截圖。代價是長度本身也是一點線索：兩個字的名字和四個字的名字仍分得出來。

使用「匿名」這個詞要小心。依照 GDPR 或台灣的個人資料保護法，只移除明顯識別資訊的資料通常屬於「假名化」，仍可能被視為個人資料。本工具不保留任何從標籤還原到原始值的對照表，但留下的上下文仍可能足以識別出某個人。

你的文字去了哪裡

哪裡都沒去。規則層在頁面中執行。模型在你開啟時從本站下載一次——約 30 MB，包括 ONNX Runtime 的 WebAssembly 引擎與模型權重——並由瀏覽器快取。之後它在 Web Worker 中執行，文字和結果都不會離開你的裝置。你可以在瀏覽器開發者工具的「網路」分頁確認：下載完成後，偵測時不會發出任何請求。

這一點在這個工具上比其他工具更重要。會想遮蔽文字，通常是因為它即將被送到別處：AI 助理、公開的議題追蹤系統、論壇貼文、廠商的客服窗口。如果遮蔽工具得先把未遮蔽的原文上傳才能工作，就失去了它存在的意義。