<p>When I heard it first, I liked the article <a href="http://arxiv.org/html/0901.4016" rel="nofollow">A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable</a>. It encodes data as a sequence of consonants and vowels. It's tied to the English language though. (Because in German, <code>f</code> and <code>v</code> sound equal, so they should not be used both.) But I like the general idea.</p>
Encoding that minimizes misreading / mistyping / misspeaking?
<p>Let's say you have a system in which a fairly long key value can be accurately communicated to a user on-screen, via email or via paper; but the user needs to be able to communicate the key back to you accurately by reading it over the phone, or by reading it and typing it back into some other interface. </p>

<p><strong>What is a "good" way to encode the key to make reading / hearing / typing it easy &amp; accurate?</strong></p>

<p>This could be an invoice number, a document ID, a transaction ID or some other abstract value.  Let's say for the sake of this discussion the underlying key value is a big number, say 40 digits in base 10.</p>

<p><strong>Some thoughts:</strong></p>

<p>Shorter keys are generally better</p>

<ul>
<li>a 40-digit base 10 value may not fit in the space given, and is easy to get lost in the middle of</li>
<li>the same value could be represented in base 16 in 33-34 digits</li>
<li>the same value could be represented in base 36 in 26 digits</li>
<li>the same value could be represented in base 64 in 22-23 digits</li>
</ul>

<p>Characters that can't be visually confused with each other are better</p>

<ul>
<li>e.g. an encoding that includes both O (oh) and 0 (zero), or S (ess) and 5 (five), could be bad</li>
<li>This issue depends on the font / face used to display the key, which you may be able to control in some cases (like printing on paper) but can't control in others (like web pages and email).</li>
<li>Also depends on whether you can control the exclusive use of upper and / or lower case -- e.g. capital D (dee) may look like O (oh) but lower case d (dee) would not; while lower case l (ell) looks like a 1 (one) while capital L (ell) would not. (With exceptions for especially exotic fonts / faces).</li>
</ul>

<p>Characters that can't be verbally / aurally confused with each other are better</p>

<ul>
<li>a (ay) 8 (eight)</li>
<li>B (bee) C (cee) D (dee) E (ee) g (gee) p (pee) t (tee) v (vee) z (zee) 3 (three)</li>
<li>This issue depends on the audio quality of the end-to-end channel -- bigger challenge if the expected user base could have a speech impediment, or may have to speak through a gas mask, or the communication channel could include CB radios or choppy VOIP phone systems.</li>
</ul>

<p>Adding a check digit or two would detect errors but not help resolve errors.</p>

<p>An alpha - bravo - charlie - delta type dialog can help with hearing errors, but not reading errors.</p>

<p><strong>Possible choices of encoding:</strong></p>

<ul>
<li>Base 64 -- compact, but too many hard-to-verbalize characters (underscore, dash etc.)</li>
<li>Base 34 -- 0-9 and A-Z but with O (oh) and I (aye) left out as the easiest to confuse with digits</li>
<li>Base 32 -- same as base 34 but leave out the 0 (zero) and 1 (one) as well</li>
</ul>

<p>Is there a generally recognized encoding that is a reasonable solution for this scenario?</p>