61–70 of 71 posts
Earlier quoted context omitted.
Check out digit-array if you are interested in the generalized algorithm. The source code is commented with formal math notation for the operations. https://github.com/deckar01/digit-array/blob/master/README.m...
This doesn't appear to address the problem. At all. https://paragonie.com/blog/2016/06/constant-time-encoding-bo...
Using an alternative to base64 encoded data for web pages and node is a horrible idea. If I came across a code base using that I would scream. A lot. None of my tools work with it, and now my browser has to run a bunch of js for something that's normally native and very fast. Its a 1-2kb savings per page that's going to make somebody jump off bridge one day.
More terrifying is that the JavaScript community is so fascinated by shiny objects that thousands of people are going to use this. I'm not sure if it's more funny or terrifying.
Anyways, this encoding is still useful if you need to pass data between legacy systems. I've used html escapes and ASCII85 before to get around annoying old stuff that doesn't use Unicode many times
The use of codepoints below 32 (space, start of what's usually considered "printable") makes me a bit hesitant. A lot of systems won't preserve those characters. Base85 is a more efficient alternative to base64, and doesn't use that lower range: https://en.wikipedia.org/wiki/Ascii85
The use of codepoints below 32 (space, start of what's usually considered "printable") makes me a bit hesitant. A lot of systems won't preserve those characters. Base85 is a more efficient alternative to base64, and doesn't use that lower range: https://en.wikipedia.org/wiki/Ascii85
Earlier quoted context omitted.
This doesn't appear to address the problem. At all. https://paragonie.com/blog/2016/06/constant-time-encoding-bo...
I misread your original comment. Nothing I posted is related to constant time encoding. I apologize for the confusion.
Base122 requires UTF-8, and while that's pretty common, it's not universal, so base64 can't ever go away in favor of base122.
Compressed base64 is more efficient than base122 (with or without compression).
Conclusion: Big nope.
Earlier quoted context omitted.
Sure, but I'd consider those edge cases to be situations where the treatment is worse than the disease
HTTPS is an edge condition? Over 50 percent of the web is now transferred via HTTPS.
I appreciate the author building a more efficient alternative to base64, but I had to laugh for a moment at the suggested use case. Using an alternative to base64 encoded data for web pages and node is a horrible idea. If I came across a code base using that I would scream. A lot. None of my tools work with it, and now my browser has to run a bunch of js for something that's normally native and very fast. Its a 1-2kb…
It's not that I don't agree with the general idea of your post, but I disagree with this part. If nobody every tries something new we'd still be in the stone age. I think base122 is a bit silly but if it had it's use and adoption became widespread then browsers and tooling etc. would follow, just as they now support base64.
https://github.com/diafygi/Offset248
Pros: simple, no ratio or ending calculation, easy copy/paste, same character length as original bytes
Cons: has to be percent encoded in urls, some fonts might not render all characters