character-encoding - son - la contraseña debe tener de 6 a 12 caracteres y contener una combinación de caracteres y números.
¿Cuáles son todos los caracteres permitidos para los nombres de las personas? (10)
¿Qué haces cuando tienes "El artista antes conocido como Prince"? Ese símbolo que usó no es un personaje en el conjunto Unicode (AFAIK).
Es una cuestión de ligereza, pero al mismo tiempo, los nombres son un concepto bastante amplio que no se presta bien a un formato estructurado. En este caso, algo de forma libre podría ser lo más apropiado.
Están los caracteres estándar AZ, az, pero también hay guiones, guiones, comillas, etc.
Además, hay todos los personajes internacionales, como diéresis, etc.
Entonces, para un sistema basado en inglés, ¿cuál es el conjunto completo? ¿Qué hay de los conjuntos para otros idiomas? ¿Qué hay de UTF8, UTF16, etc.?
Pregunta adicional: ¿Cuántos campos de nombre se necesitan y cuáles son sus longitudes máximas?
EDITAR: Definitivamente hay dos tipos diferentes de personajes involucrados en los nombres de las personas, los que están allí como parte del contexto y los que están ahí por razones estructurales. No quiero limitar o interferir con los personajes de contexto, pero sí tengo que ocuparme de los estructurales.
Por ejemplo, tenía un nombre que estaba separado por un punto de partida, pero era difícil distinguirlo del carácter menos. Para hacer que el sistema sea más fácil de buscar, quiero tomar los cinco tipos diferentes de guiones y asignarlos a un único carácter (menos), de esa forma el buscador no necesita saber específicamente qué símbolo se ingresó inicialmente.
El problema existe para guiones, probablemente también comillas, pero también ¿cuántos otros símbolos?
Cualquier carácter que pueda representarse con cualquier múltiplo de ocho bits (mayor que cero) es un carácter posible para el nombre de una persona. Las longitudes de ambos nombres y codificaciones son arbitrarias, por lo que no se debe considerar ningún límite superior.
Solo asegúrate de desinfectar las entradas de tu base de datos para que las tablas de Drop Bobby no te atrapen.
Dependiendo de la complejidad de la estructura de tu nombre, pude ver:
- Nombre de pila
- Medio inicial / segundo nombre
- Apellido
- Sufijo (Jr. Sr. II, III, IV, etc.)
- Prefijo (Sr., Sra., Sra., Etc.)
En el tema de los campos de nombre, la respuesta INCORRECTA es el nombre, la inicial del segundo nombre, el apellido, etc. por muchas razones.
Muchas personas son conocidas por su segundo nombre, y formalmente usan un primer formato inicial, segundo nombre y apellido.
En algunas culturas, el apellido es el primer nombre, y el nombre de pila es el apellido.
Múltiples nombres de pila primero y / o medio es cada vez más común. Como señala @Dour High Arch, el otro extremo son las personas con solo una palabra en su nombre.
En una base de datos orientada a objetos, debe almacenar un objeto Name con métodos para devolver un estilo de directorio o un nombre de estilo de firma; y la tienda de respaldo contendría los datos necesarios para respaldar esos métodos.
Todavía no he visto un modelo de base de datos relacional que mejore el modelo de dos cadenas de longitud variable para nombres de estilo de directorio y estilo de firma.
Incluir en una lista blanca los caracteres que podrían aparecer en el nombre de una persona es el camino equivocado, si me preguntas. Claro, [A-Za-z] es un buen punto de partida, pero, como dijiste, tienes problemas con los nombres "europeos". Entonces mapea todas las diéresis, circunflejos y esas. ¿Y los nombres chinos? ¿Japonés? ¿Indio? ¿Hebreo? Estás entrando en una batalla contra las turbinas de viento.
Si absolutamente debes verificar la validez del nombre de alguien, te sugiero hacer una lista negra modesta de ciertos personajes. Los apoyos, los caracteres matemáticos, algunos signos de puntuación y otros podrían ser seguros para ignorar. Pero sería precavido, si fuera tú.
Sería mejor simplemente aceptar lo que ingrese. UTF-16 debería ser el juego de caracteres excesivo de hoy, que debería ser adecuado para los próximos años.
Editar: en cuanto a su pregunta sobre la longitud del nombre y la cantidad de nombres. Si realmente quieres que la gente escriba sus nombres reales y completos, supongo que la única respuesta infalible a ambas preguntas sería "infinito". No poder sacar ningún ejemplo real para los seres humanos, pero seguramente hay ejemplos análogos para los humanos como el nombre nativo de la ciudad de Bangkok .
UTF-8 debería ser lo suficientemente bueno, en cuanto a los campos de nombre, querrás como mínimo un nombre y apellido.
Realmente depende de para qué se usará la aplicación.
Claro, en teoría es genial si permites que se usen todos los guiones de la tierra verde de Dios, pero si el DB también es utilizado por el personal de soporte, ¿podrán manejar nombres en japonés, hebreo y tailandés? ¿Puedes imprimir, si se usa para imprimir etiquetas postales?
Puede agregar un campo adicional "Transcripción latina", pero IMO está realmente bien restringirlo a caracteres ISO-8859-1. Las personas que no usan caracteres latinos están acostumbradas a tener que usar una transcripción que no usan. Me importa más, a menos que sean nacionalistas incondicionales.
Estoy creando software para escuelas de manejo en EE. UU., Así que para mí lo más importante es lo que el DMV estatal acepta como nombre propio en una licencia de conducir. En mi caso, causar problemas para permitir nombres más allá de lo que permite el DMV, incluso si tales nombres eran legales porque el mismo nombre debe ser utilizado más adelante para una licencia de conducir.
De , todavía no había confirmado la respuesta que necesitaba. Y sé que en mi estado (California) están usando AS400 con un software probablemente escrito en COBOL, y según mi leal saber y entender, solo admiten un conjunto de caracteres de 8 bits. (¿Es EBCDIC?) De todos modos ... Uf.
Entonces, llamé al DMV de California ... Efectivamente, su sistema permite AZ y espacios y absolutamente nada más. Ni siquiera se permiten guiones: los guiones se reemplazan por espacios. De hecho, aparentemente solo es difícil, solo usan mayúsculas. Y nombres como "O''Malley" deben reemplazarse por OMALLEY.
Déjalo al gobierno. Debo decir que estoy emocionado de no ser un desarrollador que trabaja para el DMV. (Aunque realmente podría usar ese tipo de salario).
Hay un buen artículo del W3C llamado Nombres personales en todo el mundo que explica los problemas (y las posibles soluciones) bastante bien (originalmente fue una publicación de dos partes del blog de Richard Ishida: parte 1 y parte 2 )
Personalmente, diría que es compatible con todos los caracteres Unicode imprimibles y que, para estar seguro, proporciona un solo "nombre" de campo que contenga el nombre completo y formateado. De esta manera puedes almacenar prácticamente cualquier forma de nombre. Es posible que necesite un almacenamiento más estructurado, pero no espere poder almacenar cada combinación de forma estructurada, ya que simplemente hay demasiadas diferentes.
No creo que haya una respuesta definitiva. Después de todo, algunas personas tienen nombres que ni siquiera se pueden expresar en UTF-16 ...
Hay algunas personas raras, que darán a sus hijos el nombre más loco, incluyendo poner signos de puntuación extraños, acentos que no existen en su propio idioma, etc.
Sin embargo, puede colocar restricciones arbitrarias en su base de datos. Si lo desea, puede insistir en los nombres ASCII de 7 bits. Es un poco grosero para los usuarios, pero vivirán con eso. Ciertamente facilita la búsqueda.
La hija de mi colega se llama Amélie. Pero incluso algunos (¡no todos!) Los sitios web oficiales del gobierno británico ("Por favor, ingrese el nombre exactamente como se muestra en el certificado de nacimiento") no aceptarán el Unicode, por lo que tiene que usar ''Amelie''.