CSV 文件里可以正确地保存 00123，但电子表格打开后却显示 123。文件存储的是文本字段，如何解释它们由导入的应用程序决定。请在导入时就把标识符保留为文本，并在替换原文件之前检查保存后的输出。
标识符不一定是数字
数量、价格这类内容适合做算术运算。邮政编码、目录编号或账户标识符则应按其含义来处理：它们的数字只是标签，不是可以相加的数量。前导零、长数字串和类似日期的代码，都可能因为不必要的转换而被破坏。
Microsoft 关于前导零和大数字的指南说明了如何将合适的列按文本导入，也记录了受支持的 Excel 版本中的自动转换控制选项。请核对你实际使用的版本，并非每个版本都提供相同的设置。
一个原创的虚构 CSV 示例
这些是为学习而虚构的记录，不是真实的账户或客户数据。下载示例 CSV。
item_id,reference,label,quantity
00123,12345678901234567890,JAN1,7
00007,98765432109876543210,1E10,12
| 列 | 预期含义 | 导入类型 |
|---|---|---|
| item_id | 一个五位字符的标识符 | 文本；保留 00123 和 00007 |
| reference | 一个很长的引用字符串 | 文本；保留每一位数字 |
| label | 一个代码，不是日期或指数 | 文本；按字面保留 JAN1 和 1E10 |
| quantity | 一个计数 | 整数，验证之后再使用 |
CSV 并不携带这张列类型表，也没有被普遍强制执行的模式。把它写进你的交接说明，可以避免另一个应用程序做出不同的猜测。
在 Excel 中有意识地导入
- 保留一份未改动的 CSV 源文件副本。
- 使用应用程序的文本/CSV 导入流程，而不是依赖双击打开时的自动猜测。
- 查看预览，并在应用转换之前把类似标识符的列设为文本。在查询流程中，请按需检查或替换任何自动更改类型的步骤。
- 检查分隔符、编码以及对类似日期的值的处理方式。
- 加载数据，并把确切的标识符与源文件对比。
- 导出之后，用文本编辑器检查生成的 CSV，并再次按预期的列类型导入。
Microsoft 的文本文件导入/导出说明描述了“打开”和“导入”的区别。菜单名称因平台和版本而异。像五个零这样的自定义显示格式，可以让 123 显示为 00123，但这和保留原始的文本标识符并不相同，也无法恢复已经丢失的数字。
用 Python 检查字符串
Python csv 文档说明，字段默认以字符串读取，只有特定的转换选项属于例外。下面这个小检查只使用标准库：
import csv
with open("identifier-example.csv", newline="", encoding="utf-8") as f:
rows = list(csv.DictReader(f))
assert rows[0]["item_id"] == "00123"
assert rows[0]["reference"] == "12345678901234567890"
assert rows[1]["label"] == "1E10"
quantities = [int(row["quantity"]) for row in rows]
assert sum(quantities) == 19
这些检查有意只转换 quantity 列。它们只演示示例文件的内容，不能保证任意导出文件或电子表格应用程序也是如此。
哪些内容无法自动恢复
如果一个长标识符已经被四舍五入并覆盖保存了原文件，把单元格格式改成文本也无法重建丢失的数字。请从未改动的源文件恢复。如果 123 既可能是 00123，也可能就是 123，那么给它补零属于业务规则的决定，并不能证明原始的值。
给 CSV 字段加引号，是用来保护分隔符和其他字符的语法，并不能普遍地强制电子表格把该字段当作文本。有用的交接说明应写明编码、分隔符、预期的列类型和验证规则。关于相关的文档共享问题，请参阅 Word 字体的可用性与可移植性。