Comentarios
Answer
Esta es una respuesta antigua.
Ver UTF-8 Everywhere para obtener las últimas actualizaciones.
Opinión: Sí, UTF-16 debe considerarse perjudicial . La misma razón por la que existe es porque hace algún tiempo solía haber una creencia equivocada de que widechar va a ser lo que UCS-4 ahora es.
A pesar del «anglocentrismo» de UTF-8, debe considerarse la única codificación útil para texto. Se puede argumentar que los códigos fuente de los programas, las páginas web y los archivos XML, los nombres de los 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, la sobrecarga de UTF-8 es un pequeño precio a pagar, pero tiene ventajas significativas. Ventajas como la compatibilidad con código inconsciente que simplemente pasa cadenas con char*. Esto es algo grandioso. Hay pocos caracteres ú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 dejar de usarlo como su favorito. Después de una larga investigación y discusiones, las convenciones de desarrollo en mi empresa prohíben el uso de UTF-16 en cualquier lugar excepto en las llamadas a la API del SO, y esto a pesar de su importancia de rendimiento en nuestras aplicaciones y el hecho de que usamos Windows. Las funciones de conversión se desarrollaron para convertir UTF8 std::string s siempre asumidos en UTF-16 nativo, que Windows mismo no se admite correctamente .
A las personas que dicen « use lo que se necesita donde se necesite «, les digo: «hay una gran ventaja en usar la misma codificación en todas partes, y no veo razón suficiente para hacer lo contrario. En particular, creo que agregar wchar_t a C ++ fue un error, al igual que las adiciones Unicode a C ++ 0x. Sin embargo, lo que se debe exigir a las implementaciones de STL es que cada std::string o char* se consideraría compatible con Unicode.
También estoy en contra del « uso lo que quieras «. No veo razón para tal libertad. Hay suficiente confusión sobre el tema del texto, lo que resulta en todo este software roto. Dicho lo anterior, estoy convencido de que los programadores deben finalmente llegar a un consenso sobre UTF-8 como una forma adecuada. (Vengo de un país que no habla ascii y crecí con Windows, por lo que la última vez que se esperaba que atacara 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 verificar la corrección Unicode 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 dio como resultado la misma conclusión. Así que aquí va:
- No utilice
wchar_t o std::wstring en ningún lugar que no sea el punto adyacente a API que aceptan UTF-16.
- No utilice
_T("") o L"" literales UTF-16 (estos deben, en mi opinión, estar fuera del estándar , como parte de la desaprobación de UTF-16).
- No use tipos, funciones o sus derivados que sean sensibles a la constante
_UNICODE, como LPTSTR o CreateWindow().
- Sin embargo,
_UNICODE siempre definido, para evite pasar char* cadenas a WinAPI que se compilan silenciosamente
-
std::strings y char* en cualquier parte del programa se consideran UTF-8 (si no se dice lo contrario)
- Todas mis cadenas son
std::string, aunque puede pasar char * o cadena literal a convert(const std::string &).
-
solo use funciones Win32 que acepten caracteres anchos (LPWSTR). Nunca aquellos que acepten LPTSTR o LPSTR. Pase los parámetros de esta manera:
::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
(La política usa 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);
-
Trabajar con archivos, nombres de archivo y fstream en Windows:
- Nunca pase
std::string o const char* argumentos de nombre de archivo para la familia fstream. MSVC STL no admite argumentos UTF-8, pero tiene una extensión no estándar que se debe usar de la siguiente manera:
-
Convierta std::string argumentos a std::wstring con Utils::Convert:
std::ifstream ifs(Utils::Convert("hello"), std::ios_base::in | std::ios_base::binary);
Tendremos que hacerlo manualmente eliminar la conversión, cuando la actitud de MSVC hacia fstream cambie.
- Este código no es multiplataforma y puede que tenga que cambiarse manualmente en el futuro
- Consulte el
fstream caso 4215 de investigación / discusión Unicode para obtener más información.
- Nunca produzca archivos de salida de texto con contenido que no sea UTF8
- Evite el uso de
fopen() por razones de RAII / OOD. Si es necesario, use _wfopen() y las 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 }
Comentarios
Respuesta
¡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 carácter que se parece a «iii».)
- Caracteres acentuados como «á», que se pueden representar como un solo carácter combinado «\ u00e1» o un carácter y diacrítico separado «\ u0061 \ u0301 «.
- Caracteres como sigma 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 o no visualmente, según el contexto, y que se ignora para la búsqueda semántica.
Las únicas formas de obtener la edición Unicode lo correcto es usar una biblioteca escrita por un experto , o convertirse en un experto y escribir una usted mismo. Si solo está contando puntos de código, está viviendo en un estado de pecado.
Comentarios
Respuesta
Existe 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 ir con 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/
Volver a «UTF-16 como dañino», Yo diría: definitivamente no.
Las personas que temen a los sustitutos (pensando que transforman Unicode en una codificación de longitud variable) no comprenden las otras complejidades (mucho más grandes) que hacen que el mapeo entre caracteres y un punto de código Unicode muy complejo: combinación de caracteres, ligaduras, selectores de variación, caracteres de control, etc.
Solo 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.
Comentarios
Respuesta
Sí, absolutamente.
¿Por qué? Tiene que ver con ejercitar el código .
Si observa estas estadísticas de uso de puntos de código en un corpus grande por Tom Christiansen, verá que los puntos de código BMP trans-8 bits se utilizan en varios órdenes si la magnitud es mayor que 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 el dictado TDD: «El código no probado es código roto», y reformúlelo como «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.
Es mucho más probable que los errores relacionados con no manejar UTF-16 como una codificación de ancho variable pasen desapercibidos que los errores equivalentes en UTF-8 . Algunos lenguajes de programación aún no garantice 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 (se supone que incluso C le da acceso a puntos de código si usa wchar_t, independientemente de la plataforma formularios pueden hacer).
Comentarios
Responder
Sugeriría que pensar que UTF-16 podría considerarse dañino significa que necesita obtener una mayor comprensión de Unicode .
Ya que me han votado negativamente por presentar mi opinión sobre una pregunta subjetiva, permítanme explicarlo. ¿Qué es exactamente lo que le 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 todos los códigos de un solo carácter, pero son necesarias, especialmente en el dominio de información global actual, para la comunicación entre fronteras internacionales.
Pero realmente, si cree que UTF-16 debe considerarse dañino porque es confuso o puede implementarse incorrectamente (unicode ciertamente puede serlo), ¿qué método de codificación de caracteres se consideraría no dañino?
EDITAR: Para aclarar: ¿Por qué considerar las implementaciones incorrectas de un estándar como un reflejo de la calidad del estándar en sí? Como otros han señalado posteriormente, el mero hecho de que una aplicación utilice una herramienta de manera inapropiada no significa que la herramienta en sí mismo es defectuoso. Si ese fuera el caso, probablemente podríamos decir cosas como «palabra clave var considerada dañina» o «subprocesos considerados dañinos». Creo que la pregunta confunde la calidad y naturaleza del estándar con las dificultades que muchos programadores tienen para implementar y usarlo correctamente, lo que creo que se debe más a su falta de comprensión de cómo funciona unicode, que al propio Unicode.
Comentarios
Responder
No hay nada de malo con Utf- 16 codificación. 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 carácter es bastante confuso. Dado que la mayoría de los desarrolladores esperarán que un tipo char represente un punto de código o carácter, es probable que gran parte del código se rompa cuando se exponga a caracteres más allá de BMP.
Sin embargo, tenga en cuenta que incluso usar utf-32 no significa que cada 32- el punto de código de bits siempre representará un carácter. Debido a la combinación de caracteres, un carácter real puede constar de varios puntos de código. Unicode nunca es trivial.
Por cierto. Probablemente exista la misma clase de errores con plataformas y aplicaciones que esperan que los caracteres sean de 8 bits, que se alimentan con Utf-8.
Comentarios
Responder
Mi elección personal es utilizar 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 el espacio para caracteres latinos. En la web, los idiomas latinos son los que dominan y creo que lo harán en el futuro previsible. Y para abordar uno de los argumentos principales en la publicación original: casi todos los programadores saben que UTF-8 a veces tendrá caracteres de varios bytes. No todo el mundo maneja esto correctamente, pero normalmente lo saben, lo que es más de lo que se puede decir de UTF-16. Pero, por supuesto, debe elegir el más adecuado para su aplicación. Es por eso que hay más de uno en primer lugar.
Comentarios
Respuesta
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 mucho espacio desperdiciado, ¿por qué lo usaríamos en situaciones cotidianas?
En mi opinión, la mayoría de los problemas surgen del hecho de que algún software se cayó detrás del estándar Unicode, pero no se apresuraron a corregir la situación. Opera, Windows, Python, Qt: todos aparecieron antes de que UTF-16 se hiciera ampliamente conocido o incluso existiera. Sin embargo, puedo confirmar que en Opera, el Explorador de Windows y el Bloc de notas ya no hay problemas con caracteres fuera de BMP (al menos en mi PC). Pero de todos modos, si los programas no reconocen los 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 UTF-16 en sí.
Sin embargo, creo que los problemas del software heredado que solo admite BMP son algo exagerados. Los personajes fuera de BMP se encuentran solo en casos y áreas muy específicos. De acuerdo con 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 ser descuidados porque un programa no es compatible con Unicode de otra manera, pero la mayoría de los programas no están diseñados para trabajar con textos que contienen tales caracteres. Por eso, si no lo hacen. Para apoyarlo, 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 no 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 ralentizaría la adopción de Unicode. Además, no 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? Realmente dudo que los desarrolladores de hoy en día no sepan que UTF-16 es de longitud variable, está escrito en todas partes comenzando con Wikipedia. UTF-16 es mucho menos difícil de analizar que UTF-8, si alguien señaló la complejidad como un posible problema. También es incorrecto pensar que es fácil equivocarse al determinar la longitud de la cuerda 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í deba considerarse dañina. UTF-16 es un compromiso entre simplicidad y compacidad, y no hay ningún daño en usar lo que se necesita donde se necesita .En algunos casos, necesita seguir siendo compatible con ASCII y necesita UTF-8, en algunos casos desea trabajar con ideogramas Han y ahorrar espacio usando UTF-16, en algunos casos necesita representaciones universales de caracteres usando un codificación de longitud. Use lo que sea más apropiado, simplemente hágalo correctamente.
Comentarios
Responder
Años de trabajo de internacionalización de Windows, especialmente en idiomas del este de Asia, podrían haberme corrompido, pero me inclino por UTF-16 para las representaciones internas del programa de cadenas, y UTF-8 para el almacenamiento en red o de archivos de texto plano. como documentos. 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 a UTF-16 mejoró drásticamente la adecuación del manejo de productos promedio texto internacional.Hay solo unos pocos casos estrechos en los que es necesario considerar los pares sustitutos (eliminaciones, inserciones y saltos de línea, básicamente) y el caso promedio es principalmente de paso directo. Y a diferencia de las codificaciones anteriores como las variantes de 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, es aproximadamente tan rápido en correctamente- codificado UTF-8, también. Pero también hay muchas aplicaciones UTF-8 rotas que codifican incorrectamente pares sustitutos como dos secuencias UTF-8. Por lo tanto, UTF-8 tampoco garantiza la salvación.
IE maneja los pares sustitutos razonablemente bien desde 2000 aproximadamente, aunque normalmente los convierte de páginas UTF-8 a una representación UTF-16 interna; I «Estoy bastante seguro de que Firefox también lo hizo bien, así que realmente 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 es prácticamente inútil.
Comentarios
Respuesta
UTF-8 es definitivamente el camino a seguir, posiblemente acompañado de UTF-32 para usar en algoritmos que necesitan acceso aleatorio de alto rendimiento (pero que ignoran la combinación de caracteres).
Tanto UTF-16 como UTF-32 (así como sus variantes LE / BE) sufren problemas de endiabilidad, por lo que deberían nunca se use externamente.
Comentarios
Respuesta
¿UTF-16? definitivamente dañino. Solo mi grano de sal aquí, pero hay exactamente tres codificaciones aceptables para el 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 números enteros más grandes que son convenientes para su lenguaje de programación y plataforma (decae a ASCII en el límite de recursos bajos). Debe ser int32 en computadoras más antiguas e int64 en cualquier cosa con direccionamiento de 64 bits.
-
Obviamente, interfaces para el uso de código heredado qué codificación se necesita para que el código antiguo funcione correctamente.
Comentarios
Responder
Unicode define puntos de código hasta 0x10FFFF (1,114,112 códigos), todas las aplicaciones que se ejecutan en entornos multilingües tratan con cadenas / nombres de archivos, etc. debería manejar eso 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 de 4 bytes como máximo. No sufre 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.
Estos hechos se explican por sí mismos. No entiendo la defensa del uso general de Utf-16 . Tiene una codificación de longitud variable (no se puede acceder a ella por índice), tiene problemas para cubrir todo el rango Unicode incluso en la actualidad, debe manejarse el orden de bytes, etc. No veo ninguna ventaja excepto que se usa de forma nativa en Windows y en algunos otros lugares. Aunque al escribir código multiplataforma, probablemente sea mejor usar Utf-8 de forma nativa y realizar conversiones solo en los puntos finales en 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, cadenas c (char *) interpretadas como Utf-8 codificadas, cadenas c anchas (wchar_t *) interpretadas como Utf-32 .
Comentarios
Respuesta
Agregue esto a la lista:
El escenario presentado es simple (¡incluso más simple 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 TextBox, o tal vez pega texto en él.
3.No importa lo que escriba o pegue en el TextBox, está limitado a 20, aunque emitirá un pitido con simpatía en el texto más allá del 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 emocionante aventura.
Este es un escenario fácil, y cualquiera puede escribirlo en su tiempo libre. Lo escribí yo mismo en varios lenguajes de programación usando WinForms, porque estaba aburrido y nunca antes lo había probado. Y con texto en varios idiomas reales porque estoy conectado de esa manera y tengo más diseños de teclado que posiblemente cualquiera en todo el maldito universo.
Incluso nombré la forma Paseo en alfombra mágica , para ayudar a aliviar el aburrimiento.
Esto no funcionó, por lo que vale.
Entonces, en su lugar, ingresé los siguientes 20 caracteres en mi Magic Carpet Ride formulario:
0123401234012340123 𠀀
Uh oh.
Ese último carácter es U + 20000, el primero Extensión B ideograma de Unicode (también conocido como U + d840 U + dc00, para sus amigos cercanos de los que no se avergüenza de ser desvestido, por así decirlo, delante de ellos) ….
Y ahora tenemos un juego de pelota.
Porque cuando TextBox. MaxLength habla de
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 codificador UTF-16 LE Las unidades que se pueden ingresar manualmente en el cuadro de texto y que truncarán sin piedad la basura viviente de cualquier cadena que intente jugar juegos cursis con la noción de carácter lingüístico que solo alguien tan obsesionado como ese compañero de Kaplan encontrará ofensivo (caramba, necesita ¡Obtenga más información!).
Intentaré actualizar el documento …
Lectores habituales que Recuerdo que mi serie UCS-2 a UTF-16 notará mi descontento con la noción simplista de TextBox.MaxLength y cómo debe manejar como mínimo este caso donde su comportamiento draconiano crea una secuencia ilegal, una que otras partes de .Net Framework pueden lanzar una
- 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 en otro lugar del .Net Framework (como lo estaba haciendo mi colega Dan Thompson).
Bien, tal vez la UCS-2 a UTF-16 completa esté fuera del alcance de muchos.
Pero no «¿No es razonable esperar que TextBox.Text no produzca un System.String que no hará que se lance otra pieza de .Net Framework? Quiero decir, no es como si hubiera una posibilidad en la forma de algún evento en el control que le informa del próximo truncamiento donde puede agregar fácilmente la validación más inteligente – validación que al control en sí no le importa hacer. va tan lejos como para decir que este control punk está rompiendo un contrato de seguridad que incluso podría conducir a problemas de seguridad si puede clasificar las excepciones inesperadas para terminar una aplicación como una especie de denegación de servicio. ¿Por qué debería cualquier proceso o método de WinForms o ¿Algún algoritmo o técnica produce resultados no válidos?
Fuente: Michael S.Blog de Kaplan MSDN
Comentarios
Responder
No diría necesariamente que UTF-16 es dañino. No es elegante, pero cumple su propósito de compatibilidad con UCS-2, al igual que GB18030 lo hace con GB2312, y UTF-8 lo hace con ASCII.
Pero hacer un cambio fundamental en la estructura de Unicode a mitad de camino, después de que Microsoft y Sun habían construido enormes API alrededor de caracteres de 16 bits, fue perjudicial. No difundir el conocimiento del cambio fue más perjudicial.
Comentarios
Respuesta
Respuesta
Nunca he entendido el sentido de UTF-16. Si quieres la representación más eficiente en el espacio, usa UTF-8. Si quieres poder tratar el texto como de longitud fija, use UTF-32. Si no quiere ninguno, use UTF-16. Peor aún, ya que todos los caracteres comunes (plano multilingüe básico) en UTF-16 caben en un solo punto de código, errores que asumen que UTF-16 es de longitud fija será sutil y difícil de encontrar, mientras que si intenta hacer esto con UTF-8, su código fallará rápido y ruidosamente tan pronto como intente internacionalizarse.
Responder
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 comentar, ya que tengo suficiente reputación en otros intercambios de pila.
Esto es un comentario a la Opinión: Sí, UTF-16 debe considerarse perjudicial respuesta.
Una pequeña corrección:
Para evitar que uno pase accidentalmente un UTF-8 char* en versiones de cadena ANSI de funciones API de Windows, se debe defina UNICODE, no _UNICODE. _UNICODE asigna funciones como _tcslen a wcslen, no a MessageBox a MessageBoxW. En cambio, la UNICODE define se encarga de esta última. Como prueba, esto es del encabezado WinUser.h 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 Wide- versión de cadena 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 de las versiones de funciones de cadenas anchas hace que sea aún menos probable que uno llame accidentalmente a una versión de cadena 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); }
Comentarios
Responder
Alguien dijo que UCS4 y UTF-32 eran Lo mismo. No, pero sé lo que quieres decir. Sin embargo, uno de ellos es una codificación del otro. Ojalá hubieran pensado en especificar la endiabilidad desde el principio para que no tuviéramos la batalla de la endiancia aquí también. ¿No podrían haberlo visto venir? Al menos UTF-8 es el mismo en todas partes re (a menos que alguien esté siguiendo la especificación original con 6 bytes).
Si usa UTF-16, tiene incluir el manejo de caracteres multibyte. No puede ir al enésimo carácter indexando 2N en una matriz de bytes. Tiene que recorrerlo o tener índices de caracteres. De lo contrario, habrá escrito un error.
La especificación actual del borrador de C ++ dice que UTF-32 y UTF-16 pueden tener variantes little-endian, big-endian y no especificadas. ¿En serio? Si Unicode hubiera especificado que todos tenían que hacer little-endian desde el principio, todo hubiera sido más simple. (Yo también habría estado bien con big-endian). En cambio, algunas personas lo implementaron de una manera, otras de otra, y ahora estamos atrapados con tonterías por nada. A veces es vergonzoso ser un ingeniero de software.
Comentarios
Respuesta
No creo que sea perjudicial si el desarrollador es lo suficientemente cuidadoso.
Y deberían aceptar esta compensación si también lo saben bien.
Como desarrollador de software japonés, encuentro UCS-2 lo suficientemente grande y limitar el espacio aparentemente simplifica la lógica y reduce la memoria en tiempo de ejecución, por lo que usar utf-16 bajo la limitación de UCS-2 es suficientemente bueno.
Hay sistemas de archivos u otras aplicaciones que asumen que los puntos de código y los bytes son proporcionales, por lo que se puede garantizar que el número de punto de código sin formato se ajuste a un almacenamiento de tamaño fijo.
Un ejemplo es NTFS y VFAT especificando UCS-2 como su codificación de almacenamiento de nombre de archivo.
Si ese ejemplo realmente quiere extenderse para admitir UCS-4, podría estar de acuerdo en usar utf-8 para todo de todos modos, pero la longitud fija tiene buenos puntos como:
- puede garantizar el tamaño por longitud (el tamaño de los datos y la longitud del punto de código es proporcional)
- Puede usar el número de codificación para la búsqueda de hash
- Los datos no comprimidos tienen un tamaño razonable (en comparación con utf-32 / UCS-4)
En el futuro, cuando la memoria / potencia de procesamiento sea barata incluso en cualquier dispositivo integrado, podemos aceptar que el dispositivo es un poco lento debido a fallas de caché adicionales o fallas de página y memoria adicional uso, pero esto no sucederá en el futuro cercano, supongo …
Comentarios
Responder
«¿Debería uno de los más populares codificaciones, UTF-16, ¿se consideran dañinas? «
Es muy posible, pero las alternativas no deben verse necesariamente como mucho mejores.
El problema 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 están escritos con una escritura basada en latín no están escritos con un solo punto de código Unicode. ¡Y eso está en el extremo más simple de la complejidad!) Lo que esto significa es que hacer todo correctamente es sorprendentemente difícil; se esperan errores extraños (y en lugar de simplemente quejarse de ellos aquí, cuénteles a los encargados del software en cuestión).
La única forma en que UTF- 16 puede considerarse dañino en lugar de, digamos, 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, sí 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, aunque incorrecta, puede en seguir trabajando sin reconstruirlo todo. En otras palabras, al menos puedes ver esos personajes s que no se están manejando bien!
Daría la vuelta a su pregunta y diría que todo el maldito asunto de Unicode debe considerarse dañino y todos deben usar una codificación de 8 bits, excepto He visto (en los últimos 20 años) a dónde lleva eso: una confusión horrible sobre las diversas codificaciones ISO 8859, además de todo el conjunto de las que se utilizan para el cirílico, y la suite EBCDIC, y … bueno, Unicode para todos sus defectos supera a eso . Si tan solo no fuera «un desagradable compromiso entre diferentes países» malentendidos.
Comentarios