tabla - unicode simbolos

¿Por qué no es todo lo que hacemos en Unicode? (17)

Comience con algunas preguntas

Con qué frecuencia...

¿Necesitas escribir una aplicación que se ocupe de algo más que Ascii?
¿Necesitas escribir una aplicación en varios idiomas?
¿Escribes una aplicación que tiene que ser multilingüe desde su primera versión?
¿Has oído que Unicode se usa para representar personajes que no son ascii?
¿Has leído que Unicode es un juego de caracteres? Ese Unicode es una codificación?
¿ves gente confundiendo cadenas de bytes codificadas en UTF-8 y datos Unicode?

¿Conoces la diferencia entre una intercalación y una codificación?

¿Dónde se enteró por primera vez de Unicode?

¿En la escuela? ( ¿en serio? )
¿en el trabajo?
en un blog de moda?

¿Alguna vez, en su juventud , experimentó el traslado de archivos de origen de un sistema en la configuración regional A a un sistema en la configuración regional B, editó un error tipográfico en el sistema B, guardó los archivos, procesó todos los comentarios no relacionados y terminó ... perdiendo mucho tiempo tratando de entender lo que pasó? (¿tu editor mezcló cosas? ¿el compilador? ¿el sistema? ¿el ...?)

¿Acabaste decidiendo que nunca más comentarás tu código usando caracteres que no sean ascii?

Echa un vistazo a lo que se está haciendo en otros lugares

Pitón

¿Mencioné en SO que me encanta Python? ¿No? Bueno, me encanta Python.

Pero hasta Python3.0, su compatibilidad con Unicode es desagradable. Y estaban todos esos programadores novatos, que en ese momento sabían apenas cómo escribir un bucle, obteniendo UnicodeDecodeError y UnicodeEncodeError de la nada cuando trataban de tratar con caracteres no ascii. Bueno, básicamente se traumatizaron con la vida del monstruo Unicode, y conozco a muchos codificadores de Python muy eficientes y experimentados que todavía tienen miedo de la idea de tener que lidiar con datos Unicode.

Y con Python3, hay una clara separación entre Unicode y cadenas de bytes, pero ... mira cuánto problema hay en portar una aplicación desde Python 2.x a Python 3.x si anteriormente no te importaba demasiado la separación / si realmente no entiendes lo que es Unicode

Bases de datos, PHP

¿Conoces un sitio web comercial popular que almacena su texto internacional como Unicode?

Quizás se sorprenda al saber que el backend de Wikipedia no almacena sus datos usando Unicode. Todo el texto está codificado en UTF-8 y se almacena como datos binarios en la Base de datos.

Una cuestión clave aquí es cómo ordenar los datos de texto si los almacena como puntos de código Unicode. Aquí vienen las intercalaciones Unicode, que definen un orden de clasificación en los puntos de código Unicode. Pero el soporte adecuado para colaciones en Bases de datos falta / está en desarrollo activo. (Probablemente también haya muchos problemas de rendimiento. - IANADBA) Además, todavía no existe un estándar ampliamente aceptado para las intercalaciones: para algunos idiomas, las personas no acuerdan cómo se deben clasificar las palabras / letras / grupos de palabras.

¿Has oído hablar de la normalización Unicode ? (Básicamente, debe convertir sus datos Unicode en una representación canónica antes de almacenarlos) Por supuesto, es fundamental para el almacenamiento de la base de datos o las comparaciones locales. Pero PHP, por ejemplo, solo proporciona soporte para la normalización desde 5.2.4, que salió en agosto de 2007.

Y, de hecho, PHP aún no es totalmente compatible con Unicode. Tendremos que esperar PHP6 para obtener funciones compatibles con Unicode en todas partes.

Entonces, ¿por qué no todo lo que hacemos en Unicode?

Algunas personas no necesitan Unicode.
Algunas personas no les importa.
Algunas personas no entienden que necesitarán soporte Unicode más adelante.
Algunas personas no entienden Unicode.
Para algunos otros, Unicode es un poco como accesibilidad para webapps: empiezas sin, y agregarás soporte para eso más tarde
Una gran cantidad de bibliotecas / idiomas / aplicaciones populares carecen de la compatibilidad adecuada y completa con Unicode, por no mencionar problemas de intercalación y normalización. Y hasta que todos los elementos de su pila de desarrollo sean totalmente compatibles con Unicode, no podrá escribir una aplicación Unicode limpia.

Internet claramente ayuda a difundir la tendencia Unicode. Y es algo bueno Iniciativas como los cambios bruscos de Python3 ayudan a educar a las personas sobre el tema. Pero tendremos que esperar pacientemente un poco más para ver Unicode en todas partes y los nuevos programadores usan instintivamente Unicode en lugar de Strings, donde es importante.

Para la anécdota, debido a que FedEx aparentemente no admite direcciones internacionales, todos los estudiantes de Google Summer of Code ''09 recibieron una solicitud de Google para proporcionar un nombre y una dirección de envío solo para Ascii. Si crees que la mayoría de los actores empresariales entienden lo que está detrás del soporte de Unicode, simplemente estás equivocado. FedEx no entiende, y a sus clientes realmente no les importa. Todavía.

Dado que Unicode ha existido durante 18 años , ¿por qué todavía hay aplicaciones que no tienen soporte Unicode? Incluso mis experiencias con algunos sistemas operativos y Unicode han sido dolorosas por decir lo menos. Como Joel Spolsky señaló en 2003, no es tan difícil. Entonces, ¿cuál es el problema? ¿Por qué no podemos hacerlo juntos?

Debido a la inercia causada por C ++. Tenía (tenía) soporte Unicode horrible y arrastró a los desarrolladores.

Debido a que en el 99% de las aplicaciones, la compatibilidad con Unicode no es una casilla de verificación en la matriz de comparación de productos del cliente.

Agregar a la ecuación:

Se necesita un esfuerzo consciente con casi ningún beneficio visible.
Muchos programadores le tienen miedo o no lo entienden.
La gerencia REALMENTE no lo entiende o no le importa, al menos no hasta que un cliente esté gritando al respecto.
El equipo de prueba no está probando el cumplimiento de Unicode.
"No localizamos la interfaz de usuario, por lo que los que no hablan inglés no la utilizarán de todos modos".

Es sencillo. Debido a que solo tenemos caracteres ASCII en nuestros teclados, ¿por qué nos encontraríamos o nos preocuparíamos por personajes que no fueran esos? No es tanto una actitud como lo que sucede cuando un programador nunca ha tenido que pensar sobre este tema, o nunca lo ha encontrado, tal vez ni siquiera sabe qué es unicode.

editar: Dicho de otra manera, Unicode es algo en lo que tienes que pensar, y pensar no es algo que la mayoría de la gente esté interesada en hacer, incluso los programadores.

La disponibilidad generalizada de herramientas de desarrollo para trabajar con Unicode puede ser un evento más reciente de lo que usted supone. Trabajar con Unicode fue, hasta hace pocos años, una dolorosa tarea de conversión entre formatos de caracteres y lidiar con implementaciones incompletas o defectuosas. Usted dice que no es tan difícil, y que a medida que las herramientas mejoran, se vuelve cada vez más cierto, pero hay muchas maneras de tropezar, a menos que los buenos idiomas y bibliotecas oculten los detalles. Demonios, solo cortar y pegar caracteres Unicode podría ser una proposición cuestionable hace unos años. La educación de los desarrolladores también tomó algo de tiempo, y todavía se ve que las personas cometen una tonelada de errores realmente básicos.

El estándar Unicode pesa probablemente diez libras. Incluso una visión general de la misma tendría que discutir las distinciones sutiles entre caracteres, glifos, puntos de código, etc. Ahora piense en ASCII. Son 128 caracteres. Puedo explicarle todo a alguien que sepa binario en aproximadamente 5 minutos.

Creo que casi todos los programas deberían estar escritos con soporte total de Unicode en estos días, pero ha sido un largo camino para lograr un juego de caracteres verdaderamente internacional con codificación para adaptarse a una variedad de propósitos, y aún no ha terminado.

Más gastos generales, requisitos de espacio.

Pereza, ignorancia.

Personalmente, no me gusta cómo ciertos formatos de Unicode lo rompen, por lo que ya no se puede hacer la cadena [3] para obtener el tercer carácter. Claro que podría abstraerse, pero imagine cuánto más lento sería un gran proyecto con cadenas, como GCC, si tuviera que atravesar una cadena para descubrir el enésimo carácter. La única opción es el almacenamiento en memoria caché donde están las posiciones "útiles" e incluso entonces es lento, y en algunos formatos ahora está tomando 5 buenos bytes por carácter. Para mí, eso es simplemente ridículo.

Porque UTF-16 se hizo popular antes de UTF-8 y UTF-16 es un cerdo con el que trabajar. En mi humilde opinión

Probablemente porque la gente está acostumbrada a ASCII y mucha programación es realizada por hablantes nativos de inglés.

OMI, es una función del hábito colectivo, en lugar de la elección consciente.

Sospecho que es porque el software tiene raíces tan fuertes en el oeste. UTF-8 es un formato agradable y compacto si vives en Estados Unidos. Pero no hace tanto calor si vives en Asia. ;)

Todos los sistemas operativos hasta hace muy poco tiempo se construyeron sobre la suposición de que un personaje era un byte. Sus API se construyeron así, las herramientas se construyeron así, los idiomas se construyeron así.

Sí, sería mucho mejor si todo lo que escribí ya fuera ... ¿eh ... UTF-8? UTF-16? UTF-7? UTF-32? Err ... mmm ... Parece que lo que sea que elija, le molestará a alguien. Y, de hecho, esa es la verdad.

Si elige UTF-16, todos sus datos, como en el caso de prácticamente toda la economía del mundo occidental, dejan de leerse a la perfección, ya que pierde la compatibilidad con ASCII. Además, un byte deja de ser un personaje, lo que rompe seriamente las suposiciones sobre las cuales se basa el software de hoy. Además, algunos países no aceptan UTF-16. Ahora, si elige CUALQUIER codificación de longitud variable, rompe algunas premisas básicas de muchos programas, como no tener que recorrer una cadena para encontrar el enésimo carácter, de poder leer una cadena desde cualquier punto de la misma.

Y, luego UTF-32 ... bueno, eso son cuatro bytes. ¿Cuál fue el tamaño promedio del disco duro o el tamaño de la memoria, pero hace 10 años? ¡UTF-32 era demasiado grande!

Entonces, la única solución es cambiar todo: software, utilidades, sistemas operativos, idiomas, herramientas, al mismo tiempo, para ser consciente. Bien. Buena suerte con "al mismo tiempo".

Y si no podemos hacer todo al mismo tiempo, siempre debemos estar atentos a cosas que no se han podido resolver. Lo que causa un círculo vicioso.

Es más fácil para aplicaciones de usuario final que para middleware o software básico, y algunos nuevos lenguajes se están creando de esa manera. Pero ... todavía usamos las bibliotecas de Fortran escritas en los años 60. Ese legado, no va a desaparecer.

Tradición y actitud ASCII y las computadoras son tristemente sinónimos para muchas personas.

Sin embargo, sería ingenuo pensar que el rol de Unicode, es solo una cuestión de lenguas exóticas de Eurasia y otras partes del mundo. Una codificación de texto enriquecido tiene mucho significado para llevar incluso a un texto en inglés "simple". Mire en algún libro en algún momento.

Un gran factor es el soporte del lenguaje de programación, la mayoría de los cuales usan un conjunto de caracteres que se ajusta en 8 bits (como ASCII) como el predeterminado para las cadenas. La clase String de Java usa UTF-16, y hay otras que admiten variantes de Unicode, pero muchos idiomas optan por la simplicidad. El espacio es tan trivial de preocupación en estos días que los codificadores que se aferran a cadenas "eficientes en el espacio" deberían ser abofeteados. La mayoría de las personas simplemente no se ejecuta en dispositivos integrados, e incluso dispositivos como teléfonos celulares (la gran ola informática del futuro cercano) pueden manejar fácilmente conjuntos de caracteres de 16 bits.

Otro factor es que muchos programas están escritos solo para ejecutarse en inglés, y los desarrolladores (1) no planifican (ni siquiera saben cómo) para localizar su código para múltiples idiomas, y (2) a menudo ni siquiera piensan en manejo de entrada en idiomas no romanos. El inglés es el idioma natural dominante que hablan los programadores (al menos, para comunicarse entre ellos) y en gran medida, se ha trasladado al software que producimos. Sin embargo, la apatía y / o la ignorancia ciertamente no pueden durar para siempre ... Dado que el mercado de telefonía móvil en Asia eclipsa completamente a la mayoría del resto del mundo, los programadores tendrán que lidiar con Unicode muy pronto, ya sea te guste o no.

Por lo que vale, no creo que la complejidad del estándar Unicode no sea un factor tan importante para los programadores, sino más bien para aquellos que deben implementar el soporte de idiomas. Cuando se programa en un idioma donde el trabajo duro ya se ha hecho, hay menos razones para no usar las herramientas a mano. C''est la vie, viejos hábitos mueren duro.

Unicode requiere más trabajo (pensar), por lo general solo se le paga por lo que se requiere, así que elige la opción más rápida y menos complicada.

Bueno, eso es desde mi punto de vista. Supongo que si esperas que el código use std::wstring hw(L"hello world") tienes que explicar cómo funciona todo que para imprimir wstring necesitas wcout : std::wcout << hw << std::endl; (Creo), (pero endl parece estar bien ...) ... me parece que es más trabajo, por supuesto, si estuviera escribiendo una aplicación internacional, tendría que invertir en averiguarlo, pero hasta entonces no lo hago (como Sospecho que la mayoría de los desarrolladores).

Supongo que esto se remonta al dinero, el tiempo es dinero.

Yo diría que hay principalmente dos razones. El primero es simplemente que el soporte Unicode de sus herramientas simplemente no está preparado. C ++ aún no tiene soporte para Unicode y no lo obtendrá hasta la próxima revisión estándar, que demorará tal vez un año o dos en completarse y luego otros cinco o diez años en ser de uso generalizado. Muchos otros lenguajes no son mucho mejores e incluso si finalmente tiene soporte Unicode, podría ser aún más engorroso usar cadenas simples ASCII.

La segunda razón es, en parte, lo que está causando el primer problema, Unicode es difícil, no es ciencia espacial, pero le da un montón de problemas que nunca tuvo que tratar en ASCII. Con ASCII tenía un one byte == one glyph claro one byte == one glyph relación de one byte == one glyph , podía abordar el carácter n-ésimo de una cadena por una simple str[N] , podía simplemente almacenar todos los caracteres de todo el conjunto en la memoria, y así sucesivamente. Con Unicode ya no puedes hacer eso, tienes que lidiar con las diferentes formas en que Unicode está codificado (UTF-8, UTF-16, ...), marcas de orden de bytes, errores de decodificación, muchas fuentes que tienen solo un subconjunto de caracteres que necesitaría para una compatibilidad total con Unicode, más glifos que desea almacenar en la memoria en un momento determinado, etc.

ASCII podría entenderse simplemente mirando una tabla ASCII sin más documentación, con Unicode que simplemente ya no es el caso.

Muchos desarrolladores de productos no consideran que sus aplicaciones se utilicen en Asia u otras regiones donde Unicode es un requisito.
La conversión de aplicaciones existentes a Unicode es costosa y, generalmente, impulsada por las oportunidades de venta.
Muchas empresas tienen productos mantenidos en sistemas heredados y la migración a Unicode significa una plataforma de desarrollo totalmente nueva.
Te sorprendería saber cuántos desarrolladores no comprenden las implicaciones completas de Unicode en un entorno multilingüe. No se trata solo de utilizar cadenas anchas.

En resumen, costo