Acabo de volver a trabajar con mi módulo Perl Encoding::FixLatin para manejar secuencias de bytes UTF-8 demasiado largas y convertirlas a la forma normal más corta.¿Debo convertir cadenas demasiado largas UTF-8 a su forma normal más corta?
Mi pregunta es simplemente "¿es esta una mala idea"?
Varias fuentes (entre ellas this RFC) sugieren que cualquier UTF-8 demasiado largo debe tratarse como un error y rechazarse. Advierten contra las "implementaciones ingenuas" y me dejan con la impresión de que estas cosas son inherentemente inseguras.
Dado que el propósito de mi módulo es limpiar archivos de datos desordenados con codificaciones mixtas y convertirlos en útiles y limpios utf8, esto parece ser una cosa más que puedo limpiar para que la capa de aplicación no tenga que lidiar con eso. Mi código no se ocupa de ningún significado semántico que puedan tener los caracteres resultantes, sino que simplemente los convierte en una forma normalizada.
Me falta algo. ¿Hay algún peligro oculto que no haya considerado?
Me temo que no sigue su lógica .Mi módulo no es una aplicación, es un filtro de datos. No veo cómo hay algo intrínsecamente inseguro en el texto '
No creo que sea una mala idea desde el punto de vista de la seguridad o la usabilidad.
Desde la perspectiva de la seguridad, debe desinfectar la entrada del usuario antes de su uso. Para que pueda ejecutar sus rutinas de limpieza, y luego asegúrese de que los datos no contengan más que/menos que los símbolos
<>antes de que se imprima. También debe asegurarse de llamar a mysql_real_escape_string() antes de insertarlo en la base de datos. Tenga en cuenta que los problemas de codificación del idioma, como GBK vs Latin1, pueden llevar a la inyección sql cuando no está usando mysql_real_escape_string(). (Este nombre de función debe ser bastante similar independientemente de los enlaces de la biblioteca mysql específicos de su plataforma)Sanitizar toda la entrada del usuario generalmente es una idea terrible porque no sabe cómo se usará la variable específica. Por ejemplo, sql injection y xss tienen caracteres de control muy diferentes y la misma sensibilización para ambos a menudo conduce a vulnerabilidades.
Fuente
2010-04-30 22:22:44 rook
No sé si es una mala idea en su escenario, sin embargo, como este tipo de cambio no es biyectivo, puede llevar a la pérdida de datos.
Si ha detectado incorrectamente la codificación de sus datos, puede interpretar los datos como legítimos UTF-8 y cambiarlos en la forma normal más corta. No habrá forma de recuperar más tarde los datos originales.
Como experiencia personal, sé que cuando estas cosas pueden suceder, ellos y usted potencialmente se dan cuenta del error antes de que sea demasiado tarde ...
Fuente
2010-05-03 11:49:11 dodecaplex
Gracias por su respuesta. En realidad, no existe una forma segura de manejar la situación que describe aparte de la conversión de la codificación conocida de un solo byte a UTF-8, en cuyo caso no se encontrarán secuencias demasiado largas. El nicho que ocupa Encoding :: FixLatin es limpiar los datos que contienen caracteres en múltiples codificaciones. La heurística utilizada tiene el potencial de introducir corrupción de datos y la documentación del módulo describe los riesgos. –