STDF转CSV实操指南：从二进制数据解析到良率分析

简介：一套面向半导体测试数据处理的本地化解析工具，可解决ATE测试机生成的STDF二进制文件难以直接分析的问题。工具支持二十五种记录类型的全量解析并转换为通用CSV格式，适用于封测厂、芯片设计公司及测试工程师进行良率分析、失效统计与数据看板建设。压缩包共四个文件，包含主程序、配置文件、英文说明文档，以及一个可直接运行的示例样本，整体大小约七点零一兆字节，体积紧凑。实际解析速度可达每秒十七兆至三十三兆，即便处理百兆以上的大型文件也较为高效；使用时仅需在配置文件中填写待解析文件的绝对路径，双击运行后即可在对应文件夹中查看拆分好的结果，方便后续用表格软件或数据库做二次分析。随包还附带测试数据，方便用户未修改配置前直接体验效果。目前已有四千三百六十四人学习下载，适合需要离线批量转换STDF数据、追求轻量级工具的工程技术人员。 STDF文件这名字，干半导体测试的朋友肯定不陌生，但很多刚入行的工程师或者数据分析岗的同事，第一次见到它往往是一脸懵：几GB的二进制文件、没有直观的表格结构、用记事本打开全是乱码。可良率分析、异常批次追溯、测试项分布统计，全都得从这里面挖数据。我这两年经手过的STDF文件没有一万也有八千，最常干的一件事就是把STDF解析成CSV，再丢进Python或者Excel里做进一步处理。这篇文章就把我沉淀下来的"STDF转CSV"实操路线完整讲一遍，从文件格式原理、解析方案选型，到具体代码实现和踩坑记录，一次说清楚，给需要处理这类数据的同学一条能直接落地的路。

这套内容适合谁？如果你是半导体测试工程师、良率分析工程师、设备工程师，或者做测试数据平台开发的程序员，手上正堆着一批STDF不知道从哪下手，那这篇文章就是给你写的。即使是刚接触测试数据的新人，只要你懂一点Python基础，跟着实操部分走一遍，也能独立完成解析任务。

1. 为什么非要把STDF解析成CSV

1.1 STDF不是Excel，它是一堆二进制记录

STDF全称Standard Test Data Format，是半导体测试行业的标准数据格式，由Teradyne在1991年提出，后来被GenRad、Advantest等主流测试机厂商广泛采用。它本质上是按固定结构组织的二进制流，不是给人直接看的格式。文件里记录的是完整测试过程的数据，包括批次信息、晶圆编号、芯片坐标、每个测试项的测量值、判断结果、良率统计等。

STDF的数据是分"记录"存储的，每条记录有类型、子类型、长度和数据区，一条接一条顺序写入。这种设计对测试机写入友好，但对事后分析极不友好——人类不借助工具很难直接从里面提取出“某一颗芯片的某几个测试项结果”。这就是需要解析的根本原因：把二进制记录还原成行列清晰的表格。

1.2 CSV才是数据分析的“通用语”

把STDF转换成CSV，本质上是在搭建测试机数据和数据分析工具之间的桥梁。CSV简单、通用、几乎所有工具链都支持，不管是Pandas、Excel、R、Tableau还是自研的数据平台，CSV都是最省事的输入格式。

从实际应用场景看，转成CSV之后能干的事太多了：按批次维度统计良率变化趋势、按测试项看分布直方图和CPK、按探针卡或温湿度等条件做相关性分析、用机器学习模型预测良率风险等。我见过很多团队没有STDF解析能力，只能靠测试工程师手动从测试Summary里复制数据，效率低还容易出错。搭建一条STDF转CSV的自动化管线，几乎是一劳永逸的基础设施投入。

1.3 方案选型：现成库还是自己写

做STDF转CSV，通常会面临三种路线选择，我逐个分析过它们的优劣：

我的个人建议是：如果你只需要标准的PRR、PTR数据，用开源库最省心；如果你需要对特殊记录做自定义处理，或者STDF文件里混了厂商私有扩展记录，那自己写解析器反而更灵活。下面我会重点讲自己写解析器的方案，因为理解了底层原理之后，用任何库都不再是黑盒操作。

2. 动手前，先把STDF结构吃透

2.1 文件层次：头部、记录流、尾部

STDF文件的整体结构并不复杂，本质上就是一条记录接一条记录的字节流。不同类型记录的顺序有约定，但也不是绝对固定，解析时不能假设某种记录只出现一次或一定出现在某个位置，必须动态判断类型后分发处理。

常用记录的层次关系大概是这样的：

• FAR（File Attributes Record）：文件属性记录，文件第一条记录，用来声明版本号和字节序。
• MIR（Master Information Record）：批次总体信息，包括测试程序名、批次ID、操作员、测试日期等。
• PRR（Part Results Record）：单颗芯片测试结果汇总，包括芯片坐标、良/不良判定、Hard Bin和Soft Bin。
• PTR（Pin Test Record）：单测试项测试值，包含测试项名、测量值、上限、下限、结果状态。
• MPR（Multiple Result Record）：多结果记录，用于一个测试项产生多个值的场景（比如多点测试）。
• MRR（Master Results Record）：批次结束汇总，包含良率统计、测试时间等。
• WIR/WCR/PCR等：晶圆级、测试头级、探针卡级的信息记录。

解析STDF转CSV最核心的思路，就是先扫出PRR确定每一颗芯片的存在和判定结果，收集MIR得到批次维度的元信息，再从PTR/MPR里提取所有测试项结果。测试项的数量和名称往往要到后续的PTR里才能完全确定，所以不能第一批就确定CSV的完整表头。

2.2 记录内部结构拆解

每条STDF记录有一个统一的头部结构，总共5个字节：

• 前2字节：记录剩余长度（不含这5字节头部），使用无符号16位整数
• 中间2字节：记录类型，使用两个ASCII码字符（如"PRR"对应的其实是"PR"+"R"的字符组合）
• 最后1字节：记录子类型，无符号8位整数

我举个例子，PRR记录的类型字段是字符"P"和"R"的ASCII码（0x50、0x52），子类型通常是1。拿到这5个字节之后，就能根据类型和子类型决定后续数据区的解析规则。注意STDF的记录长度字段可能跨越多条，需要按顺序读完后才能继续下一条。

2.3 字节序与变长字段是最大的坑

STDF标准使用的是大端字节序（Big Endian），也就是高字节在前，这在Intel x86平台上很容易被坑。你如果直接按本机字节序读，解析出来的数值会完全错乱。Python用struct模块时，格式串里必须显式加>前缀，比如>H表示无符号16位大端整数、>I表示无符号32位大端整数。

另外STDF里大量使用定长字符串和变长字符串。定长字符串字段的长度是固定的，不足部分用空格或NULL补齐，解析时需要strip掉尾部空白；变长字符串字段则先有一个无符号8位整数表示长度，后跟对应长度的字节。读取时务必按长度精确截取，不能擅自按固定大小读，否则后续所有字段都会错位。我在早期写解析器时，就因为在某个变长字符串上少读了一个字节，导致后面几百条记录全部解析失败，排查了大半天。

3. Python实现STDF转CSV实操

3.1 环境准备与代码结构

我这里用纯Python标准库实现，不依赖第三方库，方便在任何环境里直接跑。核心步骤分为：读记录头、分发记录类型、解析字段、组装DataFrame、写入CSV。代码组织上用一个主循环读取文件，用多个解析函数处理不同记录类型。

先定义最基础的对齐格式。STDF头部解析：

import struct def read_record_header(f): header = f.read(5) if len(header) < 5: return None rec_len, rec_type, sub_type = struct.unpack('>H2sB', header) rec_type = rec_type.decode('ascii', errors='replace') return rec_len, rec_type, sub_type

注意这里用>H2sB一次性读取，2s表示读取两个字节的原始字节串，再用decode转成字符串。这个头部是进一步解析的基础，FAR、MIR、PRR、PTR都通用。

3.2 从FAR和MIR中获取关键信息

FAR记录是文件的第一条记录，它里面有版本号和字节序信息，虽然大多数文件都是标准的，但最好还是解析一下做校验。FAR的解析规则：

• 版本号：无符号8位整数
• 字节序：无符号8位整数（1表示Vax字节序，2表示大端字节序）

遇到字节序标志不是大端时，就要考虑罕见文件，我在解析前会先检查一下。MIR记录包含批次维度信息，其中最重要的字段是批次ID（LOT_ID）、测试程序（JOB_NAME）、测试时间（SETUP_T）、操作员（OPER_NAM）。它在文件开头出现一次，后续所有PRR都属于这个批次。

3.3 核心：解析PRR和PTR拼出CSV行

PRR记录是CSV行的骨架，它记录一颗芯片的核心信息。解析PRR时，按照STDF规范，字段顺序是HEAD_NUM、SITE_NUM、PART_ID、X_COORD、Y_COORD、PART_TYP、HARD_BIN、SOFT_BIN等。我用一个简单函数解析：

def parse_prr(buf): offset = 0 fields = [] # HEAD_NUM: uint8, SITE_NUM: uint8 fields.append(struct.unpack_from('>B', buf, offset)[0]); offset += 1 fields.append(struct.unpack_from('>B', buf, offset)[0]); offset += 1 # PART_ID: variant string（长度在前） n_len = struct.unpack_from('>B', buf, offset)[0]; offset += 1 part_id = buf[offset:offset+n_len].decode('utf-8', errors='replace').strip() offset += n_len # X_COORD, Y_COORD: uint16 x_coord = struct.unpack_from('>H', buf, offset)[0]; offset += 2 y_coord = struct.unpack_from('>H', buf, offset)[0]; offset += 2 # HARD_BIN, SOFT_BIN: uint16 hard_bin = struct.unpack_from('>H', buf, offset)[0]; offset += 2 soft_bin = struct.unpack_from('>H', buf, offset)[0]; offset += 2 return { 'part_id': part_id, 'x_coord': x_coord, 'y_coord': y_coord, 'hard_bin': hard_bin, 'soft_bin': soft_bin }

PTR记录则代表单个测试项的详细数值。字段顺序里，TEST_NUM和TEST_NAM标识测试项名称，RESULT是测量结果，LO_LIMIT/HI_LIMIT是上下限，TEST_FLG表示测试状态。解析PTR时，关键的坑在于STDF规范里PTR字段有很多可选部分，必须根据TEST_FLG里的标志位判断后面是否存在高精度数值字段，这直接决定解析长度。

3.4 输出CSV：怎么组织行列最合理

STDF转CSV最常见的输出结构是：每一行代表一颗芯片，前几列是批次信息、坐标、Bin值，后面每一列对应一个测试项。我按这个思路实现完整流程：

def stdf_to_csv(stdf_path, csv_path): rows = [] # 用字典收集所有测试项名称，用于最终表头 test_names = set() current_wafer_info = {} with open(stdf_path, 'rb') as f: while True: header_info = read_record_header(f) if header_info is None: break rec_len, rec_type, sub_type = header_info data = f.read(rec_len) if rec_type == 'FAR': # 校验版本和字节序 pass elif rec_type == 'MIR': current_wafer_info = parse_mir(data) elif rec_type == 'PRR': prr = parse_prr(data) # 标记一个待完善的row对象 rows.append({ 'wafer_info': current_wafer_info, 'prr': prr, 'tests': {} }) elif rec_type == 'PTR': ptr = parse_ptr(data) # 将测试值挂到最近的PRR所对应的row if rows: rows[-1]['tests'][ptr['test_name']] = ptr['result'] test_names.add(ptr['test_name']) # 其他记录类型按需跳过

这里有一个重要细节：PTR记录并不总是紧跟在对应的PRR后面，正常流程里PTR和PRR的位置关系在逻辑上属于同一枚芯片，但不同机台的输出顺序可能有差异。更稳妥的做法是先扫一遍文件建立完整映射再输出，或者用离线过滤方式两次读取文件。对于追求效率的场景，我会用"解析时按顺序累计，遇到新的PRR时把旧的row彻底保存"的方案，绝大多数标准STDF文件都可以这样处理。

测试项名称不固定，所以CSV的列名需要在写完所有记录后统一生成。我先把每个row的tests字典补齐，再根据test_names集合确定列顺序，最后写CSV：

import csv def write_csv(rows, test_names, csv_path): sorted_tests = sorted(test_names) header = ['X_COORD', 'Y_COORD', 'HARD_BIN', 'SOFT_BIN'] + sorted_tests with open(csv_path, 'w', newline='') as f: writer = csv.writer(f) writer.writerow(header) for row in rows: prr = row['prr'] line = [prr['x_coord'], prr['y_coord'], prr['hard_bin'], prr['soft_bin']] for tn in sorted_tests: line.append(row['tests'].get(tn, '')) writer.writerow(line)

用空字符串填充缺失的测试项，避免表格参差不齐，这样CSV就可以直接进Pandas做良率分析：

import pandas as pd df = pd.read_csv(csv_path) # 按HARD_BIN统计良率 pass_rate = (df['HARD_BIN'] == 1).mean()

这一段跑下来，一个基础的STDF转CSV工具就成型了。当然现实中的文件比这个复杂，下面聊聊我实际遇到的问题。

4. 常见问题与排查技巧实录

4.1 记录字段错位导致解析失败

这是最常见的坑。症状是解析到中途报错，或者某些数值明显不合理。原因往往是某个字段的长度判断错误，尤其是变长字符串的读取长度不准确，或者跳过可选字段时判断条件写错。

排查方法：先用一个小型STDF文件，单步跟踪前几条记录，逐字节比对STDF规范。我习惯写一个调试函数，把每条记录的类型和长度打印出来，对照规范核对预期长度。一旦发现某条记录长度跟规范不符，先停到这里，重点检查前一条记录是否多读少读了字节。调试一次之后，后面几百条就能顺畅通关。

4.2 PRR与PTR的对应关系混乱

有的测试机在文件里会先连续输出多个PRR后再输出所有PTR，如果依赖"当前PTR属于当前PRR"的简单逻辑，数据就会串芯片。这个问题在FT（Final Test）多站点测试时特别常见。

我的处理思路是，不要急着在解析时合并数据，而是解析过程中先按记录类型分别存储PRR列表和PTR列表，PTR里本身包含测试项名称、站点号等信息，可以后续按站点和坐标做关联，或者等该批次所有PTR输出完后，按顺序对应。极端情况下，要利用测试项名称和坐标关系做模糊匹配，但绝大多数场景用顺序对应就够了。

4.3 大字节序陷阱

虽然STDF规范是大端，但有些老版本文件或特殊机台可能使用VAX字节序。在这种文件里，头5个字节的记录长度字段依然按大端读取，但后续数据区整体按小端解释。解析时一但发现数据明显离谱，先检查是不是字节序判断错误。

我建议在代码里增加一个解析模式参数，遇到异常数据时切换字节序重新解析。实测下来，混用了不同字节序的工厂文件并不罕见。

4.4 测试项数量巨大导致CSV膨胀

某些复杂工控、车规芯片的测试项多达数千个，如果全解析成CSV，单行就可能上万列，文件大、加载慢，Pandas读起来也吃力。针对这类场景，我通常建议两种策略：一是分块解析，只提取当前分析关心的测试项；二是转成长表格式，一行一个测试项，列包括芯片坐标、测试项名、值、上下限，后续用Pandas做数据透视表还原宽表。长表虽然不够直观，但数据库存储、条件过滤都更灵活。

5. 总结与扩展思路

5.1 解析性能优化方向

当STDF文件达数GB时，Python单线程逐条读取会比较吃力。实测下来，3GB文件纯Python解析大概需要十几分钟，主要瓶颈在逐字节解析和字符串解码。要提速，可以引入多进程按文件切块解析，或者把重复的解析循环改到Cython/C拓展里。还有一个低成本方案是用mmap把文件映射进内存，减少系统调用开销，配合数组批量读取，能让耗时下降一半以上。

5.2 从CSV到数据分析的延伸

解析出CSV只是第一步，真正价值在于后续分析。我的常规做法是把CSV导入SQLite或ClickHouse做持久化存储，再直接在数据库层面做良率统计和测试项分布分析。需要做图上监控时，用Superset或Grafana对接数据库，就能实现每日自动出良率报表。如果你的团队已经有数据平台，把STDF转CSV做成定时任务，每天自动扫描新文件并入库，就能彻底替代手工复制粘贴。

做了这么多项目之后我的体会是，STDF解析本身只是工具层面的工作，真正的难点在于对数据的理解，搞清楚每条记录代表什么、测试项之间有什么关联。我从完全不懂STDF的二进制布局，到现在能快速定位各类异常记录，中间踩了不少坑。这篇文章里写的注意事项和代码逻辑，都是我实际跑过、验证过的方案，希望能帮你少走一些弯路。

本文还有配套的精品资源，点击获取