混合二进制文件的字节序是否有性能理由？
我正在为最常见的地理数据存储类型（称为“shapefile”的文件集合）编写一个解析器。这是我的第一个项目，我必须考虑字节顺序。
原来几何存储是混合字节序的；文件的某些部分是大尾数，但大部分是小尾数。 此处描述了 shapefile 标准。
是否存在明显的绩效理由，或者只是出于历史背景？如果是这样，您知道那个历史背景是什么吗？
构成数据描述字段的整数和双精度整数 主文件中的文件头（如下所示）和记录内容采用小端（PC 或 Intel®）字节顺序。构成文件和文件管理其余部分的整数和双精度浮点数采用大端字节序（Sun® 或 Motorola®）字节 订单。
I'm writing a parser for the most common geographic data storage type, a collection of files called a "shapefile". This is my first project where I've had to think about endianness.
It turns out that the geometry storage is mixed endian; some parts of the file are big endian, but most of it is little endian. The shapefile standard is described here.
Is there a discernible performance rationale, or was it simply born out of historical context? If so, do you happen to know what that historical context is?
The integers and double-precision integers that make up the data description fields in the
file header (identified below) and record contents in the main file are in little endian (PC or Intel®) byte order. The integers and double-precision floating point numbers that make up the rest of the file and file management are in big endian (Sun® or Motorola®) byte
order.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
虽然似乎没有明确的答案，但我看到的是“尝试创建一种适用于所有平台的格式时的混乱”和“当时设计了许多设计不佳的格式”的混合体。更多信息请参见：https://gis.stackexchange.com/questions/18969/奇怪的形状文件技术规范
While there doesn't seem to be a clear answer for it, what I've seen is a mixture of "confusion while trying to create a format that works on all platforms" and "a lot of poorly designed formats were designed back then". More info here: https://gis.stackexchange.com/questions/18969/oddities-in-the-shapefile-technical-specification