¿Debe UTF-16 considerarse nocivo?

Voy a preguntar lo que probablemente sea una pregunta bastante controvertida: "¿Debería una de las codificaciones más populares, UTF-16, considerarse nociva?"

¿Por qué hago esta pregunta?

¿Cuántos programadores son conscientes del hecho de que UTF-16 es en realidad una codificación de longitud variable? Con esto quiero decir que hay puntos de código que, representados como pares sustitutos, toman más de un elemento.

Lo sé; muchas aplicaciones, frameworks y API usan UTF-16, como String de Java, String de C #, Win32 API, bibliotecas Qt GUI, la biblioteca ICU Unicode, etc. Sin embargo, con todo eso, hay muchos errores básicos en el procesamiento de caracteres fuera de BMP (caracteres que deben codificarse utilizando dos elementos UTF-16).

Por ejemplo, intente editar uno de estos caracteres:

• 𝄞 ( U + 1D11E ) SÍMBOLO MUSICAL G CLEF
• 𝕥 ( U + 1D565 ) MATEMÁTICA DE DOBLE ESTRUCTURA PEQUEÑA T
• 𝟶 ( U + 1D7F6 ) MONOESPACIO DIGITAL MATEMÁTICO CERO
• 𠂊 ( U + 2008A ) Personaje Han

Puede perder algunos, dependiendo de las fuentes que haya instalado. Todos estos personajes están fuera del BMP (Plano multilingüe básico). Si no puede ver estos caracteres, también puede intentar mirarlos en la referencia de caracteres Unicode .

Por ejemplo, intente crear nombres de archivo en Windows que incluyan estos caracteres; intente eliminar estos caracteres con un "espacio de retroceso" para ver cómo se comportan en diferentes aplicaciones que usan UTF-16. Hice algunas pruebas y los resultados son bastante malos:

• Opera tiene problemas para editarlos (eliminar requiere 2 prensas en el espacio de retroceso)
• El Bloc de notas no puede manejarlos correctamente (eliminar las 2 pulsaciones requeridas en el espacio de retroceso)
• Edición de nombres de archivo en cuadros de diálogo de Windows en roto (eliminar requiere 2 prensas en el espacio de retroceso)
• Todas las aplicaciones QT3 no pueden lidiar con ellas: muestra dos cuadrados vacíos en lugar de un símbolo.
• Python codifica dichos caracteres incorrectamente cuando se usa directamente u'X'!=unicode('X','utf-16')en algunas plataformas cuando X en caracteres fuera de BMP.
• Python 2.5 unicodedata no puede obtener propiedades en dichos caracteres cuando python se compila con cadenas Unicode UTF-16.
• StackOverflow parece eliminar estos caracteres del texto si se editan directamente como caracteres Unicode (estos caracteres se muestran usando escapes Unicode HTML).
• WinForms TextBox puede generar una cadena no válida cuando se limita con MaxLength.

Parece que tales errores son extremadamente fáciles de encontrar en muchas aplicaciones que usan UTF-16.

Entonces ... ¿Crees que UTF-16 debería considerarse dañino?

Esta es una vieja respuesta.
Vea UTF-8 Everywhere para las últimas actualizaciones.

Opinión: Sí, UTF-16 debe considerarse dañino . La razón por la que existe es porque hace algún tiempo solía haber una creencia equivocada de que widechar será lo que UCS-4 es ahora.

A pesar del "anglocentrismo" de UTF-8, debe considerarse la única codificación útil para el texto. Uno puede argumentar que los códigos fuente de programas, páginas web y archivos XML, nombres de archivos del sistema operativo y otras interfaces de texto de computadora a computadora nunca deberían haber existido. Pero cuando lo hacen, el texto no es solo para lectores humanos.

Por otro lado, los gastos generales UTF-8 son un pequeño precio a pagar mientras que tienen ventajas significativas. Ventajas como la compatibilidad con el código inconsciente con el que simplemente pasa cadenas char*. Esto es una gran cosa Hay pocos personajes útiles que son más cortos en UTF-16 que en UTF-8.

Creo que todas las demás codificaciones morirán eventualmente. Esto implica que MS-Windows, Java, ICU, Python dejan de usarlo como su favorito. Después de largas investigaciones y discusiones, las convenciones de desarrollo en mi compañía prohíben el uso de UTF-16 en cualquier lugar, excepto las llamadas a la API del sistema operativo, y esto a pesar de la importancia del rendimiento en nuestras aplicaciones y el hecho de que usamos Windows. Las funciones de conversión se desarrollaron para convertir los UTF8 siempre asumidos std::stringa UTF-16 nativo, que Windows en sí mismo no admite correctamente .

A las personas que dicen " usar lo que se necesita donde se necesita ", les digo: hay una gran ventaja en usar la misma codificación en todas partes, y no veo razón suficiente para hacerlo de otra manera. En particular, creo que agregar wchar_ta C ++ fue un error, y también lo son las adiciones de Unicode a C ++ 0x. Lo que debe ser exigido a las implementaciones STL es sin embargo que todos los std::stringo char*parámetro podría considerarse compatible con Unicode.

También estoy en contra del enfoque de " usa lo que quieras ". No veo ninguna razón para tal libertad. Hay suficiente confusión sobre el tema del texto, lo que resulta en todo este software dañado. Dicho lo anterior, estoy convencido de que los programadores finalmente deben llegar a un consenso sobre UTF-8 como una forma adecuada. (Vengo de un país que no habla ascii y crecí en Windows, por lo que se esperaba que atacara el UTF-16 por motivos religiosos).

Me gustaría compartir más información sobre cómo escribo texto en Windows y lo que recomiendo a todos los demás para la corrección Unicode comprobada en tiempo de compilación, la facilidad de uso y una mejor multiplataforma del código. La sugerencia difiere sustancialmente de lo que generalmente se recomienda como la forma correcta de usar Unicode en Windows. Sin embargo, la investigación en profundidad de estas recomendaciones resultó en la misma conclusión. Entonces aquí va:

• No utilice wchar_tni std::wstringen ningún otro lugar que no sea un punto adyacente a las API que aceptan UTF-16.
• No use _T("")ni L""literales UTF-16 (estos deben ser IMO eliminados del estándar, como parte de la desaprobación UTF-16).
• No utilice tipos, funciones o sus derivados que sean sensibles a la _UNICODEconstante, como LPTSTRo CreateWindow().
• Sin embargo, _UNICODEsiempre definido, para evitar pasar char*cadenas a WinAPI que se compila silenciosamente
• std::stringsy char*en cualquier parte del programa se consideran UTF-8 (si no se dice lo contrario)
• Todas mis cadenas son std::string, aunque puedes pasar char * o cadena literal a convert(const std::string &).

• utilice únicamente funciones de Win32 que aceptan widechars ( LPWSTR). Nunca los que aceptan LPTSTRo LPSTR. Pase los parámetros de esta manera:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (La política utiliza las funciones de conversión a continuación).

• Con cadenas MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Trabajando con archivos, nombres de archivos y fstream en Windows:

  • Nunca pase std::stringo const char*nombre argumentos a la fstreamfamilia. MSVC STL no admite argumentos UTF-8, pero tiene una extensión no estándar que debe usarse de la siguiente manera:

  • Convierta std::stringargumentos a std::wstringcon Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    Tendremos que eliminar manualmente la conversión, cuando la actitud de MSVC a los fstreamcambios.

  • Este código no es multiplataforma y puede que tenga que cambiarse manualmente en el futuro
  • Vea el fstreamcaso de investigación / discusión Unicode 4215 para más información.
  • Nunca produzca archivos de salida de texto con contenido que no sea UTF8
  • Evite usar fopen()por razones RAII / OOD. Si es necesario, use las _wfopen()convenciones de WinAPI anteriores.

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

¡Los puntos de código Unicode no son caracteres! A veces ni siquiera son glifos (formas visuales).

Algunos ejemplos:

• Puntos de código de números romanos como "ⅲ". (Un solo personaje que se parece a "iii".)
• Caracteres acentuados como "á", que se pueden representar como un solo carácter combinado "\ u00e1" o como un carácter y un signo diacrítico separado "\ u0061 \ u0301".
• Caracteres como sigma en minúscula griega, que tienen diferentes formas para el medio ("σ") y el final ("ς") de las posiciones de las palabras, pero que deben considerarse sinónimos para la búsqueda.
• Guión discrecional Unicode U + 00AD, que puede mostrarse visualmente o no, según el contexto, y que se ignora para la búsqueda semántica.

Las únicas formas de realizar correctamente la edición Unicode es utilizar una biblioteca escrita por un experto , o convertirse en un experto y escribir uno usted mismo. Si solo estás contando puntos de código, estás viviendo en un estado de pecado.

Hay una regla general simple sobre qué formulario de transformación Unicode (UTF) usar: - utf-8 para almacenamiento y comunicación - utf-16 para procesamiento de datos - puede usar utf-32 si la mayor parte de la API de plataforma que usa es utf-32 (común en el mundo UNIX).

La mayoría de los sistemas actuales usan utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Consulte también este documento: http://unicode.org/notes/tn12/

Volviendo a "UTF-16 como dañino", diría: definitivamente no.

Las personas que tienen miedo a los sustitutos (pensando que transforman Unicode en una codificación de longitud variable) no entienden las otras complejidades (mucho más grandes) que hacen que el mapeo entre caracteres y un punto de código Unicode sea muy complejo: combinar caracteres, ligaduras, selectores de variación , personajes de control, etc.

Simplemente lea esta serie aquí http://www.siao2.com/2009/06/29/9800913.aspx y vea cómo UTF-16 se convierte en un problema fácil.

Si, absolutamente.

¿Por qué? Tiene que ver con el ejercicio del código .

Si observa estas estadísticas de uso de puntos de código en un corpus grande de Tom Christiansen, verá que los puntos de código BMP trans-8bit se usan en varias órdenes si su magnitud supera los puntos de código que no son BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

Tome la frase TDD: "El código no probado es código roto", y reformúlelo como "el código no ejercitado es código roto", y piense con qué frecuencia los programadores tienen que lidiar con puntos de código que no son BMP.

Los errores relacionados con no tratar con UTF-16 como una codificación de ancho variable son mucho más propensos a pasar desapercibidos que los errores equivalentes en UTF-8 . Algunos lenguajes de programación aún no garantizan darle UTF-16 en lugar de UCS-2, y algunos de los llamados lenguajes de programación de alto nivel ofrecen acceso a unidades de código en lugar de puntos de código (incluso se supone que C le da acceso a puntos de código si los usa wchar_t, independientemente de lo que puedan hacer algunas plataformas).

Sugeriría que pensar que UTF-16 podría considerarse dañino dice que necesita obtener una mayor comprensión de Unicode .

Como me han rechazado por presentar mi opinión sobre una pregunta subjetiva, permítanme explicarlo. ¿Qué es exactamente lo que te molesta de UTF-16? ¿Preferiría que todo estuviera codificado en UTF-8? UTF-7? ¿O qué tal UCS-4? Por supuesto, ciertas aplicaciones no están diseñadas para manejar códigos de caracteres únicos, pero son necesarias, especialmente en el dominio de información global de hoy en día, para la comunicación entre fronteras internacionales.

Pero realmente, si cree que UTF-16 debe considerarse dañino porque es confuso o puede implementarse de manera incorrecta (unicode ciertamente puede serlo), entonces, ¿qué método de codificación de caracteres se consideraría no dañino?

EDITAR: Para aclarar: ¿Por qué considerar las implementaciones inadecuadas de un estándar como un reflejo de la calidad del estándar en sí? Como otros han señalado posteriormente, el simple hecho de que una aplicación utilice una herramienta de manera inapropiada no significa que la herramienta en sí sea defectuosa. Si ese fuera el caso, probablemente podríamos decir cosas como "palabra clave var considerada dañina" o "threading considerado dañino". Creo que la pregunta confunde la calidad y la naturaleza del estándar con las dificultades que muchos programadores tienen para implementarlo y usarlo adecuadamente, lo que creo que se debe más a su falta de comprensión de cómo funciona Unicode, en lugar de a Unicode en sí.

No hay nada malo con la codificación Utf-16. Pero los lenguajes que tratan las unidades de 16 bits como caracteres probablemente deberían considerarse mal diseñados. Tener un tipo llamado ' char' que no siempre representa un personaje es bastante confuso. Dado que la mayoría de los desarrolladores esperarán que un tipo char represente un punto o carácter de código, es probable que gran parte del código se rompa cuando se exponga a caracteres entre BMP.

Sin embargo, tenga en cuenta que incluso el uso de utf-32 no significa que cada punto de código de 32 bits siempre represente un carácter. Debido a la combinación de caracteres, un carácter real puede consistir en varios puntos de código. Unicode nunca es trivial.

Por cierto. Probablemente existe la misma clase de errores con plataformas y aplicaciones que esperan que los caracteres sean de 8 bits, que se alimentan con Utf-8.

Mi elección personal es usar siempre UTF-8. Es el estándar en Linux para casi todo. Es compatible con muchas aplicaciones heredadas. Hay una sobrecarga mínima en términos de espacio adicional utilizado para caracteres no latinos frente a los otros formatos UTF, y hay un ahorro significativo en espacio para caracteres latinos. En la web, los idiomas latinos reinan, y creo que lo harán en el futuro previsible. Y para abordar uno de los principales argumentos en la publicación original: casi todos los programadores son conscientes de que UTF-8 a veces tendrá caracteres de varios bytes. No todos lidian con esto correctamente, pero generalmente son conscientes, lo cual es más de lo que se puede decir de UTF-16. Pero, por supuesto, debe elegir el más apropiado para su aplicación. Es por eso que hay más de uno en primer lugar.

Bueno, hay una codificación que usa símbolos de tamaño fijo. Ciertamente me refiero a UTF-32. Pero 4 bytes para cada símbolo es demasiado espacio desperdiciado, ¿por qué lo usaríamos en situaciones cotidianas?

En mi opinión, la mayoría de los problemas aparecen por el hecho de que algunos softwares se quedaron atrás del estándar Unicode, pero no corrieron rápidamente la situación. Opera, Windows, Python, Qt: todos aparecieron antes de que UTF-16 fuera ampliamente conocido o incluso surgiera. Sin embargo, puedo confirmar que en Opera, Windows Explorer y Notepad ya no hay problemas con los caracteres fuera de BMP (al menos en mi PC). Pero de todos modos, si los programas no reconocen pares sustitutos, entonces no usan UTF-16. Cualesquiera que sean los problemas que surjan al tratar con tales programas, no tienen nada que ver con el UTF-16.

Sin embargo, creo que los problemas del software heredado con solo soporte BMP son algo exagerados. Los caracteres fuera de BMP se encuentran solo en casos y áreas muy específicos. Según las preguntas frecuentes oficiales de Unicode , "incluso en el texto de Asia oriental, la incidencia de pares sustitutos debería ser menos del 1% de todo el almacenamiento de texto en promedio". Por supuesto, los caracteres fuera de BMP no deben descuidarse porque un programa no es compatible con Unicode de lo contrario, pero la mayoría de los programas no están destinados a trabajar con textos que contienen dichos caracteres. Es por eso que si no lo apoyan, es desagradable, pero no una catástrofe.

Ahora consideremos la alternativa. Si UTF-16 no existiera, entonces no tendríamos una codificación adecuada para texto que no sea ASCII, y todo el software creado para UCS-2 tendría que ser completamente rediseñado para seguir siendo compatible con Unicode. Lo último probablemente solo retrasaría la adopción de Unicode. Tampoco hubiéramos podido mantener la compatibilidad con el texto en UCS-2 como lo hace UTF-8 en relación con ASCII.

Ahora, dejando de lado todos los problemas heredados, ¿cuáles son los argumentos en contra de la codificación en sí? Realmente dudo que los desarrolladores de hoy en día no sepan que UTF-16 es de longitud variable, está escrito en todas partes con Wikipedia. UTF-16 es mucho menos difícil de analizar que UTF-8, si alguien señala la complejidad como un posible problema. También es un error pensar que es fácil equivocarse al determinar la longitud de la cadena solo en UTF-16. Si usa UTF-8 o UTF-32, debe tener en cuenta que un punto de código Unicode no significa necesariamente un carácter. Aparte de eso, no creo que haya nada sustancial en contra de la codificación.

Por lo tanto, no creo que la codificación en sí misma deba considerarse dañina. UTF-16 es un compromiso entre simplicidad y compacidad, y no hay daño en usar lo que se necesita donde se necesita . En algunos casos, debe seguir siendo compatible con ASCII y necesita UTF-8, en algunos casos desea trabajar con ideogramas Han y ahorrar espacio con UTF-16, en algunos casos necesita representaciones universales de caracteres con un signo fijo codificación de longitud. Use lo que sea más apropiado, solo hágalo correctamente.

Los años de trabajo de internacionalización de Windows, especialmente en los idiomas de Asia oriental, podrían haberme corrompido, pero me inclino hacia UTF-16 para las representaciones de cadenas internas al programa, y ​​UTF-8 para el almacenamiento en red o archivos de documentos de texto sin formato. Sin embargo, UTF-16 generalmente se puede procesar más rápido en Windows, por lo que ese es el beneficio principal de usar UTF-16 en Windows.

Dar el salto al UTF-16 mejoró dramáticamente la adecuación de los productos promedio que manejan textos internacionales. Solo hay unos pocos casos estrechos en los que se deben considerar los pares sustitutos (eliminaciones, inserciones y saltos de línea, básicamente) y el caso promedio es en su mayoría paso directo. Y a diferencia de las codificaciones anteriores como las variantes JIS, UTF-16 limita los pares sustitutos a un rango muy estrecho, por lo que la verificación es realmente rápida y funciona hacia adelante y hacia atrás.

De acuerdo, también es aproximadamente tan rápido en UTF-8 codificado correctamente. Pero también hay muchas aplicaciones UTF-8 rotas que codifican incorrectamente pares sustitutos como dos secuencias UTF-8. Entonces UTF-8 tampoco garantiza la salvación.

IE maneja pares sustitutos razonablemente bien desde el año 2000 más o menos, a pesar de que normalmente los convierte de páginas UTF-8 a una representación interna UTF-16; Estoy bastante seguro de que Firefox también lo hizo bien, así que no me importa lo que haga Opera.

UTF-32 (también conocido como UCS4) no tiene sentido para la mayoría de las aplicaciones, ya que requiere mucho espacio, por lo que prácticamente no es un iniciador.

UTF-8 es definitivamente el camino a seguir, posiblemente acompañado por UTF-32 para uso interno en algoritmos que necesitan acceso aleatorio de alto rendimiento (pero que ignora la combinación de caracteres).

Tanto UTF-16 como UTF-32 (así como sus variantes LE / BE) sufren problemas de resistencia, por lo que nunca deben usarse externamente.

UTF-16? Definitivamente perjudicial. Solo mi grano de sal aquí, pero hay exactamente tres codificaciones aceptables para texto en un programa:

• ASCII: cuando se trata de cosas de bajo nivel (por ejemplo, microcontroladores) que no pueden permitirse nada mejor
• UTF8: almacenamiento en medios de ancho fijo como archivos

• puntos de código enteros ("CP"?): una matriz de los enteros más grandes que son convenientes para su lenguaje de programación y plataforma (decae a ASCII en el límite de bajos recursos). Debe ser int32 en computadoras más antiguas e int64 en cualquier cosa con direccionamiento de 64 bits.

• Obviamente, las interfaces con el código heredado utilizan la codificación necesaria para que el código anterior funcione correctamente.

Unicode define puntos de código de hasta 0x10FFFF (1,114,112 códigos), todas las aplicaciones que se ejecutan en entornos multilingües que tratan con cadenas / nombres de archivos, etc., deben manejarlo correctamente.

Utf-16 : cubre solo 1,112,064 códigos. Aunque los que están al final de Unicode son de los planos 15-16 (Área de uso privado). No puede crecer más en el futuro, excepto romper el concepto Utf-16 .

Utf-8 : cubre teóricamente 2,216,757,376 códigos. El rango actual de códigos Unicode se puede representar mediante una secuencia máxima de 4 bytes. No sufre con el problema de orden de bytes , es "compatible" con ASCII.

Utf-32 : cubre teóricamente 2 ^ 32 = 4,294,967,296 códigos. Actualmente no está codificado en longitud variable y probablemente no lo estará en el futuro.

Esos hechos se explican por sí mismos. No entiendo abogar por el uso general de Utf-16 . Está codificado en longitud variable (no se puede acceder por índice), tiene problemas para cubrir todo el rango Unicode incluso en la actualidad, se debe manejar el orden de bytes, etc. No veo ninguna ventaja, excepto que se usa de forma nativa en Windows y algunos otros lugares. Aunque al escribir código multiplataforma probablemente sea mejor usar Utf-8 de forma nativa y hacer conversiones solo en los puntos finales de forma dependiente de la plataforma (como ya se sugirió). Cuando es necesario el acceso directo por índice y la memoria no es un problema, se debe usar Utf-32 .

El principal problema es que muchos programadores que trabajan con Windows Unicode = Utf-16 ni siquiera saben o ignoran el hecho de que está codificado en longitud variable.

La forma en que suele estar en la plataforma * nix es bastante buena, las cadenas c (char *) interpretadas como codificadas en Utf-8 , las cadenas c anchas (wchar_t *) interpretadas como Utf-32 .

Agregue esto a la lista:

El escenario presentado es simple (¡incluso más simple ya que lo presentaré aquí de lo que era originalmente!): 1. Un WinForms TextBox se encuentra en un formulario, vacío. Tiene un MaxLength establecido en 20 .

2.El usuario escribe en el cuadro de texto, o tal vez pega texto en él.

3. No importa lo que escriba o pegue en el TextBox, está limitado a 20, aunque simpatizará con un pitido en el texto más allá de 20 (YMMV aquí; ¡cambié mi esquema de sonido para darme ese efecto!).

4.El pequeño paquete de texto se envía a otro lugar, para comenzar una aventura emocionante.

Ahora este es un escenario fácil, y cualquiera puede escribir esto, en su tiempo libre. Lo escribí yo mismo en múltiples lenguajes de programación usando WinForms, porque estaba aburrido y nunca lo había probado antes. Y con texto en varios idiomas reales porque estoy conectado de esa manera y tengo más diseños de teclado que posiblemente cualquier persona en todo el universo.

Incluso llamé a la forma Magic Carpet Ride , para ayudar a mejorar el aburrimiento.

Esto no funcionó, por lo que vale.

Entonces, en su lugar, ingresé los siguientes 20 caracteres en mi formulario Magic Carpet Ride :

0123401234012340123 𠀀

UH oh.

Ese último personaje es U + 20000, el primer ideógrafo de Extensión B de Unicode (también conocido como U + d840 U + dc00, para sus amigos cercanos a los que no le da vergüenza ser desnudo, por así decirlo) ...

Y ahora tenemos un juego de pelota.

Porque cuando TextBox.MaxLength habla sobre

Obtiene o establece el número máximo de caracteres que se pueden ingresar manualmente en el cuadro de texto.

lo que realmente significa es

Obtiene o establece el número máximo de unidades de código LE UTF-16 que se pueden ingresar manualmente en el cuadro de texto y truncará sin piedad la basura de cualquier cadena que intente jugar juegos cursis con la noción de carácter lingüístico de que solo alguien tan obsesionado como ese tipo de Kaplan lo encontrará ofensivo (¡caramba, necesita salir más!).

Trataré de ver si el documento se actualiza ...
Los lectores habituales que recuerden mi serie UCS-2 a UTF-16 notarán mi descontento con la noción simplista de TextBox.MaxLength y cómo debería manejar al menos este caso donde su comportamiento draconiano crea una secuencia ilegal, una que otras partes de .Net Framework pueden arrojar un

• System.Text.EncoderFallbackException: no se puede traducir el carácter Unicode \ uD850 en el índice 0 a la página de códigos especificada. *

excepción si pasa esta cadena a otra parte en .Net Framework (como estaba haciendo mi colega Dan Thompson).

Ahora bien, tal vez la serie completa de UCS-2 a UTF-16 está fuera del alcance de muchos.
Pero no es razonable esperar que TextBox.Text no produzca un System.Stringque no hará que se lance otra pieza de .Net Framework? Quiero decir, no es que haya una posibilidad en la forma de algún evento en el control que le informe sobre el próximo truncamiento en el que puede agregar fácilmente la validación más inteligente, validación que al control en sí no le importa hacer. Llegaría al extremo de decir que este control punk está rompiendo un contrato de seguridad que incluso podría generar problemas de seguridad si se puede clasificar causando excepciones inesperadas para terminar una aplicación como una especie de denegación de servicio. ¿Por qué cualquier proceso, método, algoritmo o técnica de WinForms produce resultados no válidos?

Fuente: Michael S. Kaplan MSDN Blog

No diría necesariamente que UTF-16 es dañino. No es elegante, pero cumple su función de compatibilidad con UCS-2, al igual que GB18030 con GB2312 y UTF-8 con ASCII.

Pero hacer un cambio fundamental en la estructura de Unicode a mitad de camino, después de que Microsoft y Sun hubieran construido API enormes alrededor de caracteres de 16 bits, fue perjudicial. El hecho de no difundir el cambio fue más dañino.

UTF-16 es el mejor compromiso entre manejo y espacio y es por eso que la mayoría de las plataformas principales (Win32, Java, .NET) lo usan para la representación interna de cadenas.

Nunca he entendido el punto de UTF-16. Si desea la representación más eficiente en espacio, use UTF-8. Si desea poder tratar el texto como de longitud fija, use UTF-32. Si no quieres ninguno, usa UTF-16. Peor aún, dado que todos los caracteres comunes (plano multilingüe básico) en UTF-16 caben en un único punto de código, los errores que suponen que UTF-16 es de longitud fija serán sutiles y difíciles de encontrar, mientras que si intenta hacerlo esto con UTF-8, su código fallará rápida y ruidosamente tan pronto como intente internacionalizarse.

_{Como todavía no puedo comentar, publico esto como respuesta, ya que parece que no puedo contactar a los autores de utf8everywhere.org. Es una pena que no obtenga automáticamente el privilegio de comentario, ya que tengo suficiente reputación en otros intercambios de pila.}

Esto se entiende como un comentario a la Opinión: Sí, UTF-16 debe considerarse una respuesta dañina .

Una pequeña corrección:

Para evitar que uno pase accidentalmente un UTF-8 char*a versiones ANSI-string de funciones de API de Windows, uno debe definir UNICODE, no _UNICODE. _UNICODEfunciones como mapas _tcslena wcslen, no MessageBoxa MessageBoxW. En cambio, la UNICODEdefinición se encarga de lo último. Como prueba, esto es del WinUser.hencabezado de MS Visual Studio 2005 :

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

Como mínimo, este error debe corregirse en utf8everywhere.org.

Una sugerencia:

Quizás la guía debería contener un ejemplo de uso explícito de la versión de cadena ancha de una estructura de datos, para que sea menos fácil perderla / olvidarla. El uso de versiones de cadenas anchas de estructuras de datos además del uso de versiones de funciones de cadenas anchas hace que sea aún menos probable que se llame accidentalmente una versión de cadenas ANSI de dicha función.

Ejemplo del ejemplo:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Alguien dijo que UCS4 y UTF-32 eran iguales. No, pero sé a qué te refieres. Sin embargo, uno de ellos es una codificación del otro. Desearía que hubieran pensado en especificar endianness desde el principio para que no tuviéramos la batalla de endianess aquí también. ¿No podrían haberlo visto venir? Al menos UTF-8 es igual en todas partes (a menos que alguien siga la especificación original con 6 bytes).

Si utiliza UTF-16 que tiene incluir el manejo de caracteres de varios bytes. No puede ir al enésimo carácter indexando 2N en una matriz de bytes. Tienes que caminar o tener índices de personajes. De lo contrario, ha escrito un error.

El borrador actual de la especificación de C ++ dice que UTF-32 y UTF-16 pueden tener variantes little-endian, big-endian y no especificadas. De Verdad? Si Unicode hubiera especificado que todo el mundo tenía que hacer little endian desde el principio, todo habría sido más simple. (Hubiera estado bien con big-endian también.) En cambio, algunas personas lo implementaron de una manera, otras de otra, y ahora estamos atrapados en la tontería por nada. A veces es vergonzoso ser ingeniero de software.

No creo que sea dañino si el desarrollador es lo suficientemente cuidadoso.
Y deberían aceptar este intercambio si también lo saben bien.

Como desarrollador de software japonés, considero que UCS-2 es lo suficientemente grande y limitar el espacio aparentemente simplifica la lógica y reduce la memoria de tiempo de ejecución, por lo que usar utf-16 bajo la limitación UCS-2 es lo suficientemente bueno.

Hay un sistema de archivos u otra aplicación que supone que los puntos de código y los bytes son proporcionales, de modo que se puede garantizar que el número de punto de código sin formato se ajuste a algún almacenamiento de tamaño fijo.

Un ejemplo es NTFS y VFAT que especifican UCS-2 como codificación de almacenamiento de nombre de archivo.

Si ese ejemplo realmente quiere extenderse para admitir UCS-4, podría estar de acuerdo con usar utf-8 para todo de todos modos, pero la longitud fija tiene buenos puntos como:

1. puede garantizar el tamaño por longitud (el tamaño de los datos y la longitud del punto de código es proporcional)
2. puede usar el número de codificación para la búsqueda de hash
3. los datos no comprimidos tienen un tamaño razonable (en comparación con utf-32 / UCS-4)

En el futuro, cuando la potencia de memoria / procesamiento sea barata, incluso en cualquier dispositivo incorporado, podemos aceptar que el dispositivo sea un poco lento para errores de caché adicionales o fallas de página y uso de memoria adicional, pero supongo que esto no sucederá en el futuro cercano ...

"¿Debería una de las codificaciones más populares, UTF-16, ser considerada dañina?"

Muy posiblemente, pero las alternativas no necesariamente deben verse como mucho mejores.

La cuestión fundamental es que existen muchos conceptos diferentes sobre: ​​glifos, caracteres, puntos de código y secuencias de bytes. El mapeo entre cada uno de estos no es trivial, incluso con la ayuda de una biblioteca de normalización. (Por ejemplo, algunos caracteres en idiomas europeos que se escriben con un guión basado en el latín no se escriben con un único punto de código Unicode. ¡Y eso está en el extremo más simple de la complejidad!) Lo que esto significa es que hacer que todo sea correcto es asombrosamente difícil; se esperan errores extraños (y en lugar de quejarse de ellos aquí, dígales a los encargados del mantenimiento del software en cuestión).

La única forma en que UTF-16 puede considerarse dañino en lugar de, por ejemplo, UTF-8 es que tiene una forma diferente de codificar puntos de código fuera del BMP (como un par de sustitutos). Si el código desea acceder o iterar por punto de código, eso significa que debe ser consciente de la diferencia. OTOH, significa que un cuerpo sustancial de código existente que asume "caracteres" siempre puede encajar en una cantidad de dos bytes, una suposición bastante común, si es incorrecta, al menos puede continuar funcionando sin reconstruirlo todo. En otras palabras, ¡al menos puedes ver esos personajes que no se manejan correctamente!

Diría su pregunta y diría que todo el maldito shebang de Unicode debería considerarse dañino y todos deberían usar una codificación de 8 bits, excepto que he visto (en los últimos 20 años) a dónde lleva eso: horrible confusión sobre las diversas codificaciones ISO 8859, más el conjunto completo de las utilizadas para cirílico, y el conjunto EBCDIC, y ... bueno, Unicode por todas sus fallas supera eso. Si tan solo no fuera un compromiso tan desagradable entre los malentendidos de diferentes países.