尧图网站建设 
简介这是一份 EnCase 4.20 取证分析工具资源面向数字取证调查人员、网络安全应急响应人员及司法鉴定从业者。该工具可获取各类系统磁盘镜像自动生成详细分析报告并支持以 RTF 或 HTML 格式导出方便证据整理与归档。内置图片查看器兼容 ATR、BMP、GIF、JPG、PNG、TIFF 等格式扩展时间标签可查看文件创建、最近访问或修改时间有助于还原文件活动时间线。同时支持 FAT16/32、NTFS、Macintosh HFS/HFS、Linux EXT2/3、UFS、JFS、UDF、ISO 9660 等主流文件系统并可用于 RAID 磁盘阵列分析适用面广。压缩包为 RAR 格式整体约 18.64MB目前已有 793 人学习使用适合需要开展电子数据取证与磁盘分析工作的技术人员快速上手。1. 做取证十年我仍不放掉 EnCase 4.20 的镜像与时间线接到检材先看系统是否被开过机是被动做法主动做法是趁早把底层扇区读出来固定成可验证的证据文件。EnCase 4.20 的界面和现代分析平台比确实显旧但它把镜像获取、文件系统识别和时间标签整理串在一条线上导入一个证据文件能同时面对 FAT、NTFS、EXT2/3、HFS 这些差异很大的卷。常规扣押检材上我用它做过完整镜像和报告导出减少大量手工记录。要注意这个版本不是全面自动化工具但它的分卷校验、RAID 处理逻辑在今天的取证链里仍然能复用。下面从写保护和 E01 镜像写起到 HTML 报告解析收尾。2. E01 镜像与写保护链路EnCase 4.20 的证据闭环2.1 为什么先要 E01E01 是 EnCase 证据文件格式的常见叫法。和 dd 出来的裸镜像相比E01 在获取阶段就把证据链需求考虑了进去文件分段、块级校验、总体哈希全在镜像容器里。做民事诉讼或刑事案件时交接的镜像若能直接验证完整性能省掉“你给的镜像我没动过”的解释成本。维度E01 证据文件dd/裸镜像存储形式多段文件每段独立单文件或磁盘整块复制压缩默认 LZ 压缩空间占用小无压缩容量即空间完整性块级 CRC 加整体 MD5/SHA需手工算 hashdeep 记录证据信息内嵌证据编号、获取人、时间无元数据靠外围文档兼容性EnCase、FTK、X-Ways 可读多数工具可读但需额外说明来源这个版本里我一般把分段大小设置为 2 GB不是容量不够而是后续转存或传输时单个文件超过 4 GB 会遇到某些中间设备限制另外分段文件损坏时只需要重新获取坏掉的段不用全盘重来。2.1.1 压缩率不要拉到最高EnCase 4.20 的证据文件压缩比例可以调。默认压缩速度较快但取证镜像可能包含大量已删除文件这些区域的熵值不定强行最高压缩反而浪费时间。我的习惯是用默认压缩只有在目标盘全是文本数据时再手动调高换取 40% 到 50% 的容量节省。注意任何镜像参数在开始获取前都要写在案件记录里。压缩率不是越极端越好之后换工具重算哈希时参数不同不会影响哈希但报告里不写清会影响后续审计。2.2 写保护是不能省的一环静态检材必须接写保护器。常见做法是硬件写保护器接 SATA 或 USB 桥接再让宿主机把盘识别为只读设备。先枚举磁盘总线确认没有接错盘位# 1) 查看当前磁盘接入情况TRANusb 的盘要确认是否经过写保护桥 lsblk -d -o NAME,TRAN,VENDOR,MODEL,SIZE # 2) 有写保护时盘应返回只读1 表示只读 blockdev --getro /dev/sde上面第一行列出块设备名称、总线类型、厂商和型号用来建立“哪个盘符对应哪个物理盘”的对应关系。第二行查询目标盘是否为只读返回 1 才可继续如果返回 0说明写保护链路没生效继续获取会污染原始介质。这个步骤很基础但我见过不少临时用读卡器接入然后整盘挂载的分析员最后被辩护律师盯住时间戳不放。2.3 EnCase 4.20 获取镜像的完整操作在 EnCase 4.20 里新建证据文件后把来源设备选成刚才确认过的盘一般会要求填写证据编号、勘查号、获取人。分段大小、哈希算法尽量在界面中一次设好。启动后不要动宿主机等它自动生成证据文件。获取完成后Case 面板会自动列出解析出的分区结构之后导出报告的核心数据就是从这里读出来的。若中途报哈希不匹配基本是源盘被写保护器断开或线缆松动先检查链路不要直接忽略继续。硬件写保护器如果接触不良镜像读取会偶发校验错误这也是为什么 E01 要比裸镜像更适合现场交接。3. 从 FAT16 到 HFSEnCase 4.20 的文件系统时间标签3.1 EnCase 4.20 的文件系统支持矩阵这个版本支持的文件系统列表经常被当作宣传点但实际使用中要区分“能识别卷”和“能完整解析删除结构”。就常规检材而言下面的矩阵能帮我快速决定用哪个模块读文件系统典型介质时间标签特点FAT16/FAT32U 盘、旧存储卡目录项有创建时间时间粒度 2 秒NTFSWindows 系统盘$MFT 里有创建/访问/修改/条目修改HFS/HFS苹果旧式电脑盘基准时间 1904-01-01需转换Linux EXT2/3Linux 设备、嵌入式板卡有 ctime不是创建时间而是 inode 状态变更UFS/FFSSolaris、BSD 服务器文件标记和分区超块时间更重要CDFS/Joliet/UDF光盘介质卷描述符的时间文件级时间精度有限TiVo Series One/Two电视录像设备文件表是私有结构常提取录像指纹AIX JFS、ReiserFS冷门服务器一般先看磁盘签名再决定是否需额外支持刻意把 EXT2/3 的“ctime”放在这里是因为 Linux 里stat输出的 change time 经常被误写成创建时间。EnCase 4.20 的界面里有时也显示为“change time”需要在报告里把它翻译成“inode 变更时间”否则法律意见书上会出现一个不存在的创建时间。3.2 扩展时间标签把 MACE 摊开来看EnCase 4.20 有一个“扩展时间标签Extended Timestamp”功能可以查看文件的创建时间、最近访问时间、最近写入时间。NTFS 下常见的是 MACE 四字段Modified, Accessed, Created, Entry Modified。但这四个字段不是独立的把文件从外盘复制进 NTFS创建时间会变成复制时刻修改时间保留原始数据里的最后修改时间访问时间可能在预览时被改动。因此取到时间字段后要回到文件系统原生活动里去验证。浏览嵌入卷里的图片证据时EnCase 4.20 自带的图片查看器支持 ATR、BMP、GIF、JPG、PNG、TIFF 格式逐张查看时不用另开外部工具也能避免外部看图器改写文件访问时间的风险。3.2.1 用 stat 和 PowerShell 交叉验证时间字段如果证据盘已经获取成镜像可以在 Linux 上以只读方式挂载验证mkdir -p /mnt/evd mount -o loop,ro /case/disk.img /mnt/evd # 注意取证环境要保证内核支持对应文件系统尽量用只读挂载 stat -c file%n birth%w access%x modify%y change%z /mnt/evd/file.txtbirth字段只在文件系统支持时才有输出NTFS 和 FAT32 一般能看到EXT2/3 没有出生时间change%z对应 inode 变更时间不是文件创建时间。如果 EnCase 报告的创建时间和这里冲突优先检查镜像本身是否有更新而不是急着改结论。Windows 下可用 PowerShell 看同样文件# 检查同一字段在系统层的表现用于对比 EnCase 报告 Get-Item E:\file.txt | Select-Object FullName, CreationTime, LastAccessTime, LastWriteTime比较两个结果时注意 FAT 的创建时间精度到秒NTFS 的高精度会带上纳秒系统之间相差 1 秒以内属于正常。相差太大时要去查文件的$STANDARD_INFORMATION和$FILE_NAME属性后者常常保留原始文件名时间。3.3 访问时间常常是最不可靠的字段很多 Windows 版本默认禁用 NTFS 更新访问时间或只做延迟更新这使LastAccessTime显示为系统策略允许的历史值。取证上把它当作“用户最后是否打开过”只有辅助意义必须结合 prefetch、日志和链接文件判断。EnCase 4.20 适合先把四类时间全列出来再和案件中的日志关联而不是单独拿访问时间下结论。4. RAID 阵列怎么拆盘序、条带大小与扇区偏移4.1 阵列在取证里的三种状态RAID 作为证据载体的难点不在于读盘而在于“镜像后如何还原可见卷”。EnCase 4.20 声称支持 RAID 磁盘阵列实际上要区分它能在识别阵列参数后把多块盘作为一个逻辑卷解析但如果阵列已经丢失元数据仍然要手动分析盘序。RAID 级别错误容忍取证最关键参数典型症状RAID0无盘序和条带大小缺一块盘立即全完RAID1镜像盘序、源盘优先级两块盘内容一样仍要逐盘哈希RAID5单盘容错盘序、条带大小、奇偶校验布局参数错则全盘乱码RAID1 看似简单但两块镜像盘可能因重建不同步而产生差异。我的做法是对所有成员盘都做完整 E01 镜像再在分析阶段比对差异不做“只取一块盘”的赌注。4.2 用 mdadm 元数据确定盘序如果阵列来自 Linux 软 RAIDmdadm可以直接输出关键参数。先把每块只读接入然后执行# 查看每块成员盘的角色和阵列状态 mdadm --examine /dev/sdb /dev/sdc /dev/sdd # 如果阵列已在系统上装配再确认详细参数 mdadm --detail /dev/md0 | grep -E Raid Level|Chunk Size|Array Sizemdadm --examine里最有用的是设备角色例如Device Role : Active device 0这就是原始盘序。Chunk Size对应条带大小它决定 EnCase 4.20 里填的 chunk 参数。没有元数据时可以尝试 32K、64K、128K 这几档常见值在卷起始位置能否找到文件系统签名作为判断标准。4.2.1 硬件 RAID 卡没有元数据可用时服务器硬件 RAID 卡在创建阵列后盘上不一定保留各盘的独立签名这时需要先读取控制器状态。常见做法是进入 RAID 配置界面记录磁盘槽位和逻辑盘映射再把整阵列的逻辑卷作为单个磁盘取证。对 EnCase 4.20 而言只要逻辑卷能被 Windows 识别为块设备就可以按普通磁盘流程获取镜像。厂商管理工具例如常见的storcli用于导出控制器日志# 显示控制器基本信息和磁盘组配置 storcli /c0 show | grep -E Interface|Data Capacity|DG # 显示虚拟磁盘类型与扇区设置 storcli /c0/v0 show all | grep -E TYPE|Initialized|Sec上面命令展示控制器号和虚拟磁盘属性作用是把逻辑卷几何参数存档方便后续重建时对照。硬件 RAID 卡因为缓存策略不同失败盘上面的“最后写入时间”经常和真实事件时间有偏差报告里要注明时间来源是控制器日志。4.3 重组后的三个校验点盘序和条带大小配好后我不会马上开 File 浏览先看三个点一是逻辑卷开头的引导扇区或分区表是否具有可识别签名二是文件系统的空闲区在 EnCase 的 Hex 视图中是否连续若频繁出现空洞说明条带计算偏了三是随机打开一个大文件把文件头尾的簇号和条带大小代入确认前后逻辑块映射一致。都不行时把每块盘的起始扇区分别做 64 字节比较找出彼此偏移再回填进 RAID 参数。5. 从 EnCase 4.20 导出的 HTML 报告里批量提取文件行为5.1 报告里值得保留的证据元素EnCase 4.20 导出 RTF 或 HTML 报告会包含分区信息、文件列表、哈希、时间标签。HTML 版本适合做二次加工但报告页数一多就难翻。我一般提取四类字段文件路径、证据文件哈希、创建时间、最近写入时间。5.2 用 Python 把 HTML 报告变成 CSV依赖 BeautifulSoup 就能处理大多数导出版本from bs4 import BeautifulSoup from pathlib import Path soup BeautifulSoup( Path(report.html).read_text(encodingutf-8, errorsignore), html.parser, ) # 表头也写进 CSV避免以后列位对不上 with open(files.csv, w, encodingutf-8, newline) as f: for tr in soup.select(table tr): cells tr.find_all([td, th]) if cells: f.write(,.join(c.get_text(stripTrue) , for c in cells) \n)采用tr.find_all([td, th])是防止表头被跳过stripTrue去掉 HTML 里的换行和空格。得到 CSV 后用排序工具或 Excel 透视就能快速找同一时间段内被访问过的文件集合。注意导出的 HTML 表格列顺序与界面列顺序一致如果先改过界面显示字段再导出报告CSV 的列顺序会变脚本里不要写死索引按表头名称读取更稳。最后补充一个验证技巧比对两次报告的差异时别直接比文件列表先比Application Version和Export Date这两行环境不同会导致字段错位。每次手工操作后保留一份原始报告防止二次报告把关键时间覆盖。本文还有配套的精品资源点击获取 EnCase 4.20取证实战：E01镜像、文件系统时间线与RAID重组
简介这是一份 EnCase 4.20 取证分析工具资源面向数字取证调查人员、网络安全应急响应人员及司法鉴定从业者。该工具可获取各类系统磁盘镜像自动生成详细分析报告并支持以 RTF 或 HTML 格式导出方便证据整理与归档。内置图片查看器兼容 ATR、BMP、GIF、JPG、PNG、TIFF 等格式扩展时间标签可查看文件创建、最近访问或修改时间有助于还原文件活动时间线。同时支持 FAT16/32、NTFS、Macintosh HFS/HFS、Linux EXT2/3、UFS、JFS、UDF、ISO 9660 等主流文件系统并可用于 RAID 磁盘阵列分析适用面广。压缩包为 RAR 格式整体约 18.64MB目前已有 793 人学习使用适合需要开展电子数据取证与磁盘分析工作的技术人员快速上手。1. 做取证十年我仍不放掉 EnCase 4.20 的镜像与时间线接到检材先看系统是否被开过机是被动做法主动做法是趁早把底层扇区读出来固定成可验证的证据文件。EnCase 4.20 的界面和现代分析平台比确实显旧但它把镜像获取、文件系统识别和时间标签整理串在一条线上导入一个证据文件能同时面对 FAT、NTFS、EXT2/3、HFS 这些差异很大的卷。常规扣押检材上我用它做过完整镜像和报告导出减少大量手工记录。要注意这个版本不是全面自动化工具但它的分卷校验、RAID 处理逻辑在今天的取证链里仍然能复用。下面从写保护和 E01 镜像写起到 HTML 报告解析收尾。2. E01 镜像与写保护链路EnCase 4.20 的证据闭环2.1 为什么先要 E01E01 是 EnCase 证据文件格式的常见叫法。和 dd 出来的裸镜像相比E01 在获取阶段就把证据链需求考虑了进去文件分段、块级校验、总体哈希全在镜像容器里。做民事诉讼或刑事案件时交接的镜像若能直接验证完整性能省掉“你给的镜像我没动过”的解释成本。维度E01 证据文件dd/裸镜像存储形式多段文件每段独立单文件或磁盘整块复制压缩默认 LZ 压缩空间占用小无压缩容量即空间完整性块级 CRC 加整体 MD5/SHA需手工算 hashdeep 记录证据信息内嵌证据编号、获取人、时间无元数据靠外围文档兼容性EnCase、FTK、X-Ways 可读多数工具可读但需额外说明来源这个版本里我一般把分段大小设置为 2 GB不是容量不够而是后续转存或传输时单个文件超过 4 GB 会遇到某些中间设备限制另外分段文件损坏时只需要重新获取坏掉的段不用全盘重来。2.1.1 压缩率不要拉到最高EnCase 4.20 的证据文件压缩比例可以调。默认压缩速度较快但取证镜像可能包含大量已删除文件这些区域的熵值不定强行最高压缩反而浪费时间。我的习惯是用默认压缩只有在目标盘全是文本数据时再手动调高换取 40% 到 50% 的容量节省。注意任何镜像参数在开始获取前都要写在案件记录里。压缩率不是越极端越好之后换工具重算哈希时参数不同不会影响哈希但报告里不写清会影响后续审计。2.2 写保护是不能省的一环静态检材必须接写保护器。常见做法是硬件写保护器接 SATA 或 USB 桥接再让宿主机把盘识别为只读设备。先枚举磁盘总线确认没有接错盘位# 1) 查看当前磁盘接入情况TRANusb 的盘要确认是否经过写保护桥 lsblk -d -o NAME,TRAN,VENDOR,MODEL,SIZE # 2) 有写保护时盘应返回只读1 表示只读 blockdev --getro /dev/sde上面第一行列出块设备名称、总线类型、厂商和型号用来建立“哪个盘符对应哪个物理盘”的对应关系。第二行查询目标盘是否为只读返回 1 才可继续如果返回 0说明写保护链路没生效继续获取会污染原始介质。这个步骤很基础但我见过不少临时用读卡器接入然后整盘挂载的分析员最后被辩护律师盯住时间戳不放。2.3 EnCase 4.20 获取镜像的完整操作在 EnCase 4.20 里新建证据文件后把来源设备选成刚才确认过的盘一般会要求填写证据编号、勘查号、获取人。分段大小、哈希算法尽量在界面中一次设好。启动后不要动宿主机等它自动生成证据文件。获取完成后Case 面板会自动列出解析出的分区结构之后导出报告的核心数据就是从这里读出来的。若中途报哈希不匹配基本是源盘被写保护器断开或线缆松动先检查链路不要直接忽略继续。硬件写保护器如果接触不良镜像读取会偶发校验错误这也是为什么 E01 要比裸镜像更适合现场交接。3. 从 FAT16 到 HFSEnCase 4.20 的文件系统时间标签3.1 EnCase 4.20 的文件系统支持矩阵这个版本支持的文件系统列表经常被当作宣传点但实际使用中要区分“能识别卷”和“能完整解析删除结构”。就常规检材而言下面的矩阵能帮我快速决定用哪个模块读文件系统典型介质时间标签特点FAT16/FAT32U 盘、旧存储卡目录项有创建时间时间粒度 2 秒NTFSWindows 系统盘$MFT 里有创建/访问/修改/条目修改HFS/HFS苹果旧式电脑盘基准时间 1904-01-01需转换Linux EXT2/3Linux 设备、嵌入式板卡有 ctime不是创建时间而是 inode 状态变更UFS/FFSSolaris、BSD 服务器文件标记和分区超块时间更重要CDFS/Joliet/UDF光盘介质卷描述符的时间文件级时间精度有限TiVo Series One/Two电视录像设备文件表是私有结构常提取录像指纹AIX JFS、ReiserFS冷门服务器一般先看磁盘签名再决定是否需额外支持刻意把 EXT2/3 的“ctime”放在这里是因为 Linux 里stat输出的 change time 经常被误写成创建时间。EnCase 4.20 的界面里有时也显示为“change time”需要在报告里把它翻译成“inode 变更时间”否则法律意见书上会出现一个不存在的创建时间。3.2 扩展时间标签把 MACE 摊开来看EnCase 4.20 有一个“扩展时间标签Extended Timestamp”功能可以查看文件的创建时间、最近访问时间、最近写入时间。NTFS 下常见的是 MACE 四字段Modified, Accessed, Created, Entry Modified。但这四个字段不是独立的把文件从外盘复制进 NTFS创建时间会变成复制时刻修改时间保留原始数据里的最后修改时间访问时间可能在预览时被改动。因此取到时间字段后要回到文件系统原生活动里去验证。浏览嵌入卷里的图片证据时EnCase 4.20 自带的图片查看器支持 ATR、BMP、GIF、JPG、PNG、TIFF 格式逐张查看时不用另开外部工具也能避免外部看图器改写文件访问时间的风险。3.2.1 用 stat 和 PowerShell 交叉验证时间字段如果证据盘已经获取成镜像可以在 Linux 上以只读方式挂载验证mkdir -p /mnt/evd mount -o loop,ro /case/disk.img /mnt/evd # 注意取证环境要保证内核支持对应文件系统尽量用只读挂载 stat -c file%n birth%w access%x modify%y change%z /mnt/evd/file.txtbirth字段只在文件系统支持时才有输出NTFS 和 FAT32 一般能看到EXT2/3 没有出生时间change%z对应 inode 变更时间不是文件创建时间。如果 EnCase 报告的创建时间和这里冲突优先检查镜像本身是否有更新而不是急着改结论。Windows 下可用 PowerShell 看同样文件# 检查同一字段在系统层的表现用于对比 EnCase 报告 Get-Item E:\file.txt | Select-Object FullName, CreationTime, LastAccessTime, LastWriteTime比较两个结果时注意 FAT 的创建时间精度到秒NTFS 的高精度会带上纳秒系统之间相差 1 秒以内属于正常。相差太大时要去查文件的$STANDARD_INFORMATION和$FILE_NAME属性后者常常保留原始文件名时间。3.3 访问时间常常是最不可靠的字段很多 Windows 版本默认禁用 NTFS 更新访问时间或只做延迟更新这使LastAccessTime显示为系统策略允许的历史值。取证上把它当作“用户最后是否打开过”只有辅助意义必须结合 prefetch、日志和链接文件判断。EnCase 4.20 适合先把四类时间全列出来再和案件中的日志关联而不是单独拿访问时间下结论。4. RAID 阵列怎么拆盘序、条带大小与扇区偏移4.1 阵列在取证里的三种状态RAID 作为证据载体的难点不在于读盘而在于“镜像后如何还原可见卷”。EnCase 4.20 声称支持 RAID 磁盘阵列实际上要区分它能在识别阵列参数后把多块盘作为一个逻辑卷解析但如果阵列已经丢失元数据仍然要手动分析盘序。RAID 级别错误容忍取证最关键参数典型症状RAID0无盘序和条带大小缺一块盘立即全完RAID1镜像盘序、源盘优先级两块盘内容一样仍要逐盘哈希RAID5单盘容错盘序、条带大小、奇偶校验布局参数错则全盘乱码RAID1 看似简单但两块镜像盘可能因重建不同步而产生差异。我的做法是对所有成员盘都做完整 E01 镜像再在分析阶段比对差异不做“只取一块盘”的赌注。4.2 用 mdadm 元数据确定盘序如果阵列来自 Linux 软 RAIDmdadm可以直接输出关键参数。先把每块只读接入然后执行# 查看每块成员盘的角色和阵列状态 mdadm --examine /dev/sdb /dev/sdc /dev/sdd # 如果阵列已在系统上装配再确认详细参数 mdadm --detail /dev/md0 | grep -E Raid Level|Chunk Size|Array Sizemdadm --examine里最有用的是设备角色例如Device Role : Active device 0这就是原始盘序。Chunk Size对应条带大小它决定 EnCase 4.20 里填的 chunk 参数。没有元数据时可以尝试 32K、64K、128K 这几档常见值在卷起始位置能否找到文件系统签名作为判断标准。4.2.1 硬件 RAID 卡没有元数据可用时服务器硬件 RAID 卡在创建阵列后盘上不一定保留各盘的独立签名这时需要先读取控制器状态。常见做法是进入 RAID 配置界面记录磁盘槽位和逻辑盘映射再把整阵列的逻辑卷作为单个磁盘取证。对 EnCase 4.20 而言只要逻辑卷能被 Windows 识别为块设备就可以按普通磁盘流程获取镜像。厂商管理工具例如常见的storcli用于导出控制器日志# 显示控制器基本信息和磁盘组配置 storcli /c0 show | grep -E Interface|Data Capacity|DG # 显示虚拟磁盘类型与扇区设置 storcli /c0/v0 show all | grep -E TYPE|Initialized|Sec上面命令展示控制器号和虚拟磁盘属性作用是把逻辑卷几何参数存档方便后续重建时对照。硬件 RAID 卡因为缓存策略不同失败盘上面的“最后写入时间”经常和真实事件时间有偏差报告里要注明时间来源是控制器日志。4.3 重组后的三个校验点盘序和条带大小配好后我不会马上开 File 浏览先看三个点一是逻辑卷开头的引导扇区或分区表是否具有可识别签名二是文件系统的空闲区在 EnCase 的 Hex 视图中是否连续若频繁出现空洞说明条带计算偏了三是随机打开一个大文件把文件头尾的簇号和条带大小代入确认前后逻辑块映射一致。都不行时把每块盘的起始扇区分别做 64 字节比较找出彼此偏移再回填进 RAID 参数。5. 从 EnCase 4.20 导出的 HTML 报告里批量提取文件行为5.1 报告里值得保留的证据元素EnCase 4.20 导出 RTF 或 HTML 报告会包含分区信息、文件列表、哈希、时间标签。HTML 版本适合做二次加工但报告页数一多就难翻。我一般提取四类字段文件路径、证据文件哈希、创建时间、最近写入时间。5.2 用 Python 把 HTML 报告变成 CSV依赖 BeautifulSoup 就能处理大多数导出版本from bs4 import BeautifulSoup from pathlib import Path soup BeautifulSoup( Path(report.html).read_text(encodingutf-8, errorsignore), html.parser, ) # 表头也写进 CSV避免以后列位对不上 with open(files.csv, w, encodingutf-8, newline) as f: for tr in soup.select(table tr): cells tr.find_all([td, th]) if cells: f.write(,.join(c.get_text(stripTrue) , for c in cells) \n)采用tr.find_all([td, th])是防止表头被跳过stripTrue去掉 HTML 里的换行和空格。得到 CSV 后用排序工具或 Excel 透视就能快速找同一时间段内被访问过的文件集合。注意导出的 HTML 表格列顺序与界面列顺序一致如果先改过界面显示字段再导出报告CSV 的列顺序会变脚本里不要写死索引按表头名称读取更稳。最后补充一个验证技巧比对两次报告的差异时别直接比文件列表先比Application Version和Export Date这两行环境不同会导致字段错位。每次手工操作后保留一份原始报告防止二次报告把关键时间覆盖。本文还有配套的精品资源点击获取