Comprender y evitar los caracteres visualmente ambiguos en los ID

Comprender los caracteres visualmente ambiguos en los ID

• Los caracteres visualmente ambiguos son aquellos que resultan difíciles de distinguir en ciertas tipografías o en escritura a mano
  • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g, entre otros
• Estos caracteres pueden provocar errores y confusión al ingresar datos
  • Por ejemplo, cuando al usuario le cuesta distinguir entre 'O' y '0' y termina introduciendo un código incorrecto, lo que genera una mala experiencia de uso
• Esto es especialmente importante en situaciones donde el ID se transmite verbalmente o debe escribirse a mano
  • Soporte al cliente, códigos de descuento, códigos de seguimiento, ID de error, ID de producto, etc.

Decidir si distinguir entre mayúsculas y minúsculas

• Es necesario decidir si los ID distinguirán entre mayúsculas y minúsculas
  • Si se distinguen mayúsculas y minúsculas, y se excluyen las ambigüedades visuales, quedan 53 caracteres utilizables
  • Si no se distinguen mayúsculas y minúsculas, quedan 22 caracteres utilizables
• Si la longitud del ID es de 5 caracteres, la cantidad posible de ID es:
  • Distinguiendo mayúsculas y minúsculas: 53^5 = 418,195,493
  • Sin distinguir mayúsculas y minúsculas: 22^5 = 5,153,632
• Sin embargo, a medida que aumenta la longitud del ID, la cantidad posible de ID crece exponencialmente
• Por lo tanto, hay que encontrar un equilibrio entre la longitud del ID y la posibilidad de ambigüedad visual
• Además, si se usan tanto mayúsculas como minúsculas, pueden surgir problemas inesperados en sistemas de terceros que no distinguen entre ambas

Conjunto de caracteres visualmente claros

• Si la prioridad es la legibilidad, se recomienda usar el siguiente conjunto de caracteres:
  • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

Consideraciones adicionales

• Algunas combinaciones de caracteres pueden parecerse a otros caracteres (por ejemplo: rn puede verse como m, y 3 puede verse como w)
  • Conviene evitar estas combinaciones en la etapa de generación del ID
• También es recomendable evitar caracteres con pronunciación similar (por ejemplo: b y p)
  • Esto es especialmente importante cuando el ID se transmite de forma verbal

Casos existentes

• Crockford's Base32: decodifica los caracteres ambiguos como el mismo valor y también toma en cuenta posibles palabrotas accidentales
• Open Location Code: usa el conjunto de caracteres 23456789CFGHJMPQRVWX. Además de evitar ambigüedad visual, también busca evitar la formación de palabras en idiomas comunes. Aun así, incluye 6/G y 9/Q.

Opinión de GN⁺

• Al generar ID, se debe priorizar la usabilidad y la legibilidad. Esto es aún más importante si con frecuencia el ID debe transmitirse verbalmente o anotarse a mano.
• Es importante elegir un conjunto de caracteres que minimice la ambigüedad visual, encontrando al mismo tiempo un equilibrio adecuado entre la longitud del ID y la cantidad de combinaciones posibles.
• Además, como pueden surgir problemas inesperados al integrarse con sistemas de terceros, hay que decidir con cuidado si distinguir o no entre mayúsculas y minúsculas.
• También hacen falta consideraciones adicionales, como excluir ciertas combinaciones de caracteres en la lógica de generación del ID o evitar caracteres con pronunciación parecida.
• Tomar como referencia casos como Crockford's Base32 u Open Location Code es una buena forma de diseñar el conjunto de caracteres óptimo según los requisitos del proyecto.

[roxie]

Esto también se ve bien: https://stackoverflow.com/a/58098360/8556340

[roxie]

Es realmente asombroso que incluso hayan tenido en cuenta la pronunciación.

[GN⁺]

Opinión de Hacker News

• Existe un caso real en producción donde se usaron números de serie con caracteres ambiguos en millones de dispositivos, lo que causó grandes dificultades para soporte al cliente. Fue una experiencia de pesadilla generar variantes de errores tipográficos con expresiones regulares y compararlas con la base de datos para inferir el número de serie real.
• Hay que usar distintos métodos de codificación según el usuario. Base32 es adecuado porque tiene un conjunto de caracteres claro, y al transmitirlo verbalmente conviene usar representaciones con listas de palabras (por ejemplo, "TIDE ITCH SLOW REIN RULE MOT"). Aun así, hay trampas como modismos, homófonos y dialectos, así que no conviene crear una lista propia de palabras.
• Hubo una vez que llegaron solicitudes de soporte inesperadas por un módulo de operaciones en bases arbitrarias subido en broma a CPAN (Math::Fleximal). La causa fue que alguien usó en producción un código de demostración que convertía hexadecimal en un código alfanumérico.
• En la pantalla de ingreso de números de serie de DLC de Nintendo Switch, se mejora la UX deshabilitando las teclas de caracteres ambiguos.
• También conviene evitar caracteres que son difíciles de distinguir cuando se escriben a mano. En particular, '7' y '1' se confunden con facilidad.
• Si se usan mayúsculas y minúsculas a la vez, más adelante puede haber sorpresas por sistemas o protocolos que no distinguen entre ambas. Incluso hay sistemas comerciales que no consideran esto un bug por motivos de comodidad para el usuario.
• Cada vez que se escriben códigos de respaldo de 2FA en papel aparece la ansiedad con ciertos caracteres (o/0, v/u, 5/S, etc.). Para evitarlo, a veces se les agregan adornos a las letras.
• Se elige como contraseña de Wi‑Fi una palabra cotidiana que incluso un niño de tercer grado pueda deletrear correctamente ("vacation").
• KeepassXC mejora mucho la legibilidad al usar colores distintos según el tipo de carácter (mayúsculas, minúsculas, números, símbolos, etc.).
• Las direcciones de Bitcoin usan una codificación Base58 modificada.
• En el artículo, el tipo de letra Arial está mal escrito como Ariel.