外发工单和聊天记录前，哪些字段必须打码

客服把用户留言贴进工单，运营把报名表导出成表格发到群里，开发把报错日志丢进聊天——这三件事同样每天都在发生。上一篇写过外发链接时哪些参数能删：utm_source 和 fbclid 可以去掉，id= 必须留。做完这一步，很多人会以为「已经干净了」。正文里的 13800138000、十八位证件号、卡号和邮箱，并不会因为网址变短而消失。

问题不在「要不要打码」，而在先分清两类字符串：能直接联系到人、或能直接动用账户的，必须遮；订单号、工单编号、商品 SKU 一类业务定位符，乱遮会让下一棒对不上。下面按对照表、例外和可当场验证的步骤把这件事写清楚。MyPassGen 的隐私清洗页按这个原则做文本脱敏；本文不讲工具总览，只回答外发前哪些字段必须打码、打完怎么核对。

清洗链接解决不了正文

《个人信息保护法》第四条把个人信息写成：以电子或者其他方式记录的、与已识别或者可识别的自然人有关的各种信息；匿名化处理后的信息除外。工单和群聊里的手机号、证件号、邮箱，正好落在「可识别」这一侧。你把整段原文转给下一个群、下一张表、下一个「在线工具」，等于把识别能力一并转出去。

第二十八条把敏感个人信息定义为：一旦泄露或者非法使用，容易导致人格尊严受侵害或者人身、财产安全受危害的信息，并列举生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹，以及不满十四周岁未成年人的个人信息。处理这类信息，法律要求特定目的、充分必要性和严格保护措施。客服群里贴完整卡号、把未成年人联系方式留在公开工单，都不符合「只转必要内容」这条。

这不是说法条替你决定每一个星号打在哪。它只划了一条工作边界：外发的默认值应当是「对方不必看到完整号码也能继续干活」。能继续干活的，用掩码或摘要；必须把完整密钥交给指定的人，就不要写进工单正文，改走一次性通道。

必须打码的字段对照

下面这张表按字段分组。它不是合规清单的穷尽版——行业还会发明新前缀——但覆盖了工单、报名表、演示稿和报错日志里最常漏出去的一批。打码之后，读者应仍能看懂「这是一个手机号 / 一张证 / 一封邮箱」，不能再直接使用。

手机号：能拨出去的才算没遮完

ITU-T E.164 规定国际公众电信号码最长 15 位（不含国际字冠）。加号 + 是记法，不算一位数字。大陆移动号码日常写成 11 位、以 1 后接 3–9 开头。工单里常见的 138****8000 就是前三后四：对方知道这是手机号，不能直接拨通。

带空格、括号或 +86 的写法，先抽出数字再判断，不要只认连在一起的 11 位。反过来，8 到 15 位的纯数字也可能是订单号。没有 +、空格或大陆手机形态时，不应一律当成电话。误伤订单号，下一棒对不上账，比少遮一个号更常见。

身份证：中间藏着区划和出生日期

GB 11643-1999《公民身份号码》 把十八位号码写成特征组合码：六位行政区划、八位出生日期、三位顺序码，外加一位校验码。顺序码奇数分给男性、偶数分给女性。校验码按 ISO 7064:1983 MOD 11-2 计算，余数为 10 时写成 X。前十七位的权重是 7、9、10、5、8、4、2、1、6、3、7、9、10、5、8、4、2——这不是为了让你手算，而是提醒：看起来像十八位、末位带 X，并不自动等于证件号，校验失败的更可能是订单号或复制错误。

只遮后四位、留下出生日期，等于还在转发年龄和籍贯线索。更稳妥的外发形态是留前三位（大约到省级）和后四位，把区划后半与全部出生日期盖住。美国社会安全号常见 ***-**-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。外发的目的常常就是让对方打开同一条记录。
• 版本与时间：构建号、提交哈希的短前缀、日期时间戳。把它们遮掉，复现步骤会断。

一个能当场做的试验：把待发文本复制到记事本，只处理一种类型（先手机，再证件，再卡号），每做完一类就读一遍：业务编号是否还在、句子是否还通。不要一次把所有长数字换成星号再猜是哪一处坏了。

护照风格的「一两位字母加六到九位数字」更容易误伤机票编号或车牌。校验通不过、或上下文明显是航班与座位时，先留着，用人工标黄，而不是交给规则一刀切。

打码不是匿名化

第七十三条把两个词分开：去标识化是处理后，不借助额外信息时无法识别特定自然人；匿名化是无法识别且不能复原。第四条把匿名化之后的信息排除在个人信息之外。工单里的 138****8000 加上姓名、地址和订单号，借助工单系统仍能定位到人——这最多算去标识化，不是匿名化，更不是「已经可以随便公开」。

因此，打码的目标要写准确：减少下一次转发、下一次截图、下一个群里的直接可用性。它不让你把处理后的表格发到公开网页，也不代替最小必要原则。姓名、住址、人脸、未成年人信息和完整密钥，经常落在规则扫不到的位置：它们写在表格另一列、截图像素里，或被空格拆开。

同一段文本里把姓名、手机、证件和家庭住址叠在一起，敏感程度会高于单独一个掩码手机号。能拆开的，就不要把四项写进同一条群消息。能只发工单号让对方自己打开系统的，就不要把用户档案复制出来。

当场核对：并排文本、星号和 Network

口号无法核对，字符可以。下面这组步骤不依赖任何品牌承诺，记事本和开发者工具就够。

1. 把待转发的原文完整粘贴到本地编辑器，保留一份未改动的副本，避免只凭记忆遮改。
2. 按上一节的对照表，先只处理手机号，再处理证件号、卡号、邮箱。一次一类，业务编号先不动。
3. 把原文和结果左右对照：被处理的字段应出现星号或等效掩码；订单号、SKU、日期应仍可读。
4. 用查找功能在结果里搜原文里的完整手机号、十八位证件号或 @ 前面的本地部分。还能搜到，就是没遮完。
5. 若使用会在浏览器里列出命中类型的工具，把清单上的类型与结果里的星号对读：清单有、结果里相应位置已遮，才算这一类做完。
6. 打开开发者工具的 Network 面板，勾选「保留日志」，再执行一次脱敏。文档和接口请求里不应出现你刚粘贴的原文，分析上报也不该带走证件号或邮箱全文。

MyPassGen 的隐私清洗按这个边界工作：在「敏感脱敏」里一次选一种类型——电话、证件号、银行卡、邮箱、API Key 或 IP——原文与结果并排。大陆手机按前三后四；十八位居民身份证校验 ISO 7064 后再掩码，留前三后四；卡号先走 Luhn，再只留后四位（比「最多前六后四」更收）；邮箱留本地部分首字符。处理在当前标签页完成，原文不上传，也不写入分析日志，无需注册。页面写明：这是辅助，重要场景仍要人工看一眼。

截图、表格和「已经打码」的假象

表格比纯文本难处理。手机号在 A 列，姓名在 B 列，证件扫描件以图片插在第三页。文本规则扫不到像素。外发演示稿前，先看有没有未裁切的证件照片、带完整号码的屏幕录像，以及 Excel 里藏在「已隐藏列」或第二个工作表的原文。

聊天软件的「回复」会把旧消息再带一遍。你在最新一条里打了码，引用的上一层仍是完整号码。外发前展开引用，或改成不带引用的新消息。邮件同理：转发整封线程，等于把早期未打码的签名和工单一并送出。

短链和二维码解决不了正文。上一篇写过，短链只是跳转层。这里要补一句：有人把「用户 13800138000 的订单」写进页面标题或 UTM 的 utm_content，链接洗干净之后，标题和正文还在。链接清洗和文本打码是两道工序，不要互相替代。

常见误区

「遮了后四位就够。」对手机号，只留后四、露出前七，对方仍可能结合社工库补全。前三后四是常见折中，不是数学证明。对身份证，留下出生日期等于没做完。

「HTTPS 已经保护隐私。」HTTPS 挡住的是传输路径上的窃听者。接收方、群成员、工单系统的管理员，仍然看得到你贴进去的明文。你要减少的是转发出去的那一份里不必要的完整号码。

「打码等于可以公开发布。」去标识化之后，借助工单系统仍能定位到人。公开网页、对外案例和培训教材，需要的是拿不到额外信息也无法复原，那是匿名化，不是几个星号。

「规则扫过就不用看了。」拆开的号码（138 0013 8000）、用汉字写的「一三八」、图片里的证件、以及规则尚未收录的密钥前缀，都会漏。人工复核的对象是：结果里还能不能搜到完整原文，以及上下文是否仍能拼出同一个人。

从哪一步开始打码

先处理你今天就要发出去的那一段。复制到本地，先只动手机号，对照原文，再决定要不要动证件和邮箱。群公告和知识库里的旧记录可以后补，不必一次清全站历史。

若同一段里混着链接和正文，先按上一篇的对照表去掉 UTM 与点击 ID，再打码正文。一条消息里同时有订单号和手机号时，留下订单号，遮手机号，再读一遍句子是否还通。做完这一条，你就已经能回答本文的问题：必须打码的是能直接联系到人或动用账户的字段，不能乱遮的是打开同一条业务记录所必需的编号。

需要把可用的密码、恢复码或 API Key 交给指定的人时，不要把完整密钥写进工单，也不要只靠掩码「假装没给」。用阅后即焚生成一次性链接；需要可反复解密的附件则走文件加密盒，在本机生成 .lock / .enc，口令走另一条消息。文本打码解决的是「讨论时少带完整号码」，不是密钥交换。

常见问题

打码之后，对方还知道这是谁吗？

常常还知道。工单号、姓名和掩码手机号叠在一起，借助内部系统仍能定位。打码减少的是「不在系统里的人拿到完整号码就能拨打或冒用」，不是让文本变成匿名统计数据。

为什么有的 11 位数字没有被当成手机号？

没有大陆手机形态、也没有 + 或分隔符的长数字，更可能是订单号。一律按电话处理，会把业务定位符遮掉。拿不准时先留着，只处理带 1[3-9] 或 + 的项，再人工标其余。

银行卡只留后四位，合规吗？

PCI DSS 对展示卡号的上限是前六后四；只留后四位更收，通常够对尾号。这仍然不是「可以发到公开渠道」。完整卡号加姓名不应出现在群聊里。

脱敏需要注册吗？原文会不会上传？

不需要注册。把完整工单交给会上传原文的网站，才有日志风险。本地处理时，原文留在当前标签页；你要核对的是 Network 里有没有把证件号或邮箱全文发到第三方，以及结果里是否还能搜到未遮的完整号码。