Dev time waster ala JSON dialect
-
Clearing away the cobwebs...nice to see a new post here!...over a month since the last one! :laugh: I'd rather deal with this type of dev time waster than the kind I seem to be cursed with...'Dev time waster ala Human dialect'. At least this one has a solution. :laugh: Seriously though, it's common for me to spend > 2 hours/day listening to other people vent. (wife/brother-in-law/neighbor/coworker) They obviously are mistaking me for a therapist! :|
"Go forth into the source" - Neal Morse
kmoorevs wrote:
I'd rather deal with this type of dev time waster than the kind I seem to be cursed with...'Dev time waster ala Human dialect'. At least this one has a solution. :laugh:
Agree 100%! :) So true...devs are often therapists...and often need therapists. :rolleyes: I'm usually listening to a problem or griping about one myself. :laugh:
-
I once had a similar issue with a GUID. Apparently there are different ways to look at a GUID :doh: I'm not really sure if it was anymore, some encoding issue or whatever, but two applications showed the same GUID differently :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
I'm not really sure if it was anymore, some encoding issue or whatever, but two applications showed the same GUID differently
If you look at Create GUID (Visual Studio Tools) - snapshot[^] you can generate GUIDs like: All the same value, but different formats. 1. 2. [Guid("0C2D39CD-F486-435B-BDBA-64A124D04D31")] 3. {0C2D39CD-F486-435B-BDBA-64A124D04D31} 4. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} static const GUID <> = { 0xc2d39cd, 0xf486, 0x435b, { 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31 } }; 5. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} DEFINE_GUID(<>, 0xc2d// {0C2D39CD-F486-435B-BDBA-64A124D04D31} 6. IMPLEMENT_OLECREATE(<>, <>, 0xc2d39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31); 39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31);
-
I have an app that runs on multiple (Windows, iOS, Android - as both a native app or as a web app). JSON is a nice lingua franca -- I thought. You see my app has simple string-based keys the user adds to keep track of her sites. Since I'm not sure what the user might type, I go ahead and encode the keys to Base64. Normally you see some Base64 encoded keys which look like: c3VwZXJzaXRl c2Vjb25kU2l0ZQ== dGhyZWU= Serialize Object As JSON In my web apps and on Windows I serialize all the user's sites as objects via JSON and it works great and looks like:
[{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c3VwZXJzaXRl","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"dGhyZWU=","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c2Vjb25kU2l0ZQ==","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"eWV0QW5vdGhlcg==","MaxLength":0}]
Of course on web sites (JavaScript), its the old
JSON.stringify(allSiteKeys)that handles that so nicely. And on Windows I've always used NewtonSoft libraries and it all works great. All interchangeable. Android Gson - Google's JSON Enter the problem. However, while developing on Android I wanted to serialize the data the same way so I turned to Gson which is Google's official Android way of doing this. However, I noticed that values which were Base64 encoded properly were output to JSON in an interesting way. Every equal sign was altered to \u003d which is the unicode equals sign[^]. That means my JSON would be altered to look like:[{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c3VwZXJzaXRl","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"dGhyZWU\u003d","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c2Vjb25kU2l0ZQ\u003d\u003d","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"eWV0QW5vdGhlcg\u003d\u003d","MaxLength":0}]
NOTE: This is not a case of oddly encoded Base64 -- if I look directly at the Base64 encoded data it still has the equals signs. This only occurred when the data was serialized to JSON. Searching For An Answer It wasn't easy to find the answer, because a Google de
A good reason to ALWAYS add your own abstraction layer on top of ANY API that you use. It is a lot easier to do it up front then try to retrofit it later. This keeps your dependencies well documented as well. String jsonSiteKeys = MyLib.json.toJson(allSiteKeys); Or maybe better String jsonSiteKeys = MyLib.toJson(allSiteKeys);
-
Sander Rossel wrote:
I'm not really sure if it was anymore, some encoding issue or whatever, but two applications showed the same GUID differently
If you look at Create GUID (Visual Studio Tools) - snapshot[^] you can generate GUIDs like: All the same value, but different formats. 1. 2. [Guid("0C2D39CD-F486-435B-BDBA-64A124D04D31")] 3. {0C2D39CD-F486-435B-BDBA-64A124D04D31} 4. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} static const GUID <> = { 0xc2d39cd, 0xf486, 0x435b, { 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31 } }; 5. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} DEFINE_GUID(<>, 0xc2d// {0C2D39CD-F486-435B-BDBA-64A124D04D31} 6. IMPLEMENT_OLECREATE(<>, <>, 0xc2d39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31); 39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31);
Yeah, but this was really like one tool showing "abc" while another showed "123" and they still somehow had the same underlying value :confused: I remember this was a thing on MongoDB, so I just installed Robo 3T just to look at the options and it's Legacy UUID encoding (do not decode or use Java/.NET/Python encoding). A coworker used another tool with another encoding and we were looking at the same document, but different values :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Sander Rossel wrote:
I'm not really sure if it was anymore, some encoding issue or whatever, but two applications showed the same GUID differently
If you look at Create GUID (Visual Studio Tools) - snapshot[^] you can generate GUIDs like: All the same value, but different formats. 1. 2. [Guid("0C2D39CD-F486-435B-BDBA-64A124D04D31")] 3. {0C2D39CD-F486-435B-BDBA-64A124D04D31} 4. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} static const GUID <> = { 0xc2d39cd, 0xf486, 0x435b, { 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31 } }; 5. // {0C2D39CD-F486-435B-BDBA-64A124D04D31} DEFINE_GUID(<>, 0xc2d// {0C2D39CD-F486-435B-BDBA-64A124D04D31} 6. IMPLEMENT_OLECREATE(<>, <>, 0xc2d39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31); 39cd, 0xf486, 0x435b, 0xbd, 0xba, 0x64, 0xa1, 0x24, 0xd0, 0x4d, 0x31);
Oh no my friend, it gets far worse than that :) A GUID is simply an 128 bit number in 5 chunks of 32-16-16-16-48. GUIDs like {0C2D39CD-F486-435B-BDBA-64A124D04D31} are when the first chunk of 32 bits is converted into hex, then the next chunk and so on, but when you use some dumb-ass third-party system that stores the bytes in a different order *cough*mongodb*cough* then the string representation of the same data can look different in two different systems despite being equal. I know this is more of a UUID issue than a GUID one, but it shows the kind of nightmares you come across when you stray from the Microsoft path.
-
Oh no my friend, it gets far worse than that :) A GUID is simply an 128 bit number in 5 chunks of 32-16-16-16-48. GUIDs like {0C2D39CD-F486-435B-BDBA-64A124D04D31} are when the first chunk of 32 bits is converted into hex, then the next chunk and so on, but when you use some dumb-ass third-party system that stores the bytes in a different order *cough*mongodb*cough* then the string representation of the same data can look different in two different systems despite being equal. I know this is more of a UUID issue than a GUID one, but it shows the kind of nightmares you come across when you stray from the Microsoft path.
-
Yeah, but this was really like one tool showing "abc" while another showed "123" and they still somehow had the same underlying value :confused: I remember this was a thing on MongoDB, so I just installed Robo 3T just to look at the options and it's Legacy UUID encoding (do not decode or use Java/.NET/Python encoding). A coworker used another tool with another encoding and we were looking at the same document, but different values :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Oh no my friend, it gets far worse than that :) A GUID is simply an 128 bit number in 5 chunks of 32-16-16-16-48. GUIDs like {0C2D39CD-F486-435B-BDBA-64A124D04D31} are when the first chunk of 32 bits is converted into hex, then the next chunk and so on, but when you use some dumb-ass third-party system that stores the bytes in a different order *cough*mongodb*cough* then the string representation of the same data can look different in two different systems despite being equal. I know this is more of a UUID issue than a GUID one, but it shows the kind of nightmares you come across when you stray from the Microsoft path.
F-ES Sitecore wrote:
A GUID is simply an 128 bit number in 5 chunks of 32-16-16-16-48. GUIDs like {0C2D39CD-F486-435B-BDBA-64A124D04D31} are when the first chunk of 32 bits is converted into hex, then the next chunk and so on, but when you use some dumb-ass third-party system that stores the bytes in a different order *cough*mongodb*cough* then the string representation of the same data can look different in two different systems despite being equal.
Oh that is really terrible. You'd think they'd mention Big-Endian v. Little-Endian or some such.
-
Sander Rossel wrote:
Yeah, but this was really like one tool showing "abc" while another showed "123"
That is interesting and painful. Very similar to my problem.
Mostly painful :laugh:
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Quote:
when you stray from the Microsoft path
Stay on the path! Mirkwoodicrosoft has many hidden dangers!
- I would love to change the world, but they won’t give me the source code.
+1 for the {4C 4F 54 52} reference :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I have an app that runs on multiple (Windows, iOS, Android - as both a native app or as a web app). JSON is a nice lingua franca -- I thought. You see my app has simple string-based keys the user adds to keep track of her sites. Since I'm not sure what the user might type, I go ahead and encode the keys to Base64. Normally you see some Base64 encoded keys which look like: c3VwZXJzaXRl c2Vjb25kU2l0ZQ== dGhyZWU= Serialize Object As JSON In my web apps and on Windows I serialize all the user's sites as objects via JSON and it works great and looks like:
[{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c3VwZXJzaXRl","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"dGhyZWU=","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c2Vjb25kU2l0ZQ==","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"eWV0QW5vdGhlcg==","MaxLength":0}]
Of course on web sites (JavaScript), its the old
JSON.stringify(allSiteKeys)that handles that so nicely. And on Windows I've always used NewtonSoft libraries and it all works great. All interchangeable. Android Gson - Google's JSON Enter the problem. However, while developing on Android I wanted to serialize the data the same way so I turned to Gson which is Google's official Android way of doing this. However, I noticed that values which were Base64 encoded properly were output to JSON in an interesting way. Every equal sign was altered to \u003d which is the unicode equals sign[^]. That means my JSON would be altered to look like:[{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c3VwZXJzaXRl","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"dGhyZWU\u003d","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"c2Vjb25kU2l0ZQ\u003d\u003d","MaxLength":0},{"HasSpecialChars":false,"HasUpperCase":false,"Key":"eWV0QW5vdGhlcg\u003d\u003d","MaxLength":0}]
NOTE: This is not a case of oddly encoded Base64 -- if I look directly at the Base64 encoded data it still has the equals signs. This only occurred when the data was serialized to JSON. Searching For An Answer It wasn't easy to find the answer, because a Google de
The bigger issue is that the difference in encoding doesn't make any difference. According to the JSON standard this encoding is valid and will make no difference to the deserialization operation. In fact, all the characters could be encoded in this way, and it should still work. Mike...
-
I once had a similar issue with a GUID. Apparently there are different ways to look at a GUID :doh: I'm not really sure if it was anymore, some encoding issue or whatever, but two applications showed the same GUID differently :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
different ways to look at a GUID :doh:
Yes, there are "case-sensitive" Guids. I guess it was project ids in a Visual Studio solution file...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
