外發工單和聊天紀錄前，哪些欄位必須打碼

客服把使用者留言貼進工單，行銷把報名表匯出成試算表丟進 LINE 群，工程師把錯誤紀錄貼進 Slack——這三件事每天都在發生。上一篇寫過外發連結時哪些參數能刪：utm_source 和 fbclid 可以去掉，id= 必須留。做完這一步，很多人會以為「已經乾淨了」。正文裡的 0912345678、十碼身分證字號、卡號和信箱，並不會因為網址變短而消失。

問題不在「要不要打碼」，而在先分清兩類字串：能直接聯絡到人、或能直接動用帳戶的，必須遮；訂單編號、工單號碼、商品 SKU 一類業務定位符，亂遮會讓下一棒對不上。下面按對照表、例外和可當場驗證的步驟把這件事寫清楚。MyPassGen 的隱私清洗頁依這個原則做個資遮罩；本文不講工具總覽，只回答外發前哪些欄位必須打碼、打完怎麼核對。

清洗連結解決不了正文

《個人資料保護法》第二條第一款把個人資料寫成：自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、聯絡方式、財務情況，以及其他得以直接或間接方式識別該個人之資料。工單和群組裡的手機號碼、身分證字號、電子郵件，正好落在「可識別」這一側。你把整段原文轉給下一個群、下一張表、下一個「線上工具」，等於把識別能力一併轉出去。

同法第六條把病歷、醫療、基因、性生活、健康檢查與犯罪前科列為原則上不得任意蒐集、處理或利用的特種個資。把病歷摘要、健康檢查結果或前科紀錄原樣貼進公開工單，已超出「只轉必要內容」。就算一般聯絡方式，第五條也要求依誠實信用方法為之，不得逾越特定目的之必要範圍——客服群裡貼完整卡號、把未成年人聯絡方式留在對外頻道，都不符合這條。

這不是說法條替你決定每一個星號打在哪。它只劃了一條工作界線：外發的預設值應當是「對方不必看到完整號碼也能繼續做事」。能繼續做事的，用遮罩或摘要；必須把完整金鑰交給指定的人，就不要寫進工單正文，改走一次性通道。

必須打碼的欄位對照

下面這張表依欄位分組。它不是合規清單的窮盡版——產業還會發明新前綴——但覆蓋了工單、報名表、簡報和錯誤紀錄裡最常漏出去的一批。打碼之後，讀者應仍能看懂「這是一個手機號碼 / 一張證 / 一封信箱」，不能再直接使用。

手機號碼：能撥出去的才算沒遮完

ITU-T E.164 規定國際公眾電信號碼最長 15 位（不含國際字冠）。加號 + 是記法，不算一位數字。台灣行動門號日常寫成 10 碼、以 09 開頭；寫成 +886 912 345 678 時，開頭的 0 會被國碼取代。工單裡常見的 0912***678 就是前四後三：對方知道這是手機號碼，不能直接撥通。

帶空格、連字號或 +886 的寫法，先抽出數字再判斷，不要只認連在一起的 10 碼。跨境客服還會碰到大陸 11 碼手機，形態是 1 後接 3–9。反過來說，8 到 15 位的純數字也可能是訂單編號。沒有 +、空格或手機形態時，不應一律當成電話。誤傷訂單編號，下一棒對不上帳，比少遮一個號更常見。

身分證字號：中間藏著縣市與性別

《國民身分證及戶口名簿格式內容製發相片影像檔建置管理辦法》把統一編號寫成十碼：首位英文字母代表首次設籍的直轄市或縣市，第二碼是性別碼（本國人男性為 1、女性為 2；新式外來人口統一證號常見 8 或 9），第十碼是檢查碼。看起來像「一字母加九數字」，並不自動等於有效字號——檢查碼對不上的，更可能是機票編號、車牌或複製錯誤。

機關行文常只遮末四碼，留下 A12345****。外發工單若還帶著姓名，等於把縣市線索和性別一併轉出去。更穩妥的形態是留字母（讓人看出「這是身分證字號」）和後四位，把性別碼與中間流水蓋住。跨境團隊若處理十八位大陸居民身分證，中間八段是出生日期；只遮後四、留下生日，等於還在轉發年齡線索。美國社會安全號常見 ***-**-1234，原則相同：留下「這是證件」的形狀，拿走「這是哪一個人」的中間段。

金融卡：展示上限不是建議值

支付卡主帳號（PAN）的校驗位按 Luhn 演算法 計算，該演算法寫在 ISO/IEC 7812-1 附錄 B。它只能抓住輸入錯誤，不能證明「這張卡現在有效」。長度通常在 13 到 19 位。PCI DSS 對展示卡號的上限是：最多可見前六位和後四位；沒有正當業務需要，連這個上限也不該用滿。

外發工單幾乎沒有「必須看見 BIN」的理由。只留後四位，已經夠客服對「末四碼是不是 4242」。把完整卡號和持卡人姓名寫在同一段聊天裡，屬於財務情況與身分資料疊在一起，比單獨一個末四碼危險得多。通過 Luhn 的長數字才按卡號處理；不通過的，優先當成業務編號，不要為了「寧枉勿縱」把宅配單號遮掉。

信箱、金鑰和位址

電子郵件的識別能力主要在 @ 前面。留下首字母、遮住其餘、保留網域，一般夠判斷「是不是公司信箱」，不夠直接寫信。整段 local@domain 原樣轉寄，等於把聯絡通道交給每一個打開紀錄的人。

API Key 往往帶家族前綴：sk- / sk_live_、AKIA / ASIA、AIza、ghp_ / github_pat_、glpat-、npm_、xoxb-，以及 Bearer 後面的權杖。前綴用來認家族，不是用來繼續呼叫。打碼後若對方仍能用這串字元打通介面，表示你遮少了，或者根本不該把可用金鑰放進工單——完整金鑰應走閱後即焚，金鑰放在 URL 的 # 後面，閱讀頁無需註冊。

IPv4 留前兩段（例如文件裡常用的測試網段 203.0.113.0/24 寫成 203.0.*.*）通常夠判斷電信商或辦公網段，不夠精確到主機。內網位址、VPN 出口和家用寬頻公網，出現在錯誤貼上裡時，按同一規則遮後兩段。

哪些數字串不該動

和連結參數一樣，正文裡也有「一刪下一棒就對不上」的編號。它們看起來也像隨機數字，職責卻是定位業務，不是定位人。

• 訂單與物流：電商訂單編號、託運單號、售後單號。長度常與手機號碼、卡號重疊，但沒有電話或 Luhn 形態。
• 工單與物件 ID：工單號碼、使用者內部編號、商品 SKU、資料庫遞增 ID。外發的目的常常就是讓對方打開同一筆紀錄。
• 版本與時間：組建編號、提交雜湊的短前綴、日期時間戳記。把它們遮掉，重現步驟會斷。

一個能當場做的試驗：把待發文本複製到記事本，只處理一種類型（先手機，再證件，再卡號），每做完一類就讀一遍：業務編號是否還在、句子是否還通。不要一次把所有長數字換成星號再猜是哪一處壞了。

護照風格的「一兩位字母加六到九位數字」更容易誤傷機票編號或車牌。台灣身分證字號是一字母加九數字；檢查不過、或上下文明顯是航班與座位時，先留著，用人工標黃，而不是交給規則一刀切。

打碼不是匿名化

個資法施行細則把「間接識別」寫成：須與其他資料對照、組合、連結，才識別得出特定個人。憲法法庭 111 年憲判字第 13 號進一步指出：資料經過處理後，客觀上若仍有還原或連結而間接識別當事人的可能，無論還原難易，都仍屬個人資料。工單裡的 0912***678 加上姓名、地址和訂單編號，借助工單系統仍能定位到人——這最多算去識別化，不是匿名化，更不是「已經可以隨便公開」。

因此，打碼的目標要寫準確：減少下一次轉寄、下一次截圖、下一個群裡的直接可用性。它不讓你把處理後的試算表發到公開網頁，也不代替最小必要原則。姓名、住址、人臉、未成年人資料和完整金鑰，經常落在規則掃不到的位置：它們寫在表格另一欄、截圖像素裡，或被空格拆開。

同一段文本裡把姓名、手機、證件和住家地址疊在一起，敏感程度會高於單獨一個遮罩手機號碼。能拆開的，就不要把四項寫進同一則群組訊息。能只發工單號碼讓對方自己打開系統的，就不要把使用者檔案複製出來。

當場核對：並排文本、星號和 Network

口號無法核對，字元可以。下面這組步驟不依賴任何品牌承諾，記事本和開發者工具就夠。

1. 把待轉寄的原文完整貼到本地編輯器，保留一份未改動的副本，避免只憑記憶遮改。
2. 按上一節的對照表，先只處理手機號碼，再處理證件字號、卡號、信箱。一次一類，業務編號先不動。
3. 把原文和結果左右對照：被處理的欄位應出現星號或等效遮罩；訂單編號、SKU、日期應仍可讀。
4. 用搜尋功能在結果裡找原文裡的完整手機號碼、十碼身分證字號或 @ 前面的本地部分。還能搜到，就是沒遮完。
5. 若使用會在瀏覽器裡列出命中類型的工具，把清單上的類型與結果裡的星號對讀：清單有、結果裡相應位置已遮，才算這一類做完。
6. 開啟開發者工具的 Network 面板，勾選「保留紀錄」，再執行一次遮罩。頁面與介面請求裡不應出現你剛貼上的原文，分析回報也不該帶走證件字號或信箱全文。

MyPassGen 的隱私清洗按這個界線工作：在「個資遮罩」裡一次選一種類型——電話、證件號碼、金融卡、電子郵件、API Key 或 IP——原文與結果並排。台灣與大陸手機、E.164、以及字母加數字的證件格式都會掃；十八位大陸居民身分證會先做 ISO 7064 校驗再遮罩；卡號先走 Luhn，再只留後四位（比「最多前六後四」更收）；信箱留本地部分首字元。處理在目前分頁完成，原文不上傳，也不寫入分析紀錄，無需註冊。頁面寫明：這是輔助，重要場景仍要人工看一眼。

截圖、表格和「已經打碼」的假象

試算表比純文字難處理。手機號碼在 A 欄，姓名在 B 欄，證件掃描檔以圖片插在第三頁。文字規則掃不到像素。外發簡報前，先看有沒有未裁切的證件照片、帶完整號碼的螢幕錄影，以及 Excel 裡藏在「已隱藏欄」或第二個工作表的原文。

聊天軟體的「回覆」會把舊訊息再帶一遍。你在最新一則裡打了碼，引用的上一層仍是完整號碼。LINE 的「轉傳」、Slack 的 thread、郵件的整串轉寄，都是同一類問題。外發前展開引用，或改成不帶引用的新訊息。轉寄整封郵件串，等於把早期未打碼的簽名檔和工單一併送出。

短網址和 QR Code 解決不了正文。上一篇寫過，短網址只是轉址層。這裡要補一句：有人把「使用者 0912345678 的訂單」寫進頁面標題或 UTM 的 utm_content，連結洗乾淨之後，標題和正文還在。連結清洗和文本打碼是兩道工序，不要互相替代。

常見迷思

「遮了後四碼就夠。」對手機號碼，只留後四、露出前面六碼，對方仍可能結合社工庫補全。前四後三是常見折衷，不是數學證明。對身分證字號，留下性別碼和縣市字母、只遮末四，在已有姓名的工單裡等於沒做完。

「HTTPS 已經保護隱私。」HTTPS 擋住的是傳輸路徑上的竊聽者。接收方、群組成員、工單系統的管理員，仍然看得到你貼進去的明文。你要減少的是轉寄出去的那一份裡不必要的完整號碼。

「打碼等於可以公開發布。」去識別化之後，借助工單系統仍能定位到人。公開網頁、對外案例和訓練教材，需要的是拿不到額外資料也無法還原，那是匿名化，不是幾個星號。

「規則掃過就不用看了。」拆開的號碼（0912 345 678）、用國字寫的「零九一二」、圖片裡的證件，以及規則尚未收錄的金鑰前綴，都會漏。人工複核的對象是：結果裡還能不能搜到完整原文，以及上下文是否仍能拼出同一個人。

從哪一步開始打碼

先處理你今天就要發出去的那一段。複製到本地，先只動手機號碼，對照原文，再決定要不要動證件和信箱。群組公告和知識庫裡的舊紀錄可以後補，不必一次清全站歷史。

若同一段裡混著連結和正文，先按上一篇的對照表去掉 UTM 與點選 ID，再打碼正文。一則訊息裡同時有訂單編號和手機號碼時，留下訂單編號，遮手機號碼，再讀一遍句子是否還通。做完這一條，你就已經能回答本文的問題：必須打碼的是能直接聯絡到人或動用帳戶的欄位，不能亂遮的是打開同一筆業務紀錄所必需的編號。

需要把可用的密碼、復原碼或 API Key 交給指定的人時，不要把完整金鑰寫進工單，也不要只靠遮罩「假裝沒給」。用閱後即焚產生一次性連結；需要可反覆解密的附件則走檔案加密盒，在本機產生 .lock / .enc，密碼走另一則訊息。文本打碼解決的是「討論時少帶完整號碼」，不是金鑰交換。

常見問題

打碼之後，對方還知道這是誰嗎？

常常還知道。工單號碼、姓名和遮罩手機號碼疊在一起，借助內部系統仍能定位。打碼減少的是「不在系統裡的人拿到完整號碼就能撥打或冒用」，不是讓文本變成匿名統計資料。

為什麼有的 10 碼數字沒有被當成手機號碼？

沒有 09 開頭、也沒有 + 或分隔符的長數字，更可能是訂單編號。一律按電話處理，會把業務定位符遮掉。拿不準時先留著，只處理帶 09、1[3-9] 或 + 的項，再人工標其餘。

金融卡只留後四位，合規嗎？

PCI DSS 對展示卡號的上限是前六後四；只留後四位更收，通常夠對末四碼。這仍然不是「可以發到公開管道」。完整卡號加姓名不應出現在群組裡。

遮罩需要註冊嗎？原文會不會上傳？

不需要註冊。把完整工單交給會上傳原文的網站，才有紀錄風險。本地處理時，原文留在目前分頁；你要核對的是 Network 裡有沒有把證件字號或信箱全文發到第三方，以及結果裡是否還能搜到未遮的完整號碼。