Tu apellido contiene caracteres no válidos (2010)
Los sistemas de software rechazan o destrozan habitualmente nombres personales perfectamente válidos, desde monónimos de una sola letra y apellidos cortos hasta nombres con guiones, diacríticos, escrituras no latinas o capitalización poco habitual. Los comentaristas comparten abundantes fallos del mundo real —billetes de avión, accesos bancarios, documentos gubernamentales, sitios de hoteles y mainframes heredados— que obligan a las personas a escribir mal o truncar su propio nombre, o a ser tratadas como fraudulentas. Un tema recurrente es que las reglas de validación rígidas y las suposiciones centradas en ASCII no solo reflejan un mal diseño técnico (por ejemplo, la falta de compatibilidad con Unicode), sino que además trasladan la culpa a los usuarios en lugar de reconocer las limitaciones del sistema.
Suposiciones y falsedades sobre los nombres
- Muchos ejemplos muestran que las suposiciones habituales del software son erróneas: las personas pueden tener un solo nombre, varios apellidos, ningún apellido, monónimos, nombres muy cortos (1–2 letras) o varios “nombres completos”.
- Las divisiones rígidas entre nombre y apellido, el orden impuesto y las reglas de longitud mínima fallan con frecuencia.
- Los sistemas a menudo insisten en que el nombre introducido “debe coincidir con el documento de identidad” mientras, al mismo tiempo, rechazan caracteres que sí aparecen en esos documentos.
Limitaciones técnicas: codificaciones y validación
- Los nombres con acentos, diacríticos, ß, ø, ć, diéresis y escrituras no latinas suelen romper formularios, bases de datos y sistemas posteriores.
- El frontend puede aceptar Unicode, pero el backend truncar, recodificar o rechazar silenciosamente, lo que provoca correo perdido, registros desajustados o fallos de inicio de sesión.
- Las codificaciones heredadas (EBCDIC, antiguas páginas de código de 8 bits, variantes de ancho medio/completo en japonés) y las restricciones de la era de los mainframes siguen impulsando reglas de “solo ASCII”.
- Algunos discuten si los sistemas deberían permitir casi todo Unicode y simplemente eliminar caracteres de control/separadores de línea; otros señalan que la integración con sistemas no Unicode o externos (correo postal, aerolíneas, gobierno) complica esto.
Aerolíneas, bancos y sistemas gubernamentales
- Las aerolíneas son infractoras frecuentes: rechazan ciertos caracteres, truncan nombres, manejan mal la transliteración (por ejemplo, diéresis → ue frente a u, ø → o frente a oe) o tratan subcadenas como obscenidades (problemas al estilo Scunthorpe).
- Las comprobaciones de seguridad a menudo dependen del sentido común humano para salvar discrepancias entre el billete, el pasaporte y las limitaciones del backend; a veces esto falla y crea grandes complicaciones.
- Los bancos, las oficinas de impuestos y los registros oficiales suelen eliminar diacríticos, destrozar espacios/guiones o imponer campos demasiado cortos.
Convenciones culturales y legales de nombres
- Varias publicaciones describen reglas específicas por país: sufijos de género obligatorios, conjuntos de caracteres restringidos para nombres legales y representaciones oficiales solo en kanji o katakana.
- Estas normas chocan con escrituras extranjeras, segundos nombres y diferentes convenciones de orden, especialmente en contextos transfronterizos.
Soluciones improvisadas de los usuarios y estrategias de adaptación
- Muchas personas “anglicanizan” o convierten sus nombres a ASCII, eliminan puntuación o segundos nombres, o mantienen varias grafías (para aerolíneas, bancos, cafeterías).
- Algunos registran alias o formas legales abreviadas específicamente para evitar fallos del software.
- Una frustración recurrente no es solo el fallo técnico, sino que los sistemas y el personal insinúen que el nombre de la persona es “inválido”, en lugar de reconocer las limitaciones del software.