¿Todavía dominas Unicode?

Question

Hace casi 5 años Joel Spolsky escribió este artículo, "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".

Como muchos, lo leí cuidadosamente, dándome cuenta de que ya era hora de que me diera cuenta de este "reemplazo para ASCII". Desafortunadamente, 5 años después siento que he vuelto a caer en algunos malos hábitos en esta área. ¿Tienes?

No escribo muchas aplicaciones específicamente internacionales, sin embargo, he ayudado a compilar muchos sitios web ASP.NET orientados a Internet, así que supongo que eso no es una excusa.

Así que para mi beneficio (y creo que muchos otros) puedo conseguir algunas aportaciones de las personas en lo siguiente:

• Cómo "superar" ASCII de una vez por todas
• orientación fundamental cuando se trabaja con Unicode.
• Libros (recomendados) (recientes) y sitios web en Unicode (para desarrolladores).
• Estado actual de Unicode (5 años después del artículo de Joels)
• Direcciones futuras.

Debo admitir que tengo un fondo .NET y también me gustaría obtener información sobre Unicode en .NET Framework. Por supuesto, esto no debería detener a nadie con un fondo diferente de comentar.

Actualización: Consulte this related question también se solicitó en StackOverflow anteriormente.

Answer 1

Desde que leí el artículo de Joel y algunos otros artículos de I18n siempre estuve atento a la codificación de mis caracteres; Y realmente funciona si lo haces de manera constante. Si trabajas en una empresa donde es estándar usar UTF-8 y todo el mundo sabe esto/funciona, funcionará.

Aquí algunos artículos interesantes (además el artículo de Joel) sobre el tema:

• http://www.tbray.org/ongoing/When/200x/2003/04/06/Unicode
• http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

Una cita del primer artículo; Consejos para usar Unicode:

• Abrazo Unicode, no lo pelee; probablemente sea lo correcto, y si no fuera así, probablemente tendrías que hacerlo de todos modos.
• Dentro de su software, almacene el texto como UTF-8 o UTF-16; es decir, elija uno de los dos y quédese con él.
• Intercambie datos con el mundo exterior utilizando XML siempre que sea posible; esto hace que un montón de problemas potenciales desaparezcan.
• Intenta hacer que tu aplicación se base en navegador en lugar de escribir tu propio cliente; los navegadores se están volviendo realmente buenos manejando los textos del mundo.
• Si está utilizando el código de la biblioteca de otra persona (y por supuesto lo está), suponga que su manejo Unicode está roto hasta que se demuestre que es correcto.
• Si está realizando una búsqueda, intente solucionar los problemas lingüísticos y de manejo de caracteres a alguien que los entienda.
• Vaya a Amazon o en algún otro lugar y compre la última revisión del estándar impreso Unicode; contiene bastante bien todo lo que necesitas saber.
• Dedique un tiempo a hurgar en el sitio web de Unicode y aprender cómo funcionan los gráficos de códigos.
• Si va a tener que hacer un trabajo serio con idiomas asiáticos, vaya a comprar el libro O'Reilly sobre el tema de Ken Lunde.
• Si tiene un Macintosh, agote y tome la herramienta de inspección de fuentes Unicode de Lord Pixel. Totalmente genial.
• Si realmente va a tener que ensuciarse con los datos, vaya a una de las conferencias de Unicode dos veces al año. Todos los expertos van y si no sabes lo que necesitas saber, podrás encontrar a alguien allí que lo sepa.

Answer 2

Pasé un tiempo trabajando con el software del motor de búsqueda: no creo que muchos sitios web publiquen contenido con encabezados HTTP o metaetiquetas que mientan sobre la codificación de las páginas. A menudo, incluso obtendrá un documento que contiene caracteres ISO-8859 y caracteres UTF-8.

Una vez que ha enfrentado algunos de estos tipos de problemas, comienza a tomar muy en serio la codificación de caracteres adecuada de los datos que produce.

Answer 3

Regla de oro: si nunca muerde o mira dentro de una cuerda y en su lugar la trata estrictamente como una masa de datos, estará mucho mejor.

Incluso hacer algo tan simple como dividir palabras o cadenas de minúsculas se vuelve difícil si quieres hacerlo "de la manera Unicode".

Y si quieres hacerlo "de la manera Unicode", necesitarás una biblioteca terriblemente buena. Esto es increíblemente complejo.

Answer 4

.NET Framework usa la codificación predeterminada de Windows para almacenar cadenas, que resulta ser UTF-16. Si no especifica una codificación cuando usa la mayoría de las clases de E/S de texto, escribirá UTF-8 sin BOM y lo leerá primero verificando una BOM y luego asumiendo UTF-8 (estoy seguro de que StreamReader y StreamWriter comportan esto). Esto es bastante seguro para los editores de texto "tontos" que no entenderán una lista de materiales, pero son un poco crudos para los más inteligentes que podrían mostrar UTF-8 o la situación en la que está escribiendo caracteres fuera del rango ASCII estándar.

Normalmente esto es invisible, pero puede levantar la cabeza de maneras interesantes. Ayer estaba trabajando con alguien que estaba usando la serialización de XML para serializar un objeto a una cadena usando un StringWriter, y no podía entender por qué la codificación siempre era UTF-16. Dado que una cadena en la memoria va a ser UTF-16 y es impuesta por .NET, es lo único que podría hacer el marco de serialización XML.

Por lo tanto, cuando estoy escribiendo algo que no es solo una herramienta desechable, especifico una codificación UTF-8 con una lista de materiales. Técnicamente en .NET siempre serás consciente de Unicode accidentalmente, pero solo si tu usuario sabe detectar tu codificación como UTF-8.

Me hace llorar un poco cada vez que veo a alguien preguntar, "¿Cómo obtengo los bytes de una cadena?" y la solución sugerida usa Encoding.ASCII.GetBytes() :(