Shapefile技术规范中的“奇数”

我一直在编写shapefile解析库，并且在规范中遇到了一些我尚未立即理解的设计决策。我希望周围有一个老谋深算的ESRI开发人员，他可以告诉我为什么这些事情都是如此。

1. 主记录文件（.shp）具有混合字节序。具体来说，标头的某些部分具有大尾数字节顺序，但是记录都是小尾数。我通常在比字节和位更高的级别上工作，但是到目前为止，我所读到的有关字节序的所有内容都将其标记为异常。为什么未将文件指定为统一字节序？

2. “文件长度”字段以及其他长度和位置字段以16位字记录，而不是更标准的（从我的角度来看）8位定位。如何做出此决定？

我在Stack Overflow上发布了类似的问题，但没有得到任何回应。如果这对其他人来说似乎太离题了，我可以支持关闭它。

shapefile的开发与ArcView的开发同时进行，后者专门设计为独立于平台。（实际上，这是它的败笔：依靠在独立于平台的GUI中开发的称为“ Neuron Data”的界面，它无法利用许多Windows功能。最终反映出所有系统中最糟糕的功能尽管shapefile规范从一开始就很奇怪，但是在此设计框架内却显得有些loop回：因为shapefile是针对许多平台设计的，所以它们的规范不应偏向任何一个平台，因此同样令人讨厌给所有劝说的程序员。

第二个问题似乎是基于一个不正确的假设。例如，“文件长度”字段出现在主标头中的字节偏移量24处，并且是一个（有符号的）四字节（32位）整数，因为它必须表示最大2 ^ 31- 1。它前面有一个四字节的“文件代码”，还有五个供以后使用的四字节字段：当您保留这样的空间时，您当然想使这些字段尽可能地大，这在当时为32位，以保持最大的灵活性。在字边界上对齐文件中的数字字段也有帮助：

外面的人知道这些答案，甚至更多，但他们没有说话。

我一直在与未记录的sbn和sbx文件进行解码的团队发现了更多相似且同时更加奇怪的奇怪现象。

大多数shapefile结构是合乎逻辑的且非常高效，这表明ESRI开发人员会仔细考虑。就像他们有一群精明的开发人员，他们陷入了一个疯子。

正如其他帖子所建议的那样，奇怪的原因可能是我们现在对机器或语言要求不熟悉的结果。

我一直怀疑16位字是节省空间的简便方法。您会发现在处理文件时必须将16位字值保留在内存中。即使在今天，以二进制格式计算值以节省空间的策略也很普遍。但是Mike的本地int建议也有可能。

字节序翻转很奇怪。我没有看到一个很好的答案。

dbf格式是从1960年代的dbase III格式中删除的。从那时起，它已被广泛使用，并且可以以其他名称（包括foxpro和xbase）找到。

尽管shapefile格式存在缺陷，奇怪之处和局限性，但它在GIS领域及其周围仍然顽固地存在。进行其他任何替换尝试都过于简单，无法进行简单的矢量存储或过于专有。甚至ESRI都认为shapefile会成为一种玩具，它将使初学者转向ArcINFO，coverage和地理数据库。互联网可能与格式的腾飞有关。

我学到了很多写pyshp的知识。编写解析器是一种学习格式的绝妙方法。

这是我的看法。

Shapefile格式很可能是从ARC / INFO演变而来的，其历史可以追溯到FORTRAN / PR1ME的起源。所有ARC / INFO格式都具有此100字节的标头，并且文件代码和文件长度（例如Coverage，TIN）的字节序很大。

当为ArcView 1制作Shapefile时，ESRI专注于打入Microsoft Windows市场，而Shapefile格式的其余部分则主要专注于PC的低端存储。

端端性之间的不断切换，大概是需要支持传统起源，同时预期进入该平台会带来好处。

我一直认为，字节序分配是由两个团队组成的，一个团队在Sun Workstations上，另一个团队在PC上，直到开发过程快结束时他们才见面。

我很想知道真正发生了什么。

我认为在后面的某个地方，我听到了有关dbf / foxpro起源的一些信息。
不过，那可能只是我一个奇怪的梦。

您必须了解shapefile是20年前引入的，当时有无数种不一致且设计不良的文件格式，因此shapefile也不例外。我自己编写了一个shapefile解析器，不得不说，与shapefile（.SHP）本身相比，在解析DBF格式时遇到了更多的问题。