lista - ¿Por qué usar Unicode si su programa es solo en inglés?
utf-8 (21)
Así que leí el artículo de Joel y miré a través de SO, y parece que la única razón para cambiar de ASCII a Unicode es para la internacionalización. La compañía para la que trabajo, como política, solo lanzará software en inglés, aunque tengamos clientes en todo el mundo. Dado que todos nuestros clientes son científicos, tienen un inglés lo suficientemente funcional como para usar nuestro software como un hablante no nativo. O eso dice la lógica. Debido a esta política, no es necesario cambiar a Unicode para que sea compatible con otros idiomas.
Sin embargo, estoy empezando un nuevo proyecto y quería usar Unicode (porque eso es lo que se supone que debe hacer un programador responsable, ¿no?). Para hacerlo, tendríamos que comenzar a convertir todas las bibliotecas que hemos escrito en Unicode. Esto no es tarea fácil.
Si la internacionalización de los programas en sí no se considera una razón válida, ¿cómo se justificaría todo el tiempo empleado en la recodificación de bibliotecas y programas para cambiar a Unicode?
La compañía para la que trabajo, ** como política **, solo lanzará software en inglés, aunque tengamos clientes en todo el mundo.
Solo una razón: las políticas cambian y cuando cambian, romperán su código existente. Período.
Diseña para el mal , y tienes la oportunidad de no romper tu código tan pronto. En este caso, utilice Unicode. Me sucedió en un sistema de legado específico del mercado de valores brasileño.
Cuando se usa Unicode, deja la puerta abierta a la internacionalización si los requisitos cambian alguna vez y se requiere que use texto en otros idiomas además del inglés.
Además, en su nuevo proyecto siempre puede escribir envoltorios para las bibliotecas que se convierten internamente entre ASCII y Unicode y viceversa.
Dicen que siempre lo pondrán en inglés ahora, pero usted admite que tiene clientes en todo el mundo. Un cliente entra y dice que la internacionalización es un factor decisivo, ¿realmente lo rechazarán?
Para aclarar el punto, estoy tratando de hacerte decir que no aceptarán este razonamiento, pero es acertado.
Siempre es mejor prevenir que lamentar, OMI.
Es posible que su cliente potencial ya esté ejecutando una aplicación no Unicode en un idioma que no sea el inglés y no podrá ejecutar su programa sin cambiar la configuración regional de Windows Unicode de un lado a otro, lo que será un gran dolor.
Esa es una muy buena pregunta. La única razón por la que puedo pensar que no tiene nada que ver con el texto I18n o el texto que no está en inglés es que Unicode es particularmente adecuado para ser lo que podría llamarse un conjunto de caracteres central. Si piensa que su sistema es un concentrador con sus dependencias externas como radios, desea aislar las conversiones de codificación de caracteres a los radios, de modo que su sistema concentrador funcione de manera coherente con la codificación elegida. Lo que convierte a Unicode en un conjunto de caracteres ideal para el centro de su sistema es que reconoce la existencia de otros conjuntos de caracteres, define las equivalencias entre sus propios caracteres y los caracteres en esos conjuntos de caracteres externos, y hay un proceso continuo en el que se extiende para mantener A la altura de la innovación y evolución de los conjuntos de caracteres externos. Hay todo tipo de codificaciones extrañas por ahí: incluso cuando la documentación le asegura que el sistema externo o la biblioteca utiliza un ASCII simple, a menudo resulta ser una variante como IBM775 o HPRoman8, y lo bueno de Unicode es que no importa lo que suceda. la codificación se lanza a usted, hay una buena probabilidad de que haya una tabla en unicode.org que defina exactamente cómo convertir esos datos en Unicode y volver a salir sin perder información. Por otra parte, los equivalentes de az están bastante bien definidos en cada conjunto de caracteres, por lo que si sus datos realmente están restringidos al alfabeto inglés estándar, ASCII puede funcionar tan bien como un conjunto de caracteres central.
Una decisión sobre la codificación es una decisión sobre dos cosas: qué conjunto de caracteres se permiten y cómo se representan esos caracteres. Unicode le permite usar casi cualquier personaje inventado, pero puede tener sus propias razones para no querer o necesitar una elección tan amplia. Aún puede restringir los nombres de usuario, por ejemplo, a combinaciones de az y guiones bajos, tal vez porque tiene que ponerlos en un sistema LDAP externo cuyo propio conjunto de caracteres está restringido, tal vez porque necesita imprimirlos usando una fuente que no lo hace. cubre todo Unicode, tal vez porque cierra los problemas de seguridad abiertos por personajes parecidos. Si está usando algo como ASCII o ISO8859-1, la capa de almacenamiento / transmisión implementa muchas de esas restricciones; Con Unicode, la capa de almacenamiento no restringe nada, por lo que es posible que tenga que implementar sus propias reglas en la capa de aplicación. Esto es más trabajo: más programación, más pruebas, más estados posibles del sistema. La compensación por ese trabajo adicional es más flexibilidad, las reglas de nivel de aplicación son más fáciles de cambiar que las codificaciones del sistema.
La internacionalización es mucho más que un simple texto en diferentes idiomas. Apuesto a que es el nicho del futuro en el mundo de TI. Heck, ya está. Ya se ha dicho mucho, solo pensé que añadiría una pequeña cosa. A pesar de que sus clientes en este momento están satisfechos con el inglés, eso podría cambiar en el futuro. Y cuanto más espere, más difícil será convertir su base de código. Incluso hoy pueden tener problemas con, por ejemplo, nombres de archivos u otros tipos de datos que guarda / carga en su aplicación.
La razón para usar Unicode es respetar las abstracciones adecuadas en su diseño.
Solo acostúmbrate a tratar el concepto de texto adecuadamente. No es dificil. No hay razón para crear un diseño roto, incluso si sus usuarios son ingleses.
Las reglas ampliadas de conjunto de caracteres científicos, técnicos y matemáticos.
¿Dónde más se puede decir ⟦∀c∣c∈Unicode⟧ y otras cuestiones técnicas similares?
Los caracteres más allá del rango ASCII de 7 bits también son útiles en inglés. ¿Alguien que use su software necesita escribir el signo €? O £? ¿Qué hay de distinguir el "currículum" del "currículum"? Dice que lo utilizan científicos de todo el mundo, que pueden tener nombres como "Jörg" o "Guðmundsdóttir". En un contexto científico, es útil hablar de longitudes de onda como λ, unidades como Å, o ángulos como Θ, incluso en inglés.
Algunos de estos caracteres, como "ö", "£" y "€" pueden estar disponibles en codificaciones de 8 bits como ISO-8859-1 o Windows-1252, por lo que puede parecer que podría usar esas codificaciones y hecho con eso El problema es que hay caracteres fuera de esos rangos que mucha gente usa con mucha frecuencia, por lo que muchos datos existentes están codificados en UTF-8. Si su software no entiende que al importar datos, puede interpretar el carácter "£" en UTF-8 como una secuencia de 2 caracteres Windows-1252, y procesarlo como "Â £". Si este tipo de error no se detecta durante el tiempo suficiente, puede comenzar a distorsionar sus datos seriamente, ya que múltiples pases de interpretación errónea alteran cada vez más sus datos hasta que se vuelven irrecuperables.
Y es bueno pensar en estos temas desde el principio en el diseño de su programa. Dado que las cadenas tienden a ser un concepto de muy bajo nivel que se enlaza a lo largo de todo su programa, con muchas suposiciones acerca de cómo funcionan de manera implícita en la forma en que se usan, puede ser muy difícil y costoso agregar soporte Unicode a un programa más adelante si para empezar, nunca has pensado en el tema.
Mi recomendación es usar siempre bibliotecas y tipos de cadena compatibles con Unicode siempre que sea posible, y asegurarse de que todas las pruebas que tenga (ya sean de unidad, integración, regresión o cualquier otro tipo de pruebas) que tratan con cadenas intenten pasar algunas cadenas Unicode a través de su Sistema para asegurar que funcionen y salgan ilesos.
Si no maneja Unicode, recomendaría asegurarse de que todos los datos aceptados por el sistema estén limpios en 7 bits (es decir, no haya caracteres más allá del rango US-ASCII de 7 bits). Esto ayudará a evitar problemas con las incompatibilidades entre las codificaciones heredadas de 8 bits como la familia ISO-8859 y UTF-8.
Muchos lenguajes (Java [y, por lo tanto, la mayoría de las implementaciones basadas en JVM], C # [y, por lo tanto, la mayoría de implementaciones en lenguaje .NET], Objective C, Python 3, ...) admiten cadenas Unicode por preferencia o incluso (casi) exclusivamente ( tiene que hacer todo lo posible para trabajar con "cadenas" de bytes en lugar de caracteres Unicode).
Si la empresa para la que trabaja siempre tiene la intención de utilizar cualquiera de estos lenguajes y plataformas, sería muy recomendable comenzar a planificar una estrategia de soporte de Unicode; Un proyecto piloto en particular podría no ser una mala idea.
No has dicho qué idioma estás usando. En algunos idiomas, cambiar de ASCII a Unicode puede ser bastante fácil, mientras que en otros (que no son compatibles con Unicode) puede ser bastante difícil.
Dicho esto, tal vez en su situación no debería apoyar a Unicode: no puede pensar en una razón convincente por la que debería hacerlo, y existen algunas razones (es decir, su costo para cambiar sus bibliotecas existentes) que se oponen. Quiero decir, tal vez "idealmente" deberías, pero en la práctica podría haber alguna otra cosa, más importante o más urgente, en la que gastar tu tiempo y esfuerzo en este momento.
No importa que su software no esté traducido, si sus usuarios usan caracteres internacionales, entonces necesita ser compatible con Unicode para poder hacer el uso correcto de mayúsculas, clasificación, etc.
Obviamente, esto depende de lo que realmente haga su aplicación, pero solo porque solo tiene una versión en inglés no significa que la internacionalización no sea un problema.
¿Qué sucede si deseo almacenar un nombre de cliente que utiliza caracteres que no están en inglés? ¿O el nombre de un lugar en otro país?
Como una ventaja adicional (ya que dice que está apuntando a científicos) es que todo tipo de símbolos y notificaciones científicas son compatibles como parte de Unicode.
En última instancia, me parece mucho más fácil ser consistente. Unicode se comporta de la misma manera, sin importar en qué computadora ejecute la aplicación. Non-Unicode significa que, de forma predeterminada, utiliza un conjunto de caracteres o una página de códigos dependientes de la configuración regional, por lo que el texto que se ve bien en su computadora puede estar lleno de caracteres de basura en otra persona.
Aparte de eso, probablemente no necesite traducir todas sus bibliotecas a Unicode de una sola vez. Escriba los envoltorios según sea necesario para convertir entre Unicode y la codificación que use de otro modo.
Si usa UTF-8 para su texto Unicode, incluso tiene la capacidad de leer cadenas ASCII simples, lo que le ahorraría algunos dolores de cabeza de conversión.
Porque internet es abrumadoramente utilizando Unicode. Las páginas web utilizan unicode. Los archivos de texto, incluidos los documentos de su cliente y los datos en sus portapapeles, son Unicode.
En segundo lugar, Windows, es nativo Unicode, y las API ANSI son un legado.
Las aplicaciones modernas deben usar Unicode cuando corresponda, que está en casi todas partes.
Si el programa toma entrada de texto del usuario, debe usar unicode; nunca se sabe qué idioma va a utilizar el usuario.
Si no tiene necesidad de cambiarse a Unicode, no lo haga. Estoy basando esto en el hecho de que pensó que tendría que cambiar el código no relacionado con el componente que ya necesita cambiar para que todo funcione con Unicode. Si puede hacer que el componente / característica en la que está trabajando en "Unicode listo" sin distribuir el código se convierta en muchos otros componentes (especialmente en otros componentes sin una buena cobertura de prueba), entonces siga adelante y haga que esté listo para Unicode. Pero no pierda toda su base de código sin necesidad comercial.
Si la necesidad del negocio surge más tarde, diríjala entonces. De lo contrario, no lo vas a necesitar.
Las personas en este hilo pueden suponer escenarios en los que se convierte en un requisito comercial. Ejecute esos escenarios por sus gerentes de producto antes de considerarlos escenarios que vale la pena abordar. Asegúrese de que sepan el costo de abordarlos cuando pregunte.
Solo piense en un cliente que quiera usar nombres como Schrödingers Cat para los archivos que guardó usando su software. O imagine algunas ventanas localizadas con una traducción de Mis documentos que utiliza caracteres que no son ASCII. Esa sería la internacionalización que, si bien no es compatible con la internacionalización, tiene efectos en su software.
Además, tener la opción de apoyar la internacionalización más adelante siempre es algo bueno.
Supongamos que su programa me permite poner mi nombre en él, en un formulario, un cuadro de diálogo, lo que sea, y mi nombre no puede escribirse con caracteres ascii ... Aunque su programa está en inglés, los datos pueden estar en otro idioma ...
Unicode es como cooties . Una vez que "infecta" un área, generalmente es difícil contenerla dada la interconexión de las dependencias. Tarde o temprano, es probable que tenga que vincularse en una biblioteca que sea compatible con Unicode y, por lo tanto, utilice wchar_t''s o similares. En lugar de calcular los caracteres entre tipos de caracteres, es bueno tener cadenas consistentes en todo momento.
Por lo tanto, es bueno ser consistente. De lo contrario, terminará con algo similar a la API de Windows que tiene una versión "A" y una versión "W" para la mayoría de las API, ya que para empezar no eran coherentes. (Y en algunos casos, Microsoft ha abandonado la creación de versiones "A" por completo ).
Yo diría que esta actitud expresaba ingenuidad, pero no podría escribir ingenuidad solo en ASCII.
ASCII aún funciona con algunos códigos solo para computadora, pero no es bueno para la fachada entre la máquina y el usuario.
Incluso sin el estilo de cooperación anticuado del neoyorquino, ¿cómo se las arreglaría una mujer pobre llamada Zoë si sus empleadores utilizasen un sistema así?
Por desgracia, ni siquiera buscaría otro empleo, ya que actualizar su currículum sería imposible, y tendría que reanudarlo. ¿Cómo va a explicárselo a su prometida?
Bueno, para empezar, sus usuarios pueden saber y entender el inglés, pero aún pueden tener nombres "locales". Si permite que los usuarios realicen cualquier tipo de entrada a su aplicación, es posible que deseen utilizar caracteres que no sean parte de ascii. Si no admite Unicode, no tendrá forma de permitir estos nombres. Estaría obligando a sus usuarios a adoptar un nombre más simple solo porque la aplicación no es lo suficientemente inteligente como para manejar caracteres especiales.
Otra cosa es que, incluso si el estándar en este momento es que la aplicación solo se lanzará en inglés, también está bloqueando la posibilidad de la internacionalización con ASCII, lo que se suma al trabajo que se debe hacer cuando la política de la compañía decide que las traducciones son una Buena cosa. La política de la compañía es buena, pero también se sabe que cambia.