Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Base24 binary-to-text encoding for humans

kuon.ch

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Show HN: Base24 binary-to-text encoding for humans

#41

Post by anonsivalley652 »

directionless wrote: post #2

I'm fond us using a base100, made of up 2 letter syllables. It results in a vaguely pronounceable string. For syllables, I use: syllables: %w[ ba be bi bo bu ca ce ci co cu da de di do du fa fe fi fo fu ga ge gi go gu ha he hi ho hu ja je ji jo ju ka ke ki ko ku la le li lo lu ma me mi mo mu na ne ni no nu pa pe pi po pu ra re ri ro ru sa se si so su ta te ti to tu va ve vi vo vu wa we wi wo wu xa xe xi xo xu ya ye y…

That's not "base-100" in terms of symbols or storage, it's functionally-identical to base-10! Be honest about how terrible it is.

Re: Show HN: Base24 binary-to-text encoding for humans

#42

Post by anonsivalley652 »

tlhunter wrote: post #13

> The final alphabet I came up with is ZAC2B3EF4NH5TKL7P8RS9WXY. As I required 24 characters, I kept G and 6 which are the least ambiguous in the list. I've read this a dozen times. Isn't OP saying that their character list includes G and 6, which are _not_ present in that list? Update: It appears to be a typo in the article. Here's the real alphabet (N replaced by G and L replaced by 6): ZAC2B3EF4GH5TK67P8RS9WXY htt…

S 5 6 G

P R

2 Z

8 B

look similar, depending on the font

It would be better to include some lower case characters which have more visual variability than trying to obsess over an arbitrary, inflexible stylistic "design."

Re: Show HN: Base24 binary-to-text encoding for humans

#43

Post by VMG »

wp381640 wrote: post #4

Microsoft product keys were base-24 with the following alphabet: > B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9 they were 115 bits encoded in 24 characters see also human-oriented base32 encoding: https://philzimmermann.com/docs/human-oriented-base-32-encod... which includes this nice trick: > We have permuted the alphabet to make the more commonly occuring characters also be those that we think are easier to read…

See also Bech32 which includes error correction and detection:

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...

> Why not use an existing character set like RFC3548 or z-base-32? The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

Re: Show HN: Base24 binary-to-text encoding for humans

#44

Post by twanvl »

Fnoord wrote: post #33
wp381640 wrote: post #4

Microsoft product keys were base-24 with the following alphabet: > B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9 they were 115 bits encoded in 24 characters see also human-oriented base32 encoding: https://philzimmermann.com/docs/human-oriented-base-32-encod... which includes this nice trick: > We have permuted the alphabet to make the more commonly occuring characters also be those that we think are easier to read…

> We have permuted the alphabet to make the more commonly occuring characters also be those that we think are easier to read, write, speak, and remember. Basically they removed vowels (except for y, if it counts as one) as non-vowels often include a vowel in their sound. A fact reinforced while teaching my toddler daughter letters, words, and numbers. On top of that, they removed l/1(/i, and also o/0), m/n, s/5, z. N…

> Not sure why they removed z. Perhaps because of 2?

My guess would be because of C, since Z can be pronounced as "zee"

Re: Show HN: Base24 binary-to-text encoding for humans

#45

Post by kozak »

beojan wrote: post #40
kozak wrote: post #39

If you consider the scenario of dictating over the phone, letters can be confusing not just because of their written shape. For many non-English speakers, for example, E can be confused with I, and V can be confused with W, unless both sides use the same way of pronouncing them. Look how Microsoft's base24 alphabet (from the other comment) has neither E nor I.

That's what the NATO phonetic alphabet is for.

In this case the phonetic alphabet will do the job only for English-speaking countries (or at least those that are very well accustomed to Latin characters).

Re: Show HN: Base24 binary-to-text encoding for humans

#46

Post by Aardwolf »

> The data length must be multiple of 32 bits. There is no padding mechanism in the encoder.

Such padding mechanism should not be necessary, and the padding from standard base64 is also not necessary. If you remove the ==='s you can still unambiguously decode it (despite the error some tools will give). URL-safe base64 (RFC 4648 §5) does not require padding and can represent any data length.

Re: Show HN: Base24 binary-to-text encoding for humans

#47

Post by cyphar »

Dylan16807 wrote: post #18
strags wrote: post #16

Earlier quoted context omitted.

I recently needed to encode a 32-bit value into something easy for QA folks to remember and report. I opted for 3 words out of an 11-bit (2048 entry) dictionary of commonly used words. How to build the dictionary? Well, in order to determine the most commonly used English words, I downloaded a bunch of free texts from Project Gutenberg, and did some simple filtering - nothing less than 5 letters, no duplication of si…

In most cases if you need a short list it's better to use something like the diceware or EFF lists than to make your own from scratch.

Or use the BIP39 lists since they also encode 2048 bits. If you just use BIP39 you also get a checksum. RFC 1751[1] is the "standardised" option but IMHO the wordlist they use is far too easy to misread (though this is because the words are all less than 4 characters).

[1]: https://tools.ietf.org/html/rfc1751

Re: Show HN: Base24 binary-to-text encoding for humans

#48

Post by jansan »

hajimemash wrote: post #24
wp381640 wrote: post #4

Microsoft product keys were base-24 with the following alphabet: > B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9 they were 115 bits encoded in 24 characters see also human-oriented base32 encoding: https://philzimmermann.com/docs/human-oriented-base-32-encod... which includes this nice trick: > We have permuted the alphabet to make the more commonly occuring characters also be those that we think are easier to read…

Brings me back to the trusty old FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8

I never heard of this before. At first I thought it's some kind of joke with the "FCK" at the beginning.

Re: Show HN: Base24 binary-to-text encoding for humans

#49

Post by jansan »

Groxx wrote: post #6

Though clearly there are some advantages with removing ambiguous chars... I feel like it's more of a UI / UX thing-to-polish than a problem . Lack of polish creates the problem, the ambiguous chars themselves are not inherently an issue. If it's ambiguous, you could accept either and transform it to the correct value (implicitly, or as entered, or whenever makes sense. your users don't ever have to know). Or if you c…

With my old shareware product that really did not sell a lot, I got one phone call from a customer who was not able to enter the correct license code. Of course he had mixed up 0 and O. So yes, for some people it solves a problem.

Re: Show HN: Base24 binary-to-text encoding for humans

#50

Post by genera1 »

raxxorrax wrote: post #38
hajimemash wrote: post #24

Earlier quoted context omitted.

Brings me back to the trusty old FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8

I wonder who owns that license. Some people allegedly used this as their password...

It was a special volume license key that didn't require online or phone activation, so presumably an OEM that got a release version couple weeks early
Post reply on HN