与输入文件相比，BinaryReader.ReadInt32 结果意外，为什么？
我对特定的 BinaryReader 操作感到困惑。
使用十六进制编辑器 (UltraEdit) 查看二进制文件时，前四个字节为：52 62 38 11。
当使用 BinaryReader 迭代同一文件时，如果我首先调用 ReadInt32()，我预计 int 值为 1,382,168,593。
.ReadInt32()：从当前流中读取一个 4 字节有符号整数，并将流的当前位置前进 4 个字节。
相反，我得到的是 288,907,858。
显然我错过了一些明显的事情......任何人都可以解释发生了什么事吗？
I am puzzled with a particular BinaryReader operation.
When viewing a binary file with a hex editor (UltraEdit), the first four bytes are: 52 62 38 11.
When iterating over the same file with a BinaryReader, if I call ReadInt32() first, I would expect the int value to be 1,382,168,593.
.ReadInt32(): Reads a 4-byte signed integer from the current stream and advances the current position of the stream by four bytes.
Instead, I get 288,907,858.
Clearly I am missing something obvious... can anyone explain what is going on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
BinaryReader以小端顺序读取字节。观察：
如果您需要指定正在读取的数据的字节顺序，我建议使用 Mono.DataConvert< /a>.我已经在几个项目中使用过它，它非常有用，并且获得了麻省理工学院的许可。 （出于性能原因，它确实使用不安全的代码，因此您不能在不受信任的上下文中使用它。）
请参阅维基百科有关字节顺序的文章，了解有关该概念的更多信息。
有关 BinaryReader 实现的详细信息，请参阅 Microsoft 参考源
BinaryReaderreads bytes in little-endian order.Observe:
If you need to specify the byte ordering of the data you are reading, I would suggest using Mono.DataConvert. I've used it in several projects and it is incredibly useful, as well as MIT-licensed. (It does use unsafe code for performance reasons, so you can't use it in untrusted contexts.)
See the Wikipedia article on endianness for more info on the concept.
See Microsoft's Reference Source for details on the implementation of BinaryReader
英特尔架构是小端。序列中的最后一个字节具有最高值。所以 52 62 38 11 相当于 0x11386252。
Intel architecture is little endian. The last byte in the sequence has the highest value. So 52 62 38 11 is equivalent to 0x11386252.