代码之家 › 专栏 › 技术社区 › Daniel Schaffer

为什么guid.toString(“n”)与从相同guid的字节数组生成的十六进制字符串不同?

hex guid c#

Daniel Schaffer · 技术社区 · 14 年前

考虑以下单元测试:

    [TestMethod]
    public void TestByteToString()
    {
        var guid = new Guid("61772f3ae5de5f4a8577eb1003c5c054");
        var guidString = guid.ToString("n");
        var byteString = ToHexString(guid.ToByteArray());

        Assert.AreEqual(guidString, byteString);
    }

    private String ToHexString(Byte[] bytes)
    {
        var hex = new StringBuilder(bytes.Length * 2);
        foreach(var b in bytes)
        {
            hex.AppendFormat("{0:x2}", b);
        }
        return hex.ToString();
    }

结果如下:

Assert.AreEqual failed. Expected:<61772f3ae5de5f4a8577eb1003c5c054>. Actual:<3a2f7761dee54a5f8577eb1003c5c054>.

3 回复 | 直到 7 年前

James Curran 14 年前

在前4个字节之后,它们是相同的。前四个是一样的,只是顺序相反。

基本上,当从字符串创建时,它被假定为“big endian”格式:最左边的字节。但是,当在内部存储(在Intel ISH机器上)时,字节被排序为“little endian”:最右边的顺序字节。

ivan_pozdeev RenanSS 7 年前

如果比较结果,可以看到前三组是相反的:

61 77 2f 3a   e5 de   5f 4a   8577eb1003c5c054
3a 2f 77 61   de e5   4a 5f   8577eb1003c5c054

那是因为在 GUID structure ,这3组定义为 DWORD 两个 WORD s而不是字节:

{0x00000000,0x0000,0x0000,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}

所以在内存中,Intel处理器将它们按小尾数顺序存储(最后一个最重要的字节)。

ChrisF 14 年前

GUID的结构如下:

int a
short b
short c
byte[8] d

所以对于代表的部分 a 您的代码将反转字节。所有其他部件都已正确转换。

推荐文章

Flegy · PHP/MSSQL字符串到十六进制

6 年前

Soumil Deshpande · 将十六进制字符串转换为可读输出

6 年前

Jahongir Rahmonov · 计算文件的校验和

6 年前

topcat · 如何从strlen返回中减去十六进制,然后添加到十六进制地址?

6 年前

DenoDev · C-十六进制输出中缺少0

6 年前

Mike -- No longer here · 使用系统设置以最少的代码行将原始字节写入串行(linux C)

6 年前

Elie Daher · 在C中将十六进制转换为uint8\u t++

6 年前

antosr7 · 如何在PostgreSQL中将以:分隔的十六进制ipv6字符串转换为十进制

6 年前

e2rabi · 如何使用Java屏蔽十六进制int?

6 年前

user3780807 · c++流负数转换

6 年前