Base64 to guid to base64

Question

I'm currently learning MongoDb as a possible database option, and I'm having problems serializing Guid. At first, I thought it was a mistake in serializing C # serialization, but now I think it is rather a naive assumption on my part.

To help me convert Bson basebox views back and forth to Guids, I wrote a few small 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 a problem that occurs to me:

 :) guidtobase64("53E32701-9863-DE11-BD66-0015178A5E3C"); ASfjU2OYEd69ZgAVF4pePA== :) base64toguid("ASfjU2OYEd69ZgAVF4pePA=="); Guid ---- 0127e353-6398-11de-bd66-0015178a5e3c 

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 > 

So, as you can see, Guid, I will return, does not match what I have invested. My function and hex () return the same. If you compare the original with the result:

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

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

Can someone enlighten me please?

Answer 1

The byte order in the GUID does not match the order in the ToString() view on little-endian systems.

You should use guid.ToByteArray () instead of using ToString ().

And you should use new Guid(byte[] b) to create it, not $str .

To express this in pure 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. } 

---

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

You will see that most of the data is stored in "Native" endianness ..., which causes confusion.

Quote:

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

<h / ">

Edit:

Powershell Version:

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

As an additional warning, you can trim the “==” at the end of the line if necessary, as this is just an addition (which may help if you are trying to save space).

Answer 2

You need to call the constructor Guid, which takes a byte array. There you need a special syntax in Powershell - if you just pass $ b, it will tell you that it cannot find a constructor that takes 16 arguments, so you have to wrap the byte array in another array:

 $g = new-object -TypeName System.Guid -ArgumentList (,$b) 

Answer 3

Looking at the c-sharp driver documentation on the mongo website, it turns out that there is an implicit conversion for System.Guid.

So, in C # (sorry, my powershell is a little rusty), you just write:

 Guid g = Guid.NewGuid(); //or however your Guid is initialized BsonValue b = g; 

I assume that the opposite will probably work:

 BsonValue b = // obtained this from somewhere Guid g = b; 

If you do not have the specific need to serialize Guid as base64, then converting directly to binary will work much less (note that, for example, there will be no problems with endian). In addition, the data will be stored in binary form on the server, so this will be more space than using base64.