1. CSV 文件基础：从定义到配方数据实战
各位同学好，我是老赵。今天咱们开始《CSV解析与配方数据校验》的第一章。说实话，CSV 这玩意儿看起来简单，但我在项目里见过太多人因为它栽跟头了。咱们先把地基打牢。
1.1 什么是 CSV？
CSV，全称 Comma-Separated Values，逗号分隔值。说白了，就是一种用纯文本存储表格数据的格式。每一行是一条记录，每个字段用逗号隔开。
举个例子，一个简单的配方数据长这样：
原料名称,用量(克),批次号,有效期
面粉,500.0,B20240101,2024-12-31
糖,200.0,B20240102,2024-11-30
盐,10.0,B20240103,2025-01-15嗯，第一行是表头，后面是数据行。就这么简单。我最早接触 CSV 是在做食品行业 MES 系统的时候，工厂老师傅递给我一个 Excel 文件，说「小赵，把这个转成机器能读的格式」。我一看，其实就是 CSV。
1.2 CSV 的结构与 MIME 类型
咱们拆开来看 CSV 的结构。其实就三个核心要素：
- 记录（Record）：文件中的每一行，代表一条完整的数据。
- 字段（Field）：行内被分隔符隔开的每一段，代表一个数据属性。
- 分隔符（Delimiter）：默认是逗号，但也可以是制表符（TSV）、分号（欧洲常用）等。
关于 MIME 类型，这个在 Web 开发中比较重要。CSV 的标准 MIME 类型是 text/csv。我记得有一次给客户做 API 对接，对方返回的 CSV 用了 application/octet-stream，结果浏览器直接下载了，没法预览。后来我让他们改成 text/csv; charset=utf-8，问题就解决了。
| 属性 | 说明 | 常见值 |
|---|---|---|
| MIME 类型 | 标准互联网媒体类型 | text/csv |
| 字符编码 | 推荐 UTF-8，避免乱码 | charset=utf-8 |
| 分隔符 | 字段之间的分隔符号 | 逗号、制表符、分号 |
| 换行符 | 记录之间的分隔 | CRLF (Windows) 或 LF (Unix) |
"北京市,朝阳区"。这个坑，几乎每个做 CSV 解析的人都踩过。
1.3 CSV 的优缺点
任何技术都有两面性。CSV 的优点和缺点，我列个表给大家看：
| 优点 | 缺点 |
|---|---|
| 纯文本，人类可读 | 不支持数据类型（全是字符串） |
| 几乎所有工具都支持 | 没有标准编码规范 |
| 文件体积小，传输快 | 不支持嵌套结构（如 JSON 的数组） |
| 易于生成和解析 | 大文件解析性能差（需逐行处理） |
| 适合批量数据交换 | 字段内换行处理麻烦 |
你想想看，为什么工业界还在大量使用 CSV？说白了，就是因为它「够用」。配方数据、物料清单、生产记录，这些结构化数据用 CSV 表达，既简单又通用。我做过一个项目，客户要求每天从 ERP 系统导出 10 万条配方数据，用 CSV 格式，压缩后不到 5MB，邮件就能发。
1.4 常见应用场景：配方数据
咱们这门课的核心是配方数据校验。那配方数据长什么样？我给大家画个图：
配方数据有几个特点：
- 字段固定：原料名称、用量、批次号、有效期，这些是标配。
- 数值校验严格：用量不能为负，有效期不能是过去日期。
- 批量导入：一次可能导入上千条配方，逐条校验是刚需。
实战经验：我在做烘焙行业的配方管理系统时，客户要求 CSV 导入后自动校验「面粉+水+酵母」的比例是否在合理范围内。如果比例不对，直接拒绝整批导入。这种业务逻辑，用 CSV 解析加自定义校验规则就能搞定。
1.5 本章小结
咱们这一章把 CSV 的底子打好了。你知道了 CSV 是什么、结构怎么组织、优缺点在哪，也看到了配方数据这个典型场景。嗯，这些知识看起来基础，但后面所有解析和校验的代码，都是建立在这个基础之上的。
记住一句话：CSV 是工业界数据交换的「通用语言」。搞懂了它，你就能跟各种系统打交道。