Cómo evitar los navegadores Normalización Unicode al enviar un formulario con Unicode

Question

Al representar el siguiente texto Unicode en HTML, resulta que el navegador (Google Chrome) hace alguna forma de Unicode normalization cuando se vuelven a publicar los datos en el servidor. (Probablemente en Form C).

Pero cuando se utiliza texto en hebreo bíblico (בְּרִיךְ הוּא), esto puede romper fácilmente el texto, como se indica en here (página 9).

¿Hay alguna forma de evitar la normalización de texto automático de los navegadores?

me escribió una entrada de blog que describen con más detalle el tema que estoy frente a: http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text

Answer 1

Esto parece ser una característica de un/error en navegadores WebKit (Chrome, Safari); normalizan los datos de formulario a NFC, lo que significa, entre otras cosas, reordenar marcas de combinación consecutivas a un orden "canónico". Esto era nuevo para mí, y malas noticias en casos como este. Lo peor es que diferentes navegadores se comportan de manera diferente.

Utilizando una versión simplificada de su caso de prueba http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text (utilizando un script del lado del servidor que solo hace eco de los datos brutos), noté que Chrome y Safari reordenaron las marcas diacríticas en U + 05E9 U + 05C1 U + 05B5 (SHIN , SHIN DOT, TSERE), mientras que IE, Firefox y Opera no.

También realicé una prueba simple con la letra latina e seguida de la combinación de la diéresis U + 0308. Los navegadores WebKit lo convierten en el único carácter ë, según las reglas de NFC, mientras que otros navegadores mantienen intacto el par de caracteres.

Esto parece ser una característica intencional, desde 2006; https://bugs.webkit.org/show_bug.cgi?id=8769 orgullosamente anuncia esto como parte de una corrección de errores! Esto podría explicar el estado del documento de política del W3C; su versión actual es WebKit-mente en este tema, pero otros proveedores de navegadores no están interesados ​​o se oponen deliberadamente a la idea de "normalización temprana".

No creo que haya una forma de evitar esto. Pero podría advertir a los usuarios contra el uso de Chrome y Safari. Incluso podría usar un campo oculto que contenga un caso de problema simple, luego verifique si el servidor fue transmitido tal como está, y dígale al usuario que cambie el navegador si no lo está.

Reparar el orden del lado del servidor no es simple, porque las rutinas de normalización comunes aparentemente no admiten la orden necesaria. Puede normalizar a la forma completamente descompuesta (NFD), luego reordenar las marcas de combinación usando su propio código para tal fin. Tal vez más simple y seguro, podría ejecutar una rutina de reemplazo ad hoc que reemplace las secuencias de combinar marcas con otras secuencias. Esto sería más seguro porque no afectaría a los caracteres que no sean los que desea afectar, mientras que NFD descompone las letras latinas con signos diacríticos, entre otras cosas.

Según los principios Unicode, las cadenas canónicamente equivalentes (por ejemplo, que difieren solo en el orden de las marcas diacríticas consecutivas) son representaciones diferentes de los mismos datos pero distintas como secuencias de caracteres Unicode (puntos de código); no se espera que difieran en la presentación, pero pueden, y a menudo lo hacen. En general, no debe esperar que los programas consideren cadenas canónicamente equivalentes como diferentes, aunque los programas pueden marcar la diferencia. Ver Unicode Normalization FAQ.

La entrada de preguntas frecuentes afirma que los problemas del hebreo bíblico se han resuelto con la introducción de COMBINING GRAPHEME JOINER. Aunque impide el reordenamiento en Chrome, es un método torpe, y puede arruinar el procesamiento (lo hace en los navegadores web, las marcas diacríticas pueden quedar mal ubicadas).

Answer 2

Puede manipular el texto en el lado del cliente antes de enviarlo. Si inserta una Combinación de Grafema Joiner, puede insertarla a través de JavaScript.

Como punto de miradas, pero aquí hay un jsFiddle que recibe la carta de caracteres por carta (probado en Safari y no normaliza el texto): http://jsfiddle.net/TmtnA/

Answer 3

Es posible evitar la normalización cadena mediante el envío de un Uint8Array en lugar de una cadena. En primer lugar, obtener los datos UTF-8 de la cadena como un Uint8Array como se describe here por @Moshev:

function utf8AbFromStr(str) { 
    var strUtf8 = unescape(encodeURIComponent(str)); 
    var ab = new Uint8Array(strUtf8.length); 
    for (var i = 0; i < strUtf8.length; i++) { 
     ab[i] = strUtf8.charCodeAt(i); 
    } 
    return ab; 
} 

, puedes publicarla que Uint8Array con XHR liso o su biblioteca favorita Ajax. Si está utilizando jQuery, tenga en cuenta que debe especificar processData: false para evitar que jQuery intente realizar una cadena y deshacer todo su trabajo.