LiveCode Forums.

FourthWorld wrote: Wed Feb 07, 2018 10:20 pm If we conservatively assume that all of us have collectively spent ~10 hours trying to find workarounds for the formatting issues inherent in using base64 for hashes, the system would need to transmit hashes 3,025,210,084 times before the 40-bytes savings hits break-even.

Although I have not (yet) spent any time on finding a work around for this, pragmatically, I'd say he has a point.

FourthWorld wrote: Wed Feb 07, 2018 10:20 pm

MaxV wrote: Wed Feb 07, 2018 6:09 pm

FourthWorld wrote: Wed Feb 07, 2018 2:50 pm Use hex rather than base64 and all this goes away.

However base64encode produce shorter strings, so in case of bigger data, it saves much more space/bandwidth/time.

The difference in length between a hex representation of a SHA3 hash and a base64 representation is ~40 bytes. ....

exactly, but I wrote in case of bigger data.

Example: Image of 1.2Mb, base64encode is 462'028 chars shorter than hex.

Richard,
you know that Italians do everything to get every horsepower they can get
Speed is everything.

Hey, I partially resemble that remark! Must be the other parts of my ancestry just don't care enough heh

MaxV wrote: Thu Feb 08, 2018 12:27 pm

FourthWorld wrote: Wed Feb 07, 2018 10:20 pm

MaxV wrote: Wed Feb 07, 2018 6:09 pm

However base64encode produce shorter strings, so in case of bigger data, it saves much more space/bandwidth/time.

The difference in length between a hex representation of a SHA3 hash and a base64 representation is ~40 bytes. ....

exactly, but I wrote in case of bigger data.

Example: Image of 1.2Mb, base64encode is 462'028 chars shorter than hex.

At the average Internet speed that would save 0.141689 seconds per transfer. Modest, but approaching thresholds one might care about, which is why most people POST binary data to servers as base64 (though even faster to just leave it as binary as a File object).

In a thread about image uploads that would be a good thing to keep in mind. But in this thread about hashes we're dealing with very different requirements.

I don't think there's a one-size-fits-all solution for anything, certainly not for transmission formats. We use what's best for the unique characteristics of the task at hand.

If we look around on the 'net we see that hashes are most commonly transferred (and even stored) as hex. I've seen a few discussions about base64 and other formats for this purpose, but most of those discussions tend to reflect this thread: while it's possible to use base64 for hashes, most people prefer to avoid the challenges involved and just stick with hex instead.

I took my time to specialy create another clear stack - I tested it before uplading the Zip - it works perfectly with my server and DBs.
The only remaining problem is that it retreives extra unwanted characters.
so one is not too sure after all the extra work how to understand :

In short, I don't believe this is the actual code you are attempting to use.

where there is not trust...there is not deal

Ok, summing up,

I came to use the HEX function has follow :
it does give me good results for both, sending & retreving strings
(still there is a diference in lenght)
...I added a bynarydecode to display the string in a field, otherwise I cant compare them visualy, right ?

as for the URLencode produced string, I keep loosing the code I had found to build it from the retreived value...so nothing for the moment...

Wahhh, ITS SOLVED !!!

As for this case - the BynaryHex function (quoted above) was the only function necessary to avoid "+" symbols to turn into " " (spaces).

Plus - the extra - unwanted caracters which gave the retreived string a diferent lenght was because of an unapropriate PARSING of the retreived value that ghettocottage helped solving through another topic
Thanks to all for their time and will to help