简介一款基于 Python 开发的敏感文件扫描工具面向需要保护个人及企业敏感信息的普通用户、安全运维人员与 Python 学习者。软件可精准识别身份证号、银行卡号、手机号、邮箱、密码等敏感数据支持 TXT、DOC、DOCX、PDF、XLS、XLSX、PPT、PPTX 等常见格式采用正则匹配引擎实现毫秒级检测全程本地扫描不上传确保隐私不外泄。压缩包共 79 个文件约 337MB涵盖 19 个 Python 源码文件、可直接运行的 exe 程序、39 个 pyc 缓存文件、打包构建目录、配置文件与 6 份 Markdown 说明文档含快速打包指南、加密解密工具使用说明等目录结构清晰。已有 186 人学习下载适合需要快速部署隐私扫描方案、学习本地正则匹配实现或二次开发自定义扫描规则的技术人员。1. 扫描大师这类敏感文件扫描工具究竟在解决什么痛点想象一个场景你是一家初创公司的技术负责人某天合规部门突然要求检查全公司电脑里是否有违规存储的个人信息。你用脚本全盘搜索*.xlsx、*.docx结果在同事的桌面文件夹里翻出了一堆带有身份证号、手机号的客户登记表有些甚至直接放在名为内部资料的压缩包里。这时候你需要的不是网管式的漫无目的翻找而是一个能自定义规则、精准捕捉特定敏感数据的扫描工具。扫描大师这类工具解决的正是这个需求把散落在磁盘角落、压缩包内部、甚至备份镜像里的身份证号、手机号、邮箱地址自动揪出来生成一份可以拿去汇报、整改的报告。这类工具不是杀毒软件它不判断文件是否有害只判断文件是否携带你定义的敏感信息。它可以是一条命令行也可以是一个带界面的卫士。手头这台机器、这台服务器、这批历史备份里到底躺着多少敏感数据只有扫过才知道。适合谁用一是要做合规自查的运维和开发二是对个人隐私比较在意的普通用户——想看看自己网盘备份里是不是藏着几年前上传的身份证照片。这篇文章不打算讨论某个闭源软件的界面按钮而是把自定义敏感文件扫描这件事的完整落地路径拆开规则怎么设计、压缩包怎么处理、坑在哪里、结果怎么用。2. 敏感数据检测的核心原理正则规则、指纹匹配与自定义规则设计2.1 为什么内置规则永远不够用市面上很多敏感文件扫描工具提供快速扫描按钮点一下就开始跑跑完告诉你找到了多少手机号、多少身份证。这种内置规则最大的问题是你不知道它匹配了什么也没法调整。比如内置规则把座机号码也当成手机号或者把社保卡号当成身份证号误报刷屏真正的问题反而不容易暴露。自定义规则的思路完全不同规则由你定义匹配逻辑对你的扫描范围和数据类型完全透明。底层技术不外乎两种。第一是正则表达式匹配把目标数据的格式特征描述成模式串比如连续18位数字、1开头11位数字这种第二是内容指纹匹配对已知敏感文件的哈希值建库扫到相同哈希的文件直接命中比如公司下发过一份含员工身份证的Excel模板把它的MD5记下来之后任何人改个文件名另存也能被认出来。实际做扫描工具时两种技术通常会混合使用。正则负责抓格式符合但内容未知的新数据指纹负责抓内容完全没变但换了马甲的老数据。正则的问题在于规则太宽会误报太严会漏报指纹的问题在于只对一模一样的文件有效任何字节改动都会失效。这也是为什么自定义规则的熟练度直接决定一个扫描工具是玩具还是生产力。2.2 身份证、手机号、邮箱的规则怎么写三个典型正则示例最基础的是手机号匹配。中国大陆手机号是11位以1开头第二位通常是3、5、7、8、9。但直接写1[3-9]\d{9}会匹配出大量非手机号比如一串以13开头的QQ号。更稳的做法是匹配后做一次前置字符检查确认手机号不是某个更长数字串的一部分。import re # 手机号11位1开头第二位3-9前后不能是数字或字母 phone_pattern re.compile(r(?!\d)(?![0-9a-zA-Z])1[3-9]\d{9}(?!\d)) # 邮箱常见邮箱格式限制域名长度避免把网址当邮箱 email_pattern re.compile(r\b[A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}\b) # 身份证18位前17位数字最后一位可能是数字或X idcard_pattern re.compile(r\b\d{17}[\dXx]\b)这段代码用(?!\d)和(?!\d)做边界限定避免12345678901385123456这种长串中间被截出手机号。邮箱正则里的\b用于单词边界。身份证的规则到这里只是第一关18位数字串很常见——订单号、信贷编号都可能是18位数字所以必须加上校验码验证。身份证最后一位是校验码由前17位按加权因子计算得出。正则只能筛出长得像的校验码能把假货剔除大半。一个完整的自定义规则应该分成两步先用正则粗筛再用算法精验。这一步是扫描工具是否可信的分水岭。2.3 规则引擎的匹配流程与命中判定扫描工具的运行逻辑一般来说是这样一个流水线遍历指定目录按扩展名或文件签名判断文件类型文本类文件直接按行读二进制文件先经过编码探测再转成文本Office文档则先解压提取内部XML然后喂给规则引擎。规则引擎把每一条规则编译成独立的自动机对文本做一次扫描所有规则同时跑而不用每来一条规则就重新读一遍文件。命中之后工具要记录的不仅是命中的字符串本身还包括文件路径、行号、上下文内容。只记录一个匹配到的号码后续人工复核时你根本不知道它在哪一行、前后是什么内容根本无法判断是真实客户数据还是测试样本。我做扫描工具时至少会保存命中的前后各50字作为上下文摘要。规则引擎还有一个关键参数叫每条规则的命中上限比如一个文件里匹配到1000个手机号就没必要继续记录更多了否则结果文件会爆炸。3. 把扫描大师跑起来自定义扫描任务的最小可复现方案3.1 安装与初始化需要准备哪些环境扫描工具如果只依赖Python标准库部署起来最省事。文本扫描、ZIP解压、目录遍历标准库都能覆盖但RAR解压需要第三方库另外检测Office文档里的内容结构最好有一个openpyxl或者至少能处理XML的库。我用的是Python 3.9以上版本配合rarfile库处理RARopenpyxl处理Excel。初始化环境的时候有两条路。第一条是全量安装pip install rarfile openpyxl。第二条是纯标准库方案先不装任何东西用zipfile处理ZIP用email库解析.eml邮件备份把RAR文件的扫描先挂起等真正遇到RAR时再补装rarfile。我一般会选择全量安装因为扫描过程中突然发现缺库中断重启的成本远高于一开始就装好。rarfile有一个前提它本身不是解压器只是一个封装真正干活的是系统里的unar或者WinRAR命令行工具。Windows上装了WinRAR之后rarfile会尝试自动调用UnRAR.exe。Linux上建议安装unar或者unrar-free。没装底层工具rarfile会在解压时直接抛RarCannotExec异常这个坑我踩过不止一次。3.2 配置一个扫描任务路径、规则、输出把规则和扫描参数分开写是让工具可复用的关键。我习惯把规则放在一个单独的Python模块里扫描脚本只负责读文件不关心规则细节反过来规则模块也只暴露一个match(text)方法不关心文件从哪来。这样换一套规则就等于换一个插件扫描任务本身不用改。下面的代码是一个最小配置框架# rules.py import re RULES { phone: { description: 中国大陆手机号, pattern: re.compile(r(?!\d)(?![0-9a-zA-Z])1[3-9]\d{9}(?!\d)), verify: lambda x: True }, idcard: { description: 身份证号(带校验), pattern: re.compile(r\b\d{17}[\dXx]\b), verify: check_idcard # 校验码验证函数 }, email: { description: 邮箱地址, pattern: re.compile(r\b[A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Za-z]{2,}\b), verify: lambda x: True } }这个配置结构里有pattern和verify两个字段前者负责格式粗筛后者负责内容精验。verify函数接收命中的字符串返回True/False。为手机号写lambda x: True是因为格式校验对手机号已经够用身份证必须走校验码逻辑。扫描脚本会先把pattern.finditer的所有命中收集起来再逐条跑verify两条都过才算最终命中。3.3 命令行一次扫描的完整过程启动扫描就是一个命令行参数的事不需要图形界面。下面这个命令是典型用法python scan.py --path D:\客户资料 --rules phone,idcard,email --output result.json --hotfix--path指定扫描目录--rules用逗号分隔要启用的规则--output指定结果文件--hotfix表示自动忽略系统目录和临时文件。第一次跑建议不加--hotfix先看全量结果因为系统目录里的异常发现有时候更值得注意。扫描过程中要关注两个指标。第一个是命中率如果扫了10万个文件只有3个命中先别急着高兴可能是规则写得太严或者文件编码识别失败导致内容根本没被正确提取。第二个是扫描耗时如果单文件平均耗时超过50毫秒要检查是不是在做无意义的全文正则回溯。实际的扫描循环大概长这样for root, dirs, files in os.walk(path): for fname in files: fpath os.path.join(root, fname) text extract_text(fpath) if text: matches scan_text(text, rules) if matches: record(fpath, matches)extract_text内部判断扩展名.txt/.log/.csv直接用二进制模式读取并按utf-8、gbk顺序尝试解码.docx/.xlsx先解压再提取XML文本.rar/.zip先解压到临时目录再递归扫描。这个函数是性能瓶颈文件大、编码杂的时候90%的耗时都花在这里。扫描结果输出成JSON记录命中的文件路径、规则名、命中字符串和上下文。结果文件本身就是一份可审计的清单直接从扫描完成跳到整改清单不用二次加工。输出JSON而不是CSV是因为字段长度不固定CSV到Excel里容易截断JSON后续写脚本处理起来更顺手。4. 加密压缩包里的敏感文件怎么扫RAR 与 ZIP 的解压扫描策略4.1 为什么压缩包是敏感文件的重灾区敏感资料最容易藏身的地方不是明文文件夹而是压缩包。原因很直接压缩包是一种归档形态文件归档进去之后容易被遗忘同时压缩包自带体积小的优势方便通过聊天工具、邮件转发收件人解压后随手放在桌面从来没想过里面包含身份证复印件。还有一个现实因素扫描工具的默认配置往往只递归扫描目录不进入压缩包内部压缩包里的敏感文件就成了监管盲区。做扫描大师这类工具压缩包支持一定是核心卖点之一也是自定义扫描里最容易被低估的一环。4.2 用 Python 自动解压并扫描 RAR 文件的实现处理RAR文件首先要有底层支持。rarfile库是Python侧的操作接口但真正解压依赖系统安装的UnRAR.exe或unar。代码层面可以这样写import rarfile import tempfile, os rarfile.UNRAR_TOOL UnRAR.exe # Windows下指定路径 def scan_rar(rar_path, rules, temp_root): with rarfile.RarFile(rar_path) as rf: for info in rf.infolist(): if info.is_dir(): continue target os.path.join(temp_root, info.filename) rf.extract(info, pathtemp_root) text extract_text(target) if text: for rule in rules: hits rule.match(text) if hits: report({ archive: rar_path, inner_file: info.filename, rule: rule.name, hits: hits })这段代码要把temp_root放在有足够空间的磁盘上因为解压会释放原始文件大小。参数说明info.filename是压缩包内的相对路径从临时目录拼接回去要防止路径穿越如果是损坏的RAR包extract会抛RarCRCError需要单独捕获。生产环境里我会限制单文件解压大小比如超过500MB的RAR条目就直接跳过毕竟扫描目标是敏感信息不是文件系统备份恢复。ZIP文件的处理就更简单一些Python自带的zipfile就能解压但有一个坑ZIP条目文件名可能使用cp437编码中文字符会变成乱码。遇到ZipFile读取文件名出现?符号时可以手动尝试encode(cp437).decode(gbk)来恢复中文文件名。4.3 遇到有密码的 RAR 文件怎么办合法场景下的处理思路压缩包里带密码是非常常见的事。很多部门习惯把含个人信息的Excel压缩后加密码发到群里密码写在同一个群里等于没加密。扫描工具遇到加密RAR会直接报错因为rarfile解压到加密条目时如果没有密码就会抛RarWrongPassword异常。正确的做法是扫描时对加密RAR文件单独标记先解压能解压的对加密的条目输出一个需要人工处理列表而不是让整个扫描任务中断。有人会想到用rar密码移除、advanced rar password recovery这类恢复工具。先说清楚边界如果你自己就是文件的所有者知道密码的找回方式和工具操作都属于正常范畴比如加密的课程资料忘记解压密码通过恢复工具找回自己设定的密码没有法律问题。但如果你手里的压缩包来源不明试图用暴力破解打开别人的加密文件这已经不是技术问题而是合规问题。扫描工具的定位是发现风险不是破解风险。对于自己拥有但忘记密码的RAR文件我建议优先走官方找回流程而不是上来就跑暴力破解。WinRAR本身不提供密码找回功能第三方工具恢复密码的成功率取决于密码长度和复杂度。一个8位纯数字密码用单机CPU跑运气好几分钟运气不好几天。但6位以内纯数字密码基本上算是秒破这类密码在内部的敏感文件压缩包中反而最常见。我的习惯是扫描过程中发现加密RAR时直接列入待补密码清单后续通过内部密码台账查询查不到再考虑恢复工具并且只用在自己有权访问的归档上。扫描深度的问题也在这里暴露出一个常见矛盾既要扫描压缩包内部又不能无限递归下去。RAR里面套RAR、ZIP里面套ZIP的嵌套结构在真实环境中确实存在。我会设置递归深度为3层超过之后停止解压并标记为深度受限。设定这个值前要明确一点敏感文件通常不会嵌套超过3层藏得太深的文件反而不像是无心泄露更像是故意隐藏。5. 扫描大师避坑指南误报、漏报和性能坑一次说清5.1 身份证校验码不校验误报率翻倍现象规则只写了\d{17}[\dXx]扫描结果里命中数千条身份证号人工复核后发现一半是订单号、流水号、ISBN编号真正是身份证的不到三成。原因18位数字串的格式特征太宽泛任何固定长度数字序列都符合。解决必须在verify函数里实现身份证校验码算法。校验码是前17位乘加权因子求和后对11取模映射表得出第18位。把这一步补上误报率能降一个数量级。这里有一个更隐蔽的坑很多身份证号是从Excel里导出的前导零被吃掉18位变成17位还有单元格被设成科学计数法身份证显示成4.10227E17。这种情况下正则完全失效。解决的办法是扫描Excel时不仅提取显示文本还要提取单元格的原始数值并做格式还原。openpyxl读取单元格时拿到的是数值类型需要按yyyy-mm-dd之类格式反推回原始字符串这是个细活但值得做。5.2 大文件直接卡死内存溢出与编码错误的处理现象扫描一个2GB的日志文件时Python进程内存占用飙升到好几个GB然后系统开始换页整个机器卡成幻灯片。原因一次性把整个文件读进内存做正则匹配对文本数据量来说是最省事的写法但也是最耗内存的写法。解决按块读取每块1MB保留末尾几百字节的边界重叠防止手机号跨块截断。代码写法是def scan_large_file(fpath, rules, chunk_size1024*1024): last_tail with open(fpath, rb) as f: while True: chunk f.read(chunk_size) if not chunk: break text try_decode(last_tail chunk) for rule in rules: rule.feed(text) last_tail chunk[-256:]理解这段代码的关键在于last_tail。假设手机号前半段在上一块末尾后半段在当前块开头不使用tail缓冲就会漏报。文本解码也容易翻车文件是GBK编码你用UTF-8解码得到一堆乱码正则自然匹配不到。处理方式是把try_decode做成依次尝试UTF-8、GBK、Latin-1并用解码后是否包含常见中文字符作为判断依据。如果三种编码都解出乱码就放弃扫描而不是直接崩溃。5.3 扫描到压缩包外层就停下递归深度设置与性能的平衡现象目录里有一个名为备份2024.rar的压缩包你明知道里面有敏感文件但扫描结果里完全没有它的记录。原因扫描脚本只对普通文件做了内容提取没把.rar/.zip纳入递归解压流程或者解压层数设为了1。解决把压缩包处理逻辑和普通文件扫描统一起来。扫描到压缩包时先把解压后的文件列表加入待扫描队列。要注意的是这种统一处理很容易形成递归风暴所以必须设置深度上限并且统一走临时目录。一个典型的配置是扫描深度3层每层限制解压文件总大小500MB超过就跳过。临时目录用事后自动清理因为解压出来的文件本身就是敏感文件留在磁盘上等于自己制造了一个新的泄露点。5.4 规则写得太宽日志刷屏现象邮箱规则\w\w.\w上线后扫描结果炸了。日志里全是aaabbb.com这种测试字符串实际有威胁的泄露反而淹没在海量结果里。原因规则没有限制域名格式和字符类型匹配到了大量代码中的占位符、配置文件里的示例地址。解决把邮箱规则收窄为域名优先列表比如qq.com、163.com、gmail.com这些常见邮箱域名同时排除.png、.jpg等资源文件里的字符串。更进一步可以建立一个上下文黑名单如果命中字符串的前后50字里包含example、test、placeholder等标记则不记录。规则宁严勿松漏报可以通过多写几条互补规则来弥补误报太多会导致没人愿意看报告。5.5 密码恢复工具救急但不该成为依赖现象遇到加密RAR文件网上搜rar密码移除、advanced rar password recovery下载工具开始跑破解跑了一晚上没出结果。原因密码不是纯短数字字典和暴力双管齐下也撬不开。解决先确认文件所有权找密码台账确实找不到再考虑恢复工具而且要优先选择支持GPU加速的版本CPU破解16位复杂度密码的时间是以年为单位计算的。更靠谱的方案是在扫描流程里加入密码提醒环节——扫描到加密压缩包自动记录文件名和来源路径发给归档负责人确认密码而不是让操作员现场破解。扫描大师这类工具把加密包扫描做成显式功能本意是让压缩包不再成为藏污纳垢的角落而不是把密码破解也包进来。6. 让扫描结果真正可用三招减少误报、固化基线6.1 命中结果加上下文摘要二次核验成本减半扫描报告里如果只有路径和命中的号码审计人员必须打开原始文件核对。给每条命中附带前后120字符的上下文就能在结果里直接判断是真实数据还是误报。做法很简单正则finditer命中的时候取start-120到end120的切片替换掉不可打印字符存储进结果JSON。实际用下来这个功能让一份上千条命中的报告人工复核时间从两天压缩到三小时。注意切片边界不要落在代理对字符中间Python字符串切片按码点走遇到Emoji或者生僻字切片可能切断代理对导致后续处理报错。稳妥的办法是使用text[start:end]之后做一次errorsignore编码清理。6.2 把白名单路径做成基线增量扫描扫描不能每次全量跑数据量大了以后全量扫描耗时太长。把已知安全的位置和文件加入白名单后续扫描只针对白名单之外的新增和变化文件。实现上可以用文件修改时间mtime做增量判断上次扫描时间之后的文件才进入扫描队列。每次扫描结束后把文件路径、大小、mtime存成一个基线文件。下一次扫描时对照基线mtime没变的文件直接跳过。基线文件本身也是敏感信息——它记录了哪些路径存在数据所以要对基线文件做权限控制最好和扫描结果放一起加密保存。增量扫描最大的陷阱是只按mtime判断会漏掉内容变了但修改时间没变的情况比如用工具直接改文件内容再恢复时间戳。对安全敏感的扫描任务定期做一次全量扫描兜底是必要的比如每季度一次。增量扫描服务于日常高频监控全量扫描服务于审计节点两条腿走路。6.3 定时任务与通知扫描从一次性变成常态化单次扫描只能证明当前没有敏感文件一旦有人往磁盘里拷入新文件之前的扫描结果就作废了。把扫描挂进定时任务里每天凌晨跑一次问题才真正可控。Windows上用计划任务Linux上用cron扫描结果直接追加到日志文件。发现新的命中时自动调用邮件接口或Webhook通知负责人。这里有个细节通知内容不要包含命中的完整手机号和身份证只报数量、路径、命中的规则名称完整信息在结果文件里。结果文件本身带访问控制因为通知链路一旦泄露等于把敏感信息又送出去一份。我自己的习惯是把上一次扫描结果称为已知清单新命中与已知清单做差集后再通知。这样就不会天天凌晨三点收到”发现手机号”的告警——基线里的数据是已知的不值得打扰人。等到告警安静下来常态化的扫描才有意义它盯着的是变化不是存量。扫描工具做得再好如果报告没人看等于白做。希望每个做敏感文件扫描的人都能把结果管起来让扫描真正成为个人信息保护的一道防线也帮到你所在的团队少踩几个坑。本文还有配套的精品资源点击获取