GPX 文件说到底是不是 XML 文件？

先说结论

用普通文本编辑器打开一个 .gpx 文件，第一行通常是 XML 声明，紧接着是一个 <gpx> 标签把后面的内容整个包起来——和任何其他 XML 文档一样，都是标签嵌套加属性这套写法。GPX 更准确地说是一份「模式（schema）」：一套公开的规则，规定 <gpx> 这个元素里面能放哪些标签、一个轨迹点长什么样、时间戳和海拔该放在哪儿。底层的文件格式从头到尾都是普通 XML，GPX 只是叠在它上面的一套词汇。

也就是说，.gpx 这个后缀是标签，不是原料。它的作用是在程序打开文件之前先告诉它该期待什么，但没有往里面的字节添加任何东西；后缀丢了或者写错了，里面的内容也不会因此少掉什么。

真正让一个文件算作「GPX 文件」的是什么

解析文件的程序不管文件叫什么名字，它看的是结构：有没有一个带 version 和 creator 属性的 <gpx> 根元素，里面嵌着 <trk>、<rte>、<wpt> 中的某一种或几种，装着实际的坐标。一份文件够不够格叫「GPX 文件」，靠的是它包不包含这套结构，跟磁盘上那个名字无关。一个叫 export.gpx、里面却没有 <gpx> 根元素的文件，不是「名字对但内容不对」的 GPX 文件，它就是套了个错误后缀的别的东西。

这一点值得和后缀分开来看，因为两者通常一致，但说的不是一回事。后缀是写在文件名本身里的，关于这份文件的元数据；<gpx> 这套结构，才是这份文件本身。

既然如此，后缀为什么在实际使用中还是有影响

后缀既然对内容没有任何添加，那为什么光凭它就能把一个文件挡在外面，这个疑问很合理。答案是速度。看一眼文件名几乎不花时间，程序只要看末尾那几个字符，就能立刻判断这个文件值不值得打开。真要解析整份文件、确认里面是不是有效的 GPX 结构，才是真正花力气的事，大多数上传工具都不愿意对每一个递过来的文件——包括那些明显不对路的——都花这个功夫。所以网站或 App 通常会先按后缀做一轮机械筛选，只有过了这一关的文件，内容才会被真正读进去。

这第一轮筛选，正是内容完全正确的 GPX 轨迹，却因为和内容无关的原因被挡下来的地方。文件叫 export.xml，或者叫 track.txt，还没轮到看它实际的结构，就已经在文件名这一关被先拦住了。

改后缀能解决什么、解决不了什么

因为后缀在格式本身里没有任何分量，把 .xml 改成 .gpx 不会动里面的任何一个字节——改变的只是这份文件之后能通过哪些按文件名筛选的关卡。如果下载下来的文件叫 something.xml，用文本编辑器打开，开头附近能看到 <gpx> 这个根元素，那它已经是一条 GPX 轨迹了；把它改名成 something.gpx 是安全的，而且往往正好解决了某个上传工具单纯因为名字不对而拒收的问题。

改名做不到的是，把本来不存在的 GPX 数据凭空造出来。规定一份文件是不是 GPX 的，是里面的标签，不是文件名，所以一份恰好也用 XML 语法、但用途完全不同的无关文档——一段网页订阅源、某个 App 的配置文件——就算把后缀改成 .gpx，也不会因此多出一个 <gpx> 根元素或者任何轨迹点。真正会解析内容而不是只信后缀的程序，不管文件叫什么名字，最后还是什么熟悉的东西都找不到。

为什么有的导出一开始就是 .xml

这通常和数据本身没问题，问题出在导出走的是一条通用路径。一些比较老的系统，还有一些本来就不是专门为 GPX 设计、只是用来大范围传递地理数据的流程，会走一个通用的「导出为 XML」步骤——里面写出来的确实是正确的 GPX 结构，但没有顺手把文件名也改成配套的样子。浏览器的「网页另存为」，对着它没有特别识别出是 GPX 的内容，有时也会做类似的事。不管哪种情况，实际保存下来的内容都没受影响，变得笼统的只是外面那层名字。

TrailCam 在这里扮演什么角色

TrailCam 导出一条路线时，写出来的就是带着 .gpx 后缀的 GPX 1.1 文件，不用在传给 Strava、Garmin Connect、Komoot 或者其他任何认 GPX 轨迹的地方之前先改名。GPX 导出是可选的 TrailCam Pro 里的功能，App 本身免费下载。