4 ms·
I developed safe32 for this reason. https://github.com/kstenerud/safe-encoding/blob/master/safe32-specification.md https://github.com/kstenerud/safe-encoding/b
by kstenerud 2y ago
I developed safe32 for this reason.
https://github.com/kstenerud/safe-encoding/blob/master/safe32-specification.md https://github.com/kstenerud/safe-encoding/blob/master/safe3...
Notably, confusable characters are interchangeable when being ingested (although a machine encoder MUST always produce canonical output). https://github.com/kstenerud/safe-encoding/blob/master/safe32-specification.md#alphabet https://github.com/kstenerud/safe-encoding/blob/master/safe3...
So a user can confuse 1 for l, 0 for o, I for l, u for v, uppercase, lowercase etc, or the agent can say any of those over the phone, and it won't matter.
- vanderZwan 2y agoOh that looks well-thought out and is probably the sanest way to solve this particular problem! It's obvious why the safe64/safe80/safe85 cannot do this, but is there a reason why the safe16 version doesn't have the same features?
- kstenerud 2y agoOh whoops that's an oversight! I'll fix that up tonight.
- what 2y agoIsn’t this just crockford encoding?
- kstenerud 2y agoEvery base-32 style encoding is Crockford at the core. The difference is in the alphabet, and also whether it requires padding or not (safe32 does not). Crockford also incorporates error correction, which is unnecessary in modern systems since the underlying protocols do that already.
- ss64 2y agoAnother approach is using base31 with all vowels removed https://ss64.com/ps/syntax-base31.html https://ss64.com/ps/syntax-base31.html
- kstenerud 2y agoYou still have the problem of 1 vs l. And also it doesn't support user-error (reading 0 as O, or reading V as U).