多线程爬虫生成的文件合并后行数少1行的原因是什么?
问题根因分析与修复方案
- 末尾无换行符的行拼接问题(概率最高)
绝大多数单条行数缺失的场景都来自该问题:如果某一个分片文件的最后一行末尾没有携带\n换行符,合并时下一个文件的第一行内容会直接拼接在该行末尾,原本的2行将被合并为1行,最终总计数少1。
你之前的行数校验逻辑大概率是用len(list(open(fname)))这类方式统计,这类统计逻辑无论文件末尾是否有换行,都会把最后没有换行的内容计入为1行,不会提前发现问题。
验证方法:执行以下代码查看所有分片文件的末尾字节,确认是否存在无\n的情况:for fname in filenames: tail = open(fname, 'rb').read()[-1:] if tail != b'\n': print(f"{fname} 末尾无换行符") - 文本解码异常导致行丢失
你合并时用的是UTF-8文本模式读取文件,如果分片文件中存在非法UTF-8字节序列,且你的运行环境修改了默认的解码错误处理策略为ignore,异常字节所在的行可能被截断或直接跳过,不会抛出报错。 - 异常换行符导致的计数偏差
若分片文件中存在单独\r作为换行符的场景,Windows文本模式下的换行转换逻辑可能导致行计数和实际写入的换行不匹配,最终出现行数偏差。
修复方案
临时修复合并逻辑
可以在合并时主动补全每个分片文件末尾缺失的换行,避免行拼接:
with open(r"data\run12.txt", "w", encoding="utf-8") as outfile: for fname in filenames: with open(fname, "r", encoding="utf-8") as infile: content = infile.read() # 确保每个文件内容末尾带换行再写入 outfile.write(content.rstrip('\n') + '\n')
根本修复
在多线程写入分片文件的逻辑中,强制所有行末尾携带\n,包括每个文件的最后一行,从源头避免无换行的问题。
内容的提问来源于stack exchange,提问作者metzkorn
相关产品推荐
相关产品推荐

