language agnostic - tipos - ¿Todavía dominas Unicode?

utf 8 en xml (4)

Hace casi 5 años, Joel Spolsky escribió este artículo, "El mínimo absoluto que todo desarrollador de software debe saber absolutamente sobre Unicode y conjuntos de caracteres (¡sin excusas!)" .

Al igual que 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.

Entonces, para mi beneficio (y creo que para muchos otros), ¿puedo obtener información de personas sobre lo siguiente?

Cómo "superar" a ASCII de una vez por todas
Orientación fundamental cuando se trabaja con Unicode.
Libros (recomendados) y sitios web (recientes) 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 recibir información sobre Unicode en .NET Framework. Por supuesto, esto no debería detener a nadie con un fondo diferente de comentar.

Actualización: vea esta pregunta relacionada también en StackOverflow previamente.

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

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

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

Abrace a Unicode, no lo luche; es probable que 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 esté basada 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 que lo es), suponga que su manejo de 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.
Ve a Amazon o a algún lado y compra la última revisión del estándar impreso Unicode; contiene bastante bien todo lo que necesitas saber.
Dedica algo de tiempo a hurgar en el sitio web de Unicode y aprender cómo funcionan los gráficos de códigos.
Si vas a tener que hacer un trabajo serio con idiomas asiáticos, ve 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 vas a tener que ensuciarte con los datos, ve a asistir a una de las conferencias 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.

Pasé un tiempo trabajando con el software del motor de búsqueda: no creería cuántos sitios web publican contenido con encabezados HTTP o metaetiquetas que mienten 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 haya combatido algunos de estos tipos de problemas, comenzará a tomar muy en serio la codificación de caracteres adecuada de los datos que produce.

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 minicar cadenas 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.

.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 (sé con certeza 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 un poco confusos 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.

Entonces, 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() :(