从base64引导到base64 [英] base64 to guid to base64

查看:125
本文介绍了从base64引导到base64的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在研究MongoDb作为一​​种可能的数据库选项,并且在处理Guid序列化时遇到了麻烦.我最初以为这可能是C#驱动程序序列化中的错误,但现在我认为这更像是天真的假设.

I'm currently researching MongoDb as a possible database option, and I'm having trouble dealing with Guid serialization. I thought at first maybe this was a bug in the C# driver's serialization, but now I think it's more likely a naive assumption on my part.

为帮助我将Bson base64表示形式来回转换为Guids,我编写了一些小powershell函数来提供帮助:

To help me convert the Bson base64 representations back and forth to Guids, I wrote a couple of little powershell functions to help:

function base64toguid  
{  
    param($str);  
    $b = [System.Convert]::FromBase64String($str);
    $hex = "";
    foreach ($x in $b) {
        $hex += $x.ToString("x2");
    }
    $g = new-object -TypeName System.Guid -ArgumentList $hex;
    return $g;
}


function guidtobase64
{
    param($str);
    $g = new-object -TypeName System.Guid -ArgumentList $str;
    $b64 = [System.Convert]::ToBase64String($g.ToByteArray());
    return $b64;
}

我遇到的问题的一个示例:

An example of the issue I'm having:

:) guidtobase64("53E32701-9863-DE11-BD66-0015178A5E3C");
ASfjU2OYEd69ZgAVF4pePA==
:) base64toguid("ASfjU2OYEd69ZgAVF4pePA==");

Guid
----
0127e353-6398-11de-bd66-0015178a5e3c

从mongo shell:

And from the mongo shell:

:) mongo
MongoDB shell version: 1.6.5
connecting to: test
> b = new BinData(3, "ASfjU2OYEd69ZgAVF4pePA==");
BinData(3,"ASfjU2OYEd69ZgAVF4pePA==")
> b.hex();
127e353639811debd66015178a5e3c
>

因此,如您所见,我返回的Guid与我输入的Guid不匹配.我的函数和hex()返回相同的内容.如果您将原始图与结果进行比较:

So as you can see, the Guid I get back doesn't match what I put in. My function and hex() return the same thing. If you compare the original to the result:

53E32701-9863-DE11-BD66-0015178A5E3C
0127e353-6398-11de-bd66-0015178a5e3c

53E32701-9863-DE11-BD66-0015178A5E3C
0127e353-6398-11de-bd66-0015178a5e3c

您可以看到前3组十六进制对是相反的,但后2组不是.这让我觉得关于Guid.ToString()的某些事情我不了解.

You can see that the first 3 sets of hex pairs are reversed, but the last 2 sets are not. This makes me think there is something about Guid.ToString() that I don't understand.

任何人都可以教育我吗?

Can anyone educate me please?

推荐答案

GUID中字节的顺序与小尾数系统中其ToString()表示形式的顺序不同.

The order of bytes in a GUID are not the same as the order in their ToString() representation on little-endian systems.

您应该使用guid.ToByteArray()而不是ToString().

You should use guid.ToByteArray() rather than using ToString().

而且,您应该使用new Guid(byte[] b)来构造它,而不是$str.

And, you should use new Guid(byte[] b) to construct it, rather than $str.

要用纯C#表示:

public string GuidToBase64(Guid guid)
{
    return System.Convert.ToBase64String(guid.ToByteArray());  // Very similar to what you have.
}

public Guid Base64Toguid(string base64)
{
    var bytes = System.Convert.FromBase64String(base64);
    return new Guid(bytes);  // Not that I'm not building up a string to represent the GUID.
}


在Wikipedia上查看GUID文章的基本结构"部分有关更多详细信息.


Take a look at the "Basic Structure" section of the GUID article on Wikipedia for more details.

您将看到大多数数据都存储在本地"字节序中……这是造成混淆的地方.

You will see that most of the data is stored in "Native" endianness... which is where the confusion is coming from.

引用:

Data4以与GUID文本编码中显示的相同顺序存储字节(请参见下文),但是在小尾数系统(例如Intel CPU)上,其他三个字段是相反的.

Data4 stores the bytes in the same order as displayed in the GUID text encoding (see below), but the other three fields are reversed on little-endian systems (for example Intel CPUs).


Powershell版本:

Powershell version:

function base64toguid  
{  
    param($str);  
    $b = [System.Convert]::FromBase64String($str);
    $g = new-object -TypeName System.Guid -ArgumentList (,$b);
    return $g;
}

作为附加的警告,您可以选择在字符串的末尾剪掉"==",因为它只是填充(如果您想节省空间,这可能会有所帮助).

As an additional caveat, you can optionally trim the "==" off of the end of your string, since it is just padding (which may help if you are trying to save space).

这篇关于从base64引导到base64的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆