如何阅读.NET的Guid成Java的UUID [英] How to read a .NET Guid into a Java UUID

问题描述

我要传达的.NET生成一个Java应用程序，一个GUID。我用 Guid.ToByteArray（）将其在磁盘上存储为字节[] ，然后读入Java和其转换为UUID。为此，我复制UUID的（私人）构造函数接受一个字节[] 的实施：

I need to communicate a Guid that was generated in .NET to a Java application. I use Guid.ToByteArray() to store it on disk as a byte[], then read it into Java and convert it to a UUID. For this purpose I copied the implementation of the (private) constructor of UUID that takes a byte[]:

private UUID(byte[] data) {
    long msb = 0;
    long lsb = 0;
    assert data.length == 16;
    for (int i=0; i<8; i++)
        msb = (msb << 8) | (data[i] & 0xff);
    for (int i=8; i<16; i++)
        lsb = (lsb << 8) | (data[i] & 0xff);
    this.mostSigBits = msb;
    this.leastSigBits = lsb;
}

然而，当我检查使用的toString（），Java的UUID是从.NET的Guid不同的UUID

However, when I inspect the UUID using toString(), the Java UUID is different from the .NET Guid.

例如，在.NET的Guid

For example, the .NET Guid

888794c2-65ce-4de1-aa15-75a11342bc63

变成了Java UUID

turns into the Java UUID

c2948788-ce65-e14d-aa15-75a11342bc63

如此看来，前三个组的字节顺序反向，而在最后两个基团的顺序是相同的。

It seems that the byte ordering of the first three groups is reversed, while the ordering in the last two groups is the same.

由于我期望的toString（）这两个GUID和UUID产生相同的结果，没有人知道我应该如何正确地读取.NET的Guid成一个Java UUID？

Since I would expect the toString() of both the Guid and the UUID to yield the same result, does anyone know how I should correctly read the .NET Guid into a Java UUID?

编辑：：要澄清，实施不是我自己的。它是取 java.util.UUI D类的私有构造一个字节[] ，这是我抄用于读取一个byte []从磁盘到UUID的目的。

To clarify, the implementation is not my own. It is the private constructor of the java.util.UUID class that takes a byte[], which I copied to use for the purpose of reading a byte[] from disk into a UUID.

我不希望使用字符串存储的GUID为我存储了很多人，这似乎是一个浪费空间。

I do not want to use strings to store the Guids as I'm storing a lot of them and it seems like a waste of space.

罗素Troywest的环节，至少澄清为什么第一对夫妇的GUID组问世逆转，而下半场停留在相同的顺序。现在的问题是，我可以依靠.NET的总是以相同的顺序生成这些字节？

Russell Troywest's link at least clarifies why the first couple of groups of the Guid come out reversed, while the second half stays in the same order. The question is, can I depend on .NET always generating these bytes in the same order?

推荐答案

在回答您的编辑，不，你不能一直依赖于相同的顺序生成的字节数。运行时决定字节顺序。 C＃也不过报价 BitConverter.isLittleEndian 出于这个原因。

In response to your edit, no, you cannot consistently depend on the bytes being generated in the same order. The runtime determines the endianness. C# does however offer BitConverter.isLittleEndian for this very reason.

我知道你不能改变Java实现的位转移的字节序。但是你可以储存后，并将它们发送到Java转向之前在C＃端位。

I know you can't change the endianness of the Java implementation and the bit shifting. But you can shift the bits on the C# end after storing and before sending them to Java.

更新：

MSDN文章上IsLittleEndian

编辑： 要实用，你也许可以指望它总是被小尾数字节的第一块它的布局，但在技术上你不能。

To be practical, you can PROBABLY count on it always being little endian in its layout of the first chunk of bytes, but technically you can't.

这篇关于如何阅读.NET的Guid成Java的UUID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！