导出的 GPS 轨迹 CSV 文件，为什么在 Excel 里打开会显得不对劲

简单说

通常会出两种不同的问题，原因也不一样。要么整个文件完全没被拆开，全挤进了一列；要么列是拆对了，但坐标显示成一个被截短、看着像四舍五入过的数字，而不是导出时的那个原始值。第一种，是 CSV 用来分隔数值的字符，跟 Excel 认定的分隔符对不上。第二种，是 Excel 那套通用的数字显示格式对着长小数一贯的做法，跟这个数字是不是 GPS 坐标没关系。不管哪一种，都不代表底层数据本身有问题。

为什么整份文件有时会挤成一列

CSV 全称是"逗号分隔值"，大多数导出文件也确实用逗号来标记一个字段到下一个字段的分界。可是 Excel 直接打开文件的时候，未必把逗号当成这个分界符。它期望哪个字符当分隔符，是由 Excel 的地区格式设置决定的——而在美国以外的不少地区，这个字符是分号，不是逗号，因为逗号在那些地区已经被用作小数点了，没法再兼职当列分隔符。在这种设置下打开一份用逗号分隔的文件，Excel 会老老实实去找分号，一个都找不到，于是认定整行就是一个字段。结果就是，导出文件里所有的列都挤进了 A 列，逗号还留在原地，只是没被拆开。

这跟 GPS 数据没什么特别关系。在把逗号当小数点的系统上，任何逗号分隔的文件都会这样——一份姓名和价格的表格，跟一份坐标和时间戳的表格，遇到的问题一模一样。

为什么坐标看起来像是被截短或四舍五入了

就算列拆对了，坐标看起来也可能比导出时短。以不指定格式的普通数字打开，Excel 会套用它默认的"常规"格式，这个格式会根据列宽和它自己对显示位数的上限来调整。一个带好几位小数的经纬度，可能因为单元格更在意"数字看着整齐"，被视觉上截掉一截，或者显示的位数比文件里实际保存的要少。把列拉宽，或者把单元格格式改成文本，就能还原完整的值——底层的数字从来没变过，变的只是 Excel 选择显示几位而已。

这个显示上的缩短，跟上面说的挤成一列是两个不同的问题，但经常被互相当成对方的锅。把列拆对了，不会自动修好坐标的显示；把显示修好了，也解决不了一开始就没拆开的列。

怎么把坐标文件导进来，同时避开这两个问题

同时避开这两个问题最靠谱的办法，是走"导入"这条路，而不是直接双击打开文件——导入能让你明确告诉 Excel 该怎么读，而不是让它自己猜。用"从文本/CSV 导入数据"这类功能，可以不管地区默认设置，直接把分隔符指定成逗号，也可以把坐标所在的列指定成"文本"而不是"常规"，这样在导入过程中就不会被重新格式化、四舍五入或者按别的方式解读。文本列会原样显示文件里的每一个字符，对坐标这种"位数准确比看着整齐更重要"的值来说，这是最保险的设置。

如果导入不方便，针对挤成一列这个问题，还有个更快的土办法：先用纯文本编辑器打开文件，把所有作为分隔符的逗号换成分号，再拿到用逗号当小数点的系统上的 Excel 里打开。不过这只在数值本身不含逗号的前提下管用，而且对显示被四舍五入这个问题完全没用。

容易搞错的地方

• 看到整份文件挤成一列，就以为导出本身坏了——绝大多数情况下，这只是 Excel 的地区设置导致分隔符对不上，跟文件有没有损坏没关系。
• 文本编辑器打开明明好好的，却怀疑是数据本身有问题，动手改了再存一遍——文本编辑器对分隔符和数字格式完全没有自己的假设，正因为这样，它才能原样正确显示文件。
• 看到单元格里是个整整齐齐的普通数字，就直接拿来用——这种"整齐"很可能正是常规格式悄悄处理过的结果，用之前值得在编辑栏里核对一下单元格实际存的内容。
• 修好了列的拆分，就以为看着被四舍五入的数字也一并修好了——这两个问题的根源不一样，得分开处理。

TrailCam 在这里的角色

TrailCam 可以在开通 TrailCam Pro 后把一条轨迹导出成 CSV，也可以导出成 GPX 1.1，用来传到任何能读取 GPX 的地方。这两种导出都不会因为最终由谁打开而改变自己的样子——文件在一个程序里打开得好好的，在另一个程序里却拆得乱七八糟或者数字被四舍五入，原因在于打开它的那个程序自己的地区设置和数字显示方式，而不在文件本身。TrailCam 免费下载。