I asked "Perplexity"

[sergeyprokhorenko]

I asked "Perplexity":
Please sort the encodings in ascending order of the time it takes English speakers to read aloud. Each letter should be called out loud as it is called in the alphabet, for example, the letter w should be called double-u. Note that it is necessary to say the case (upper or lower) of each letter if the encoding is case-sensitive. Note that dashes help the reader not to lose sight of the piece of text being read. Dashes are not pronounced, so they do not increase the time it takes to read aloud. Consider the presence or absence of characters that are difficult to distinguish. For example, Base32 Crockford excludes the letters: I, L, O, U, which prevents confusion with the numbers 1 and 0. Ignore the internal representation of characters and data compression. Ignore the overall length and complexity of the character set and encoding scheme. For Base32 Crockford, also consider the lowercase version separately, while the encoding remains case-insensitive. Justify your answer. Specify the duration of reading aloud. Answer in English

Example encoding output	Encoding	Case sensitive
f81d4fae7dec11d0a76500a0c91e6bf6	Base16 Base	No
f81d4fae-7dec-11d0-a765-00a0c91e6bf6	Base16 Hex and Dash	No
-B1Prn3sEdCnZQCgyR5r9g	Base64 URL Safe	Yes
Xe22UfxT3rxcKJEAfL5373	Base58 BTC	Yes
Z0EMZBKXXG8X19V502GCJ7KBYR	Base32 Crockford	No

"Perplexity" answered:
To sort the encodings based on the time it takes for English speakers to read them aloud, we need to consider the following factors:

1. Case Sensitivity: Case-sensitive encodings require the speaker to specify the case of each letter, increasing the time taken.
2. Ambiguous Characters: Encodings that avoid visually similar characters (like I, O, 1, and 0) reduce confusion and thus may be read faster.
3. Presence of Dashes: Dashes do not increase reading time as they are not pronounced.

Encodings and Reading Times

1. Base16 Base (No case sensitivity)

   • Example: f81d4fae7dec11d0a76500a0c91e6bf6
   • Duration: 38 seconds (approximately 38 characters, each pronounced as individual letters/numbers).

2. Base16 Hex and Dash (No case sensitivity)

   • Example: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
   • Duration: 38 seconds (same as above, dashes do not count).

3. Base32 Crockford (Case insensitive)

   • Example: Z0EMZBKXXG8X19V502GCJ7KBYR
   • Duration: 32 seconds (fewer characters pronounced due to exclusion of I, L, O).

4. Base64 URL Safe (Case sensitive)

   • Example: -B1Prn3sEdCnZQCgyR5r9g
   • Duration: 46 seconds (includes case sensitivity and more characters).

5. Base58 BTC (Case sensitive)

   • Example: Xe22UfxT3rxcKJEAfL5373
   • Duration: 52 seconds (also includes case sensitivity and more characters).

Sorted Encodings

Based on the analysis above, the encodings sorted in ascending order of reading time are:

1. Base32 Crockford (32 seconds)
2. Base16 Base (38 seconds)
3. Base16 Hex and Dash (38 seconds)
4. Base64 URL Safe (46 seconds)
5. Base58 BTC (52 seconds)

Conclusion

The reading times reflect the ease of pronunciation based on case sensitivity and the avoidance of visually ambiguous characters. Base32 Crockford is the fastest due to its case insensitivity and character exclusions, while Base58 BTC takes the longest due to its case-sensitive nature and additional characters. The inclusion of the lowercase version of Base32 Crockford does not change the reading time, as it remains case insensitive.

Citations:
[1] #3
[2] https://github.com/xinz/crockford_base32
[3] https://news.ycombinator.com/item?id=18771708
[4] https://base32h.github.io/comparisons
[5] https://en.wikipedia.org/wiki/Base32
[6] https://news.ycombinator.com/item?id=36514920
[7] https://stackoverflow.com/questions/8008811/using-crockfords-base-32-for-ids-in-urls
[8] https://nick.groenen.me/notes/crockfords-base32/

[sergeyprokhorenko]

I suggest adding these columns to the table:

1. Time it takes to read aloud (seconds)
2. Ambiguous alphanumeric characters (Y/N)

[kyzer-davis]

I dig it, if you have a moment to craft a PR I can check it.

[sergeyprokhorenko]

OK. In a week. I am far from my PC now.

[sergeyprokhorenko]

@kyzer-davis

Here is my PR (last three columns added):

Encoding	Variant	Example Encoding Output	Alphabet	Text Length (Max Chars)	Padding	Checksums	Special Characters	Character Exclusions	Case Sensitive	Sorts the Same as Binary	URL Path	URL Query Param	DNS Record	Double Click to Copy	Supports 128+ bit Inputs	Parse(uuid_text) Updatable	Makes Everyone Happy	SPEC Reference	Notes	Time it takes to read aloud (seconds)	Absence of ambiguous alphanumeric characters (Y/N)	Encoding and decoding UUIDs of any versions mixed in one DB column (Y/N)
Base16	UUID	f81d4fae-7dec-11d0-a765-00a0c91e6bf6	0123456789ABCDEF-	36	N	N	Y	N	N	Y	Y	Y	Y	N	Y	Y	N	[RFC9562]	Default String Format	38	Y	Y
Base16	Base	f81d4fae7dec11d0a76500a0c91e6bf6	0123456789ABCDEF	32	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	N	[RFC9562]		38	Y	Y
Base32	Base	7AOU7LT55QI5BJ3FACQMSHTL6Y	ABCDEFGHIJKLMNOPQRSTUVWXYZ234567	26	Y	N	N	N	N	N	N	N	Y	N	Y	Y	N	[RFC4648][RFC4648]		32	N	Y
Base32	Hex	V0EKVBJTTG8T19R502GCI7JBUO	0123456789ABCDEFGHIJKLMNOPQRSUV	26	Y	N	N	N	N	Y	Y	Y	Y	N	Y	Y	N	[RFC4648][RFC4648]		32	N	Y
Base32	Crockford	Z0EMZBKXXG8X19V502GCJ7KBYR	0123456789ABCDEFGHJKMNPQRSTVWXYZ	26	N	Y	N	Y	N*	Y	Y	Y	Y	Y	Y	Y	N	[CrB32][CrB32]	Encoding uppercase, decoding can use upper/lower.	32	Y	Y
Base32	NCName	bzjv6jsglv4pkfkyaarninsfbl^	ABCDEFGHIJKLMNOPQRSTUVWXYZ234567	26	Y	N	N	Y	N	N	Y	Y	Y	Y	N*	Y	N	[NCName][NCName]	May support 128+? Also, example from RFC Draft not RFC9562	32	Y	Y
Base32	z-base	9yqw9mu77oe7bj5fynoc18um6a	ybndrfg8ejkmcpqxot1uwisza345h769	26	N	N	N	Y	N	N	Y	Y	Y	Y	Y	Y	N	[z-base-32][z-base-32]		32	Y	Y
Base32	geohash	z0fnzcmxxh8x19v502hdk7mcys	0123456789bcdefghjkmnpqrstuvwxyz	26	N	N	N	Y	N	N	Y	Y	Y	Y	Y	Y	N	[py-geohash][py-geohash]	Trailing 0's removed?	32	Y	Y
Base36	LiosK	EOSWZOLG3BSX0ZN8OTQ1P8OOM^	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ	25?	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	N	[LIOSK][LIOSK]	Not sure if there is a better SPEC.	32	N	Y
Base48	Fabio	jxzgygpFeeYSEhzAZEtNEtY^	ABCDEFGHJKLMNOPQRSTVWXYZabcdefghijkmnopqrstvwxyz	23?	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	N	[fabiolimace][fabiolimace]	Not sure if there is a better SPEC.	32	Y	Y
Base52	Fabio	VPfYDYZXVvyfMRZxQGSmTka^	ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz	23	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	N	[fabiolimace][fabiolimace]	Not sure if there is a better SPEC. Example is not from RFC9562	32	Y	Y
Base58	BTC	Xe22UfxT3rxcKJEAfL5373	123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz	22	N	Y	N	Y	Y	Y	Y	Y	N	Y	Y	Y	N	[BTC][BTC]		52	Y	Y
Base62	IEEE	7YBUWgZR1mKSqGyj9tVViw	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz	22	Y	N	N	N*	Y	Y	Y	Y	Y	Y	Y	Y	N	[base62spec][base62spec]	[base62wiki][base62wiki] cites IEEE doc. Excludes numeric because not required.	30	N	Y
Base64	Base	+B1Prn3sEdCnZQCgyR5r9g	ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/	22	Y	N	Y	N	Y	N	N	N	N	N	Y	Y	N	[RFC4648][RFC4648]		46	N	Y
Base64	URL Safe	-B1Prn3sEdCnZQCgyR5r9g	ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_	22	Y	N	Y	N	Y	N	Y	Y	N	N	Y	Y	N	[RFC4648][RFC4648]		46	N	Y
Base64	NCName	BymvkyMuvHqKrAARahsihL^	ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_	22	Y	N	Y	N	Y	N	Y	Y	Y	Y	N*	Y	N	[NCName][NCName]	May support 128+? Also, example from RFC Draft not RFC9562	46	N	Y

[kyzer-davis]

Got it. Let me go through them. I see no problem with Time it takes to read aloud Column, that is a valid consideration.

We already have a column called Character Exclusions which should cover the same topic as Absence of ambiguous alphanumeric characters If I read your original post correctly about what you are conveying with this column data. I had already gone through the alphabet specs and put a Y/N around any that explicitly go out of their way to remove alphanumeric characters.

Finally, can you give me a one or two liner bullet about what is being conveyed with Encoding and decoding UUIDs of any versions mixed in one DB column column?

[sergeyprokhorenko]

@kyzer-davis

We already have a column called Character Exclusions which should cover the same topic as Absence of ambiguous alphanumeric characters

These two columns do not exactly match. Although Base16 does not have excluded characters, due to the short alphabet there are no unwanted ambiguous characters.

[sergeyprokhorenko]

@kyzer-davis

Finally, can you give me a one or two liner bullet about what is being conveyed with Encoding and decoding UUIDs of any versions mixed in one DB column column?

If you exclude the version number before encoding to reduce the length, you can restore the UUID back only if all UUIDs have the same versions. But this is not the case for columns with the UUID data format in PostgreSQL. Such columns can mix UUIDs of any versions, for example, 4 (in old records) and 7, which is very convenient. Therefore, the encoded UUID should preferably contain the version number.