News for hackers. Stuff that matters.

A comment on Base64 encoding and decoding at almost the speed of a memory copy. Parent comment

Re:Base64 encoding and decoding at almost the speed of a mem... by panic on Wednesday November 06, 2019 @02:05AM (#21460356)
This is relevant to webdev, though -- binary data in JSON is often encoded as a Base64 string.
[ Parent | on HN ]
Re:Base64 encoding and decoding at almost the speed of a mem... by wingi on Wednesday November 06, 2019 @02:09AM (#21460370)
Why use 6-bit data, if JSON can transport 8-bit (-1 for quoting the ") ?
[ Parent | on HN ]
Re:Base64 encoding and decoding at almost the speed of a mem... by cryptonector on Wednesday November 06, 2019 @02:14AM (#21460391)
Byte values that are ASCII control characters need to be escaped, and byte values that are not valid UTF-8 can't be represented in JSON strings.
[ Parent | on HN ]
Re:Base64 encoding and decoding at almost the speed of a mem... by Vrixam on Wednesday November 06, 2019 @02:16AM (#21460398)
Would this always be valid UTF8?
[ Parent | on HN ]
Re:Base64 encoding and decoding at almost the speed of a mem... by conradfr on Wednesday November 06, 2019 @08:29AM (#21462280)
As an anecdote I have a Phoenix LiveView project where I've discovered that loading, converting and sending an (uncacheable) image as base64 via the websocket connection feels quicker and smoother (I didn't benchmark it) than only updating the src path and letting the browser load it (with http1, I would have to compare with http2).
[ Parent | on HN ]