客户名单发出去之前：我用文档脱敏工具兜了个底

2026年9月18日隐私文档处理工具推荐

上周三下午，同事在群里问能不能把客户登记表发给做数据清洗的外包。那份表两百多行，姓名、手机、身份证、收货地址一应俱全。我第一反应是“打码不就行了”，结果真动手才发现这事比想象中麻烦得多。

手动打码的第一个坑：你以为看全了，其实没有

我最初的做法很朴素——开着表格从头滚到尾，看到手机号就改成 138****5678。四十分钟过去，眼睛都花了。第二天对方回了个消息：“表里第 137 行还有个完整的身份证号。”

我翻回去一看，那个身份证号前面多了个空格，我滚动的时候眼睛直接跳过去了。

手动打码的问题不是慢，是不可靠。人眼在重复内容上会形成节奏，一旦某行的格式跟前面不一样（多了空格、换了列顺序、藏在一句话中间），节奏被打断却不一定会被注意到。而漏一条身份证号的代价，比多花四十分钟大得多。

第二版我学乖了，写了个脚本把所有 11 位数字都换成星号。这下不漏了，但外包那边又找过来了：他们需要按客户去重统计人数，现在全是一样的星号，没法判断哪些记录属于同一个人。

这就是脱敏里最容易被忽略的一对矛盾：

「换成稳定代号」是我最后选的方案。原理很简单：对同一个原值做一次哈希，得到固定长度的代号，比如 手机号#a3f2。同一个号码每次都是同一个代号，不同号码几乎不会撞车。这样外包能统计出“这份表里有 187 个独立客户”，但拿不到任何一个真实号码。

工具最终用的是正则加校验位这一套，分了三档严格度：

第一档，格式唯一、几乎不会误报的。 手机号（1 开头的 11 位）、邮箱、URL、IPv4。这些直接上正则，闭着眼都不会错。

第二档，格式像但会撞车的，必须加校验。 身份证号光看 18 位数字 会把订单号、流水号全抓进来；银行卡号光看 16-19 位数字 更离谱。所以我加了两条硬校验：

加了这两条之后，误报基本清零。代价是会漏掉校验位恰好算错的极少数真数据，但我宁可漏也不愿意把正常数字打成星号。

第三档，压根没有格式的，只能靠上下文。 中文姓名是这里最难的一块。“张伟”这两个字，跟“张伟董事长出席了会议”里的“张伟”在字面上没有任何区别。我的处理是只认三种情况：

前两种误报很低，默认开；第三种误报明显，做成开关，需要高召回时才打开。上次处理一份会议纪要，开着第三种模式，结果“高山流水”被识别成了人名——这就是姓氏推断的代价。

把那段登记表丢进工具，命中统计长这样：

姓名 187 处
手机号 187 处
身份证 172 处
住址 168 处
邮箱 43 处

172 而不是 187，是因为有 15 行填的是护照号或者干脆空着。这种“数量对不上”的提示其实很有用——它告诉你数据本身有缺口，而不是工具漏了。

输出长这样：

姓名：张*，联系电话 138****5678
身份证号：110101********123X
收货地址：北京市朝阳区****************

住址识别靠格式。 我的规则是“省市区 + 路名 + 门牌号”，遇到“朝阳区那家星巴克旁边的小区”这种口语描述就抓瞎了。这类只能人工补。

同一份数据里同音不同字。 “张伟”和“张玮”在稳定代号模式下是两个代号，但它们可能是同一个人。要做真正的实体对齐得上 NLP，不是一个前端工具该干的事。

打码后的文本长度会变。 保留首尾模式输出的长度跟原文不一样，如果你后面还有按字节偏移处理数据的流程，需要重新定位。

最后说个原则问题。脱敏这件事，如果工具本身要把你的原文上传到服务器，那你要防的对象就多了一个——工具的运营方。

一份两百行的客户名单，里面是最值钱也最危险的东西：真实姓名配真实身份证号。为了省四十分钟把它传给一个你并不了解的在线服务，这笔账怎么算都不划算。

所以我做的这个文档脱敏工具，整个识别和打码过程都在浏览器里完成，文本一步都没有离开设备。你可以把网断掉再试，功能完全不受影响。

顺带一提，如果你只需要把手机号邮箱这类东西捞出来而不是抹掉，用文本提取更直接；如果要按自己的规则批量替换，批量替换支持多条规则和正则捕获组。

脱敏的难点从来不是“把字变成星号”，而是三个判断：哪些东西算敏感信息、打码到什么程度还能用、识别错了的代价谁承担。把这三件事想清楚，工具只是执行环节。