.NET和Linux之间的GUID/UUID兼容性问题 在我的C++程序中，我使用Debian Linux的UUID包生成UUID值，它返回了一个大小为16的无符号字符数组，它是UuIDyt类型。然后我将其转换为字符串并将其打印到控制台

然后，我获取相同的字节数组，并通过网络将其发送到windows计算机。Windows计算机使用.net的GUID类型，并使用相同的字节数组创建GUID对象。然后我使用GUID的ToString方法再次将其打印到控制台。令人惊讶的是，同一字节数组在Linux和.Net下有不同的字符串表示形式，尽管它们几乎相似

下面是一个例子：

字节数组：

101208176173236192,64,86191214132,22132143247

Linux： 65d0b0ad-ecc0-4056-bfd6-8402d5e88ff7

.NET： adb0d065-c0ec-5640-bfd6-8402d5e88ff7

正如您可能注意到的，它们非常相似，最后的部分是相同的，第一部分使用相同的数字，只是数字的顺序不同。我按照上面解释的方式创建的每个UUID都遵循相同的模式，这让我认为存在字节顺序差异

---

如何在linux中创建UUID值并使用相同的字节数组具有相同的字符串表示形式。

不幸的是，您不能具有相同的字节数组并具有

Guid。ToString

生成与linux字符串匹配的字符串

您需要决定优先考虑哪一项：

var dotNetGuid = new Guid(new byte[] { 101, 208, 176, 173, 236, 192, 64, 86,
                                       191, 214, 132, 2, 213, 232, 143, 247 });

// option 1 - keep the existing guid's byte array intact
//            and create a new ToUnixString method to display it as-required

Console.WriteLine(dotNetGuid.ToString());      // adb0d065-c0ec-5640-bfd6-8402d5e88ff7
Console.WriteLine(dotNetGuid.ToUnixString());  // 65d0b0ad-ecc0-4056-bfd6-8402d5e88ff7

// option 2 - create a new guid by re-arranging the existing guid's byte array
//            and then use the standard ToString method

var unixGuid = dotNetGuid.ChangeByteOrder();
Console.WriteLine(dotNetGuid.ToString());  // adb0d065-c0ec-5640-bfd6-8402d5e88ff7
Console.WriteLine(unixGuid.ToString());    // 65d0b0ad-ecc0-4056-bfd6-8402d5e88ff7

// ...

public static class GuidExtensions
{
    public static string ToUnixString(this Guid guid,
        string format = "D", IFormatProvider provider = null)
    {
        return guid.ChangeByteOrder().ToString(format, provider);
    }

    public static Guid ChangeByteOrder(this Guid guid)
    {
        var s = guid.ToByteArray();
        var d = new byte[]
                    {
                        s[3], s[2], s[1], s[0], s[5], s[4], s[7], s[6],
                        s[8], s[9], s[10], s[11], s[12], s[13], s[14], s[15]
                    };

        return new Guid(d);
    }
}

根据和消息，问题实际上在于对guid/uuid应该是Big-Endian还是Little-Endian的不同理解。看起来微软的实现将它们视为Big-Endian（至少在英特尔平台上是如此），但uuid_unparse似乎是Little-Endian。表示GUID（即Microsoft的UUID）如下所示，这似乎需要Big-Endian排序

---

因此，这两种实现之间存在明显的不一致性。作为一种解决方法，我建议在两个系统之间以字符串格式交换数据，这在两个系统之间似乎是一致的。

Endianness problem？您是否忘记调用/

ntohs

？好的，我省略了网络部分，我在一个小型.net应用程序中手动输入了相同的字节数组，它仍然没有相同的spring表示形式。我颠倒了字节顺序，它不会生成任何有意义的内容。因此，看起来htons并不是罪魁祸首。据我所知，如果希望在.net和linux之间使用相同的字符串表示形式，则需要按如下所示更改字节顺序。linux中生成的索引的原始顺序是：1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16。在.net中应该使用的顺序是：4,3,2,1,6,5,8,7,9,10,11,12,13,14,15,16，这将生成相同的字符串。在检查了一点之后，我了解到这是endianness问题，正如您在开始时所说的，GUID由4字节int组成，短2字节，短2字节，短81字节，我的linux机器正在以小端顺序转换4字节和2字节。根据，GUI必须编码为大端。