为什么数据与算法同事总劝你先落一层 TXT 再进管道？
舆情监控要把新闻稿与公告丢进分词器、对账脚本要把回函里的账号行写进数据库、大模型要把制度条款切块做向量——这些下游系统最怕的不是「没格式」，而是「带着隐形样式与不可见字符的富文本炸弹」。大家搜「pdf 转 txt 在线」「pdf 去格式 纯文本」「utf-8 提取」「语料 清洗」「管道 输入 编码」时，应把 TXT 视为可控中间层：统一换行与编码后再做去重、哈希与敏感词扫描，比在 Word 里复制少踩一半坑。纯文本会丢失表格网格与上下标语义，若业务仍要行列关系，应并行保留结构化导出而不是逼 TXT 背锅。对多语言混排，需在管道头声明语言检测与分隔符策略，避免中日韩与拉丁语黏连。对进入公网模型或外包标注的文本，必须先脱敏与分级审批，纯文本链路并不会自动替你抹掉隐私。对大体积年报与政策汇编，还应把章节标题正则与停用页眉模板纳入清洗脚本版本库，避免半年后无人记得当年规则。
如何将 PDF 导出为 UTF-8 纯文本并接入脚本或语料流水线
- 与下游约定换行策略：段落间空一行还是单换行、是否保留行号前缀，并在工具侧选择 UTF-8 无 BOM 以避免 Unix 与 Windows 工具链互相抱怨；对超大文件先按章节截取试跑再全量。
- 抽取后在终端或编辑器用 `file` 与抽样十六进制确认无异常控制字符，再跑一遍敏感信息正则与邮箱电话命中报告，命中项回源打码或丢弃对应行。
- 将清洗后的 TXT 纳入版本库或对象存储时附带来源 PDF 哈希、页范围与清洗规则版本号，便于审计追问「这条语料从哪一页来」；禁止把含客户代号的中间文件长期留在个人下载目录。
纯文本中间层常见问答
表格在 TXT 里变成一长串数字加空格，数据同事骂「没法用」，这种期望错位该怎么在需求评审里一次性说清？
应在需求表里把「结构化表」与「段落语料」分成两条交付物，TXT 只服务后者；若必须行列，请另走表格抽取或导出 CSV。把「TXT 不承诺网格」写进数据字典第一页。
Windows 记事本与 Linux 管道对换行符理解不一致，导致 CI 里 diff 假阳性，这类工程问题该在提取侧还是仓库规范侧解决？
应在仓库统一配置 `.gitattributes` 与 `core.autocrlf` 策略，并在生成 TXT 时显式选择换行风格；不要在聊天里手改二进制混用。把换行策略链接写进 README。
想把整本制度一次性抽进向量库，但中间夹杂大量页眉水印重复句，会不会污染检索 topK、有没有低成本去重策略？
应使用 SimHash 或 MinHash 对段落去重并保留首次出现页码，再入库；对水印高频 n-gram 可建停用表。把去重阈值与保留策略登记在语料治理台账。
抽取后中文与英文单词黏在同一行没有空格，全文检索命中率暴跌，这种分词前清洗该交给谁维护一套规则？
应由 NLP 工程在分词器前增加中英边界插空格规则并版本化；业务方不应各自手写 sed。把规则仓库与回滚流程写进 MLOps checklist。
合规要求保留不可变审计副本，但 TXT 很容易被误编辑覆盖，怎么在流程上把「可改」与「不可改」分开、对象存储权限该由谁审批？
应对外分发只读对象存储路径与时间戳命名，并在权限上禁止覆盖；本地工作副本可写。把「审计副本文档不可原地保存」写进信息安全制度。