¿Lista blanca o saneamiento de lista negra para comentarios internacionales?

Por eso existe la clase de caracteres [[: alnum:]]; incluye los caracteres que se consideran alfanuméricos válidos en la configuración regional activa actualmente. Por supuesto, eso no funciona bien en un servidor web en los EE. UU. Cuando alguien en Egipto está tratando de proporcionar información a través de un formulario, y no funciona con la puntuación. Pero tampoco incluye espacios, y eso puede ser completamente irrelevante.

--- Editar --- Basándose en la respuesta de Mark a continuación y utilizando enlace como referencia, también se podría usar [\p{L}\p{N}] en lugar del carácter alnum clase en la mayoría de las implementaciones de expresiones regulares para reconocer "todas" letras / números Unicode en todas las configuraciones regionales conocidas por el motor de expresiones regulares en uso. Básicamente, la elección depende de si la aplicación que realiza la comparación sabe de qué configuración regional proviene la entrada o no. Y, por supuesto, si se espera que la entrada sea letras y números, o algo más (los nombres propios a veces contienen puntuación, por ejemplo). :) --- Editar ---

Para responder más directamente a la pregunta, sí, siempre es preferible una lista blanca. Sin embargo, no siempre es práctico. Solo alguien familiarizado con la aplicación específica puede realizar la llamada en cuanto a lo que es realmente práctico.

Suponiendo que esté preguntando esto en el contexto del desarrollo web ...

Puede detectar conjuntos de caracteres apropiados con una simple validación de expresiones regulares. Sin embargo, también puede ser víctima de un teatro de seguridad: el saneamiento de entradas es no la respuesta.

Si está intentando validar para configuraciones regionales específicas y no desea aceptar otras configuraciones regionales, puede elegir las específicas utilizando Regex. Aquí hay un ejemplo:

1. \p{InHan} para caracteres chinos.
2. \p{InArabic} para el árabe
3. \p{InThai} para tailandés

Sin embargo, estoy con O'Rooney aquí: debe aceptar todo (siempre que esté validado: longitud, nulo, formato, lista blanca) y use Prepared Statements con output sanitation .

Advertencias sobre listas blancas basadas en lenguaje

Si insiste en ir con una lista blanca basada en rango de Unicode, tenga en cuenta que aún debe permitir [a-zA-Z0-9] , aunque solo esté aceptando otras configuraciones regionales. En el internet chino, la gente frecuentemente escribe con letras en inglés. Por ejemplo, pueden intentar evadir la censura con caracteres abreviados (solo el texto en wikipedia, pero todavía NSFW ). Muchas personas también utilizan pinyin y los números romanos.

También puede utilizar rangos Unicode , pero cuando esté usando ideogramas / conjuntos de idiomas combinados, como CJK (chino, japonés y coreano; creo que \p{IsHan} es CJK ), se encontrará con muchos problemas de validación.

Si desea excluir por idioma, tendrá problemas con este concepto cuando esté esperando una entrada en japonés, pero en cambio obtenga una entrada en chino, o viceversa. El mismo concepto se aplica con coreano contra chino o japonés. Deberá encontrar los rangos Unicode apropiados, pero tenga en cuenta que algunos idiomas se superponen ocasionalmente: chino ( Hanzi ) y japonés (< a href="https://en.wikipedia.org/wiki/Kanji"> Kanji ) comparte algunos caracteres .

Debido a que le preocupa la entrada aceptada, suena como si estuviera buscando un saneamiento de entrada. Este es el enfoque equivocado. Usted debe no ser la entrada de "desinfección" que se incluye en una base de datos. La lista blanca está bien (valores aceptables, por ejemplo).

Desinfección y Validación Los comentarios son dos cosas diferentes. ¿Cuál es la diferencia?

1. La entrada de desinfección podría tener este aspecto: stripApostrophesFromString(input);
2. La validación de entrada podría tener este aspecto: if (input != null && input.Length == acceptableNumber && regexFormatIsValid(input) && isWithinAcceptableRanges(input)) { } else { }

Para la validación de conjuntos de caracteres, una variación de las expresiones regulares enumeradas podría ser suficiente, pero no validará la longitud, el formato, etc. Si le preocupa la inyección de SQL (y debería be) , deberías usar prepared statements con output sanitation .

El saneamiento de salida consiste esencialmente en convertir caracteres erróneos, como etiquetas de script, a su entidad HTML equivalente. Por ejemplo, < se convierte en < , y > se convierte en > .

Nuestra respuesta es que para una aplicación verdaderamente internacional, en comentarios generales como los nombres de personas, debes aceptar todo y codificarlo en el momento de la visualización. Es cierto que (hasta cierto punto) le pasa el problema a la persona que escribe el algoritmo de codificación.

Sin embargo, si tiene una entrada que es algo específico, como una placa de matrícula de un vehículo o un código de identificación comercial, entonces debe validarlo con esas reglas, independientemente de que sea una aplicación internacional. Una vez más, una advertencia adicional es que esas reglas podrían ser difíciles de definir, por ejemplo, los símbolos de las placas de matrícula variarían según el país.

(Editar) Por qué prefiero la codificación en lugar de la validación:

En el momento de la validación, esos datos podrían ir potencialmente a cualquier lugar: un archivo de texto CSV, una consulta SQL, una página web, una configuración. No sabes, y no puedes saber, qué son los personajes riesgosos.

En el momento de la codificación, por definición, usted sabe a dónde se dirigen los datos, por lo que puede codificar definitivamente los caracteres de riesgo.