先给结论:不要试图把打不开的导出文件“修好”再读。更稳妥的做法是把它当成一份原始凭证,先固定它的字节和来源信息,再从文件外部重建字段字典,最后用一份可读的映射表把原始列名、取值和当时的含义对应起来。只要字段含义保存在独立文档里,文件本身能否被当前软件打开就不再是关键。
旧导出打不开,通常有三种互不相同的表现,对应的处理方向也不一样。
rank、reach、pageviews 已经没人说得清当时采集的是哪一项。这类问题最容易被误判成“文件坏了”。判断方法很简单:先用十六进制查看器或文本编辑器打开文件头部,看是否还有可读的列名。如果列名可读,问题多半只在读取工具;如果列名已乱码,含义必须从外部重建。这一步的结果直接决定下一步是找解析器,还是直接进入字段字典重建。
在动手转换之前,先做三件不可逆之前该做的事。
sha256sum export.csv 得到一串摘要。它的作用是:以后任何一次转换、清洗或转存,都能证明是否动过原始字节。做完这三步,你手里就有了一份可核对的底本。后续任何字段解释如果与底本冲突,以底本为准。这是把“打不开的文件”转成“可执行处理方案”的起点。
字段含义不能靠猜,要靠可核对的旁证。按可靠性从高到低排列,大致是:
重建时建议做一张三列映射表:原始列名 / 当时含义 / 证据来源。第三列必须写清楚依据是哪份文档、哪次导出或哪条数值特征。没有证据来源的字段,宁可留空并标注“待核实”,也不要写一个看起来合理的解释。
一个常见的反常现象是:某列在旧导出里全是 0,于是有人推断“这个字段当时就已经废弃”。这个推断并不成立。数值全为 0 至少还有几种合理解释:采集时段内确实没有数据;该字段在导出环节被默认置零;导出任务本身只覆盖了部分维度。要区分这些解释,需要看同一份文件里其他列是否正常、同一时期其他导出是否也全零。如果只有这一列异常,更可能是采集或导出环节的问题,而不是字段定义变了。
同理,某个旧指标在某次查询中返回空值,也不能单独证明该指标已被取消。空值可能来自查询条件、权限变化或接口返回格式调整。把“现象”和“结论”分开记录,是避免误判的关键。
假设你手里有一份 2012 年前后从某个网站分析后台导出的 CSV,当前表格软件打开后列名显示为乱码,但数值仍可辨认。可以这样处理:
iconv -f GBK -t UTF-8 old.csv > old_utf8.csv,把结果另存为新文件,不动原件。export_2012_raw.csv 与 export_2012_fields.md。这个流程的结果是:即使以后再也找不到能打开原文件的软件,你仍然知道每一列当时代表什么。下一步无论是做历史对比还是写核查说明,都有据可依。
把字段含义从文件里解放出来,存进独立的映射表,是这类旧导出唯一可靠的长期保存方式。文件可以打不开,含义不能丢。