[HN Gopher] Base64 Encoding, Explained
       ___________________________________________________________________
        
       Base64 Encoding, Explained
        
       Author : software_writer
       Score  : 46 points
       Date   : 2023-10-23 05:28 UTC (3 hours ago)
        
 (HTM) web link (www.akshaykhot.com)
 (TXT) w3m dump (www.akshaykhot.com)
        
       | bediger4000 wrote:
       | > Base64 encoding takes binary data and converts it into text,
       | specifically ASCII text.
       | 
       | Perpetuates the idea that there's "binary" and "text", which is
       | incorrect, but also implies you can't encode ordinary ASCII text
       | into base64.
        
         | farhanhubble wrote:
         | The article actually shows an example of text to base64
         | encoding. But base64 is generally used for encoding data in
         | places where only ascii is admissible like URLs and inlined
         | binary blobs
        
           | jillesvangurp wrote:
           | It's part of a lot of web standards and also commonly used
           | for crypto stuff. E.g. the plain text files in your .ssh
           | directory are typically in base64 encoding; if you use basic
           | authentication that's $user:$passwd base64 encoded in a
           | header; you can indeed use it to have images and other inline
           | content in the url in web pages; email attachments are
           | usually base64 encoded. And so on. One of those things any
           | decent standard library for just about any language would
           | need.
        
         | Aachen wrote:
         | There is binary and text, though. Many bit sequences aren't
         | valid in a given text encoding (such as UTF-whatever) and so
         | trying to use them as text is an error.
         | 
         | I understand what you mean, of course text can be represented
         | and treated as binary, and the inverse often as well although
         | it isn't necessarily true. Even in Windows-1252, where the
         | upper 127 characters are in use, there are control characters
         | such as null, delete, and EOT which I'd be impressed if a
         | random chat program preserves them across the wire.
         | 
         | I also don't read an implication that ASCII couldn't be
         | converted to b64
        
       | adamzochowski wrote:
       | There is also base64URL , where the encoding uses different ascii
       | characters that are url safe. I have seen some devs use BASE64URL
       | but call it just base64, and that can lead to some problems for
       | unaware.
       | 
       | https://datatracker.ietf.org/doc/html/rfc4648#section-5
        
         | JimDabell wrote:
         | The problem with base64url is that ~ and . are not letters.
         | This means that double-clicking on something encoded with
         | base64url isn't going to select the whole thing if you want to
         | copy-paste it. This is annoying needless friction in a huge
         | number of use cases. Base62 encoding (0-9A-Za-z) is almost as
         | efficient as base64url and retains URL safety but is more
         | easily copy-pasted.
         | 
         | If you want to eliminate ambiguity for human readers, you can
         | drop to Base58 but in almost all cases, if you are BaseXX-
         | encoding something, it's long enough that copy-pasting is the
         | norm, so it doesn't usually matter.
         | 
         | https://en.wikipedia.org/wiki/Base62
        
           | iainmerrick wrote:
           | _The problem with base64url is that ~ and . are not letters._
           | 
           | No, typically the extra characters used are "-" and "_".
           | That's what the table in the IETF link shows.
        
           | Aachen wrote:
           | > The problem with base64url is that ~ and . are not letters.
           | This means that double-clicking on something encoded with
           | base64url isn't going to select the whole thing
           | 
           | Well, you're in luck: tilde and dot aren't part of base64url
        
           | nly wrote:
           | Encoding and decoding base58 is a lot less efficient (needs
           | arithmetic multiplication with a carry across the stream).
           | 
           | Base32 is sufficient in most cases and can avoid some
           | incidental swear words.
           | 
           | If you want density go for Z85, which is a 4 -> 5 byte
           | chunked encoding and therefore much more efficient on a
           | pipelined CPU.
           | 
           | https://rfc.zeromq.org/spec/32/
        
       | erhaetherth wrote:
       | Funny. I'm trying to write a base50 encoder now. No good reason,
       | just 'cuz. Can't quite figure out what to do with the half a bit.
       | Gotta carry it forward somehow until I have a full char again but
       | haven't come up with a good scheme.
        
         | rustybolt wrote:
         | What do you mean, half a bit? A typical base50 encoder would
         | use 50 characters, so say 309 would get encoded as 69 (309 = 6
         | * 50 + 9 * 1).
        
         | VMG wrote:
         | write a base-n encoder and use 50 as a parameter
        
       | benjaminwai wrote:
       | Just a note with the Bash encoding method. It should be with the
       | -n option:                 $ echo -n "abcde" |base64
       | 
       | Otherwise, without the -n, echo injects an extra newline
       | character to the end of the string that would become encoded.
        
         | manojlds wrote:
         | Yeah been bit by few times. Somehow keep forgetting.
        
       ___________________________________________________________________
       (page generated 2023-10-23 09:00 UTC)