字节顺序 java/.net
当通过套接字从java应用程序向C#应用程序发送信息时，字节顺序是否不同？或者我可以将一个整数从 C# 发送到 java 应用程序并将其作为整数读取吗？
（操作系统重要吗？或者无论实际操作系统如何处理它，对于 java/.net 来说都是一样的吗？）
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这一切都取决于您如何编码数据。如果您将其仅视为原始字节序列，则不会发生冲突；顺序是一样的。当将数据块解释为（例如）整数时，问题在于字节序。
任何在编写时考虑到可移植性的序列化程序都将具有定义的字节序 - 例如，在协议缓冲区（适用于 Java 和 C#）中，无论如何，始终使用小字节序 您的本地硬件。
如果您正在手动写入流，那么使用基于移位的编码（而不是直接内存复制）之类的东西将为您提供定义的字节序。
如果您使用预先固定的平台序列化器，那么您将受到实现的支配。它可能是字节序安全的，也可能不是（即它可能取决于两端的平台）。例如，.NET
BitConverter类不安全 - 通常认为（错误地）它是小端字节序，但在某些平台上（特别是在某些平台上的 Mono 中）硬件）它可以是大端字节序；因此.IsLittleEndian属性。我的建议是使用一个序列化器来为你处理这一切；p
It all comes down to how you encode the data. If you are treating it only as a raw sequence of bytes, there is no conflict; the sequence is the same. When the matters is in endianness when interpreting chunks of the data as (for example) integers.
Any serializer written with portability in mind will have defined endianness - for example, in protocol buffers (available for both Java and C#) little-endian is always used regardless of your local hardware.
If you are doing manual writing to the stream, using things like shift-based encoding (rather than direct memory copying) will give you defined endianness.
If you use pre-canned platform serializers, you are at the mercy of the implementation. It might be endian-safe, it might not be (i.e. it might depend on the platform at both ends). For example, the .NET
BitConverterclass is not safe - it is usually assumed (incorrectly) to be little-endian, but on some platforms (and particularly in Mono on some hardware) it could be big-endian; hence the.IsLittleEndianproperty.My advice would be to use a serializer that handles it all for you ;p
在 Java 中，您可以使用
DataInputStream或DataOutputStream首先读取和写入高字节，如文档所述：http://download.oracle.com/javase/6/docs/api/java/io/DataOutputStream.html#writeInt%28int%29
您应该检查相应的 C# 文档以了解什么确实如此（或者也许这里有人可以告诉你）。
在 Java 中，您还可以选择使用 ByteByffer ：
http://download.oracle.com/javase/6/docs/api/java/nio/ByteBuffer.html
...其中有“order”方法，允许您指定读取多字节基元类型的操作的字节顺序。
In Java, you can use a
DataInputStreamorDataOutputStreamwhich read and write the high-byte first, as documented:http://download.oracle.com/javase/6/docs/api/java/io/DataOutputStream.html#writeInt%28int%29
You should check corresponding C# documentation to see what it does (or maybe someone here can tell you).
You also have, in Java, the option of using
ByteByffer:http://download.oracle.com/javase/6/docs/api/java/nio/ByteBuffer.html
... which has the "order" method to allow you to specify a byte order for operations reading multi-byte primitive types.
Java 对某些库（例如 DataInput/OutputStream）使用 Big Endian。 IP协议都使用Big Endian，这可能导致人们使用Big Endian作为网络协议的默认值。
然而，NIO、ByteBuffer 允许您指定 BigEndian、LittleEndian 或 NativeEndian（无论系统默认使用什么）
x86 系统倾向于使用 Little Endian，因此许多 Microsoft/Linux 应用程序默认使用 Little Endian，但可以支持 Big-Endian。
Java uses Big Endian for some libraries like DataInput/OutputStream. IP protocols all use Big Endian which can lead people to use Big Endian as default for network protocols.
However NIO, ByteBuffer allows you to specify BigEndian, LittleEndian or NativeEndian (whatever the system uses by default)
x86 systems tend to use little endian and so many Microsoft/Linux applications use little endian by default but can support big-endian.
是的，字节顺序可能不同。 C#
假设little-endian可能使用平台的字节顺序，Java倾向于使用big-endian。之前已经在 SO 上讨论过这个问题。例如，请参阅 C# 小端序还是大端序？Yes, the byte order may be different. C#
assumes little-endianmay use the platform's byte ordering, Java tends to use big-endian. This has been discussed before on SO. See for example C# little endian or big endian?