2011-01-15 7 views
7

Sé que la web se está normalizando principalmente hacia UTF-8 últimamente y me preguntaba si había algún lugar donde usar UTF-8 sería algo malo. Escuché el argumento de que UTF-8, 16, etc. pueden usar más espacio, pero al final ha sido insignificante.¿Hay alguna razón para no usar UTF-8, 16, etc. para todo?

Además, ¿qué ocurre con los programas de Windows, el shell de Linux y cosas de esa naturaleza? ¿Se puede usar UTF-8 de forma segura allí?

+0

Para los protocolos existentes que no son compatibles con UTF-8, esa es una buena razón para no usar UTF-8 :) Personalmente solo me gusta apoyar la codificación UTF-8 ya que permite caracteres Unicode mientras permite que mi vida gire en torno al Espacio de caracteres ASCII (la apertura de contenido UTF-16 en un editor "tonto" me hace sangrar los ojos). –

+0

@pst: B e c a u s e l t o o s k i l e t i s e s? – dan04

Respuesta

1

Si UTF-32 está disponible, prefiera eso sobre las otras versiones para el procesamiento.

Si su plataforma admite UTF-32/UCS-4 Unicode de forma nativa, las versiones "comprimidas" UTF-8 y UTF-16 pueden ser más lentas, ya que utilizan números variables de bytes para cada carácter (secuencias de caracteres), lo que hace imposible hacer una búsqueda directa en una cadena por índice, mientras que UTF-32 usa 32 bits "planos" para cada carácter, acelerando algunas operaciones de cadena mucho.

Por supuesto, si se está programando en un entorno muy restringido sistemas como, por ejemplo, incrustados y puede estar seguro de que habrá solamente ASCII o ISO 8859-x caracteres de todo, vez, a continuación, se puede elegir estos juegos de caracteres para eficiencia y velocidad Pero en general, quédese con Formatos de transformación Unicode.

+2

UTF-32 toma 4 veces el espacio de ASCII (o UTF-8 cuando codifica caracteres ASCII) para los mismos datos. Esto definitivamente puede importar. Además, a diferencia de los conjuntos de caracteres "heredados" como ISO-8859- * (y a diferencia de UTF-8), tiene problemas de endianidad de orden de bytes con UTF-32 y UTF-16. – dkarp

+0

["UTF-32 (o UCS-4) es un protocolo para codificar caracteres Unicode que usa exactamente 32 bits para cada punto de código Unicode. Todos los otros formatos de transformación Unicode usan codificaciones de longitud variable. La forma UTF-32 de un personaje es una representación directa de su punto de código. "] (http://en.wikipedia.org/wiki/UTF-32/UCS-4) – dkarp

+0

@dkarp Solo se ha verificado dos veces y tienes razón. Mi mala –

0

Cuando necesite escribir un programa (realizar manipulaciones de cadena) que necesite ser muy rápido y que esté seguro de que no necesitará caracteres exóticos, puede ser que UTF-8 no sea la mejor idea. En cualquier otra situación, UTF-8 debe ser un estándar.

UTF-8 funciona bien en casi todos los programas recientes, incluso en Windows.

+0

Bueno, * puedes * escribir software basado en UTF-8 en Windows (lo he hecho), pero debes evitar funciones como 'fopen' que toman una cadena" ANSI ":-( – dan04

+0

¿En qué? Fopen? ¿Qué idioma? ¿Dije que era imposible escribir software en Windows basado en UTF-8?No entiendo tu punto. O tal vez alguien borró su comentario. –

0

Es bien sabido que utf-8 funciona mejor para el almacenamiento de archivos y el transporte de red. Pero la gente debate si utf-16/32 es mejor para procesar. Un argumento importante es que utf-16 sigue siendo de longitud variable e incluso utf-32 aún no es un punto de código por carácter, entonces, ¿cómo son mejores que utf-8? Mi opinión es que utf-16 es un muy buen compromiso.

En primer lugar, los caracteres fuera del BMP que necesitan puntos de código dobles en utf-16 son extremadamente raros. Los caracteres chinos (también algunos otros caracteres de Asia) en ese rango son básicamente los muertos. La gente común no los usará en absoluto, salvo que los expertos los utilicen para digitalizar libros antiguos. Por lo tanto, utf-32 será un desperdicio la mayor parte del tiempo. No se preocupe demasiado por esos personajes, ya que no harán que su software se vea mal si no los manejó correctamente, siempre y cuando su software no sea para esos usuarios especiales.

En segundo lugar, a menudo necesitamos que la asignación de memoria de cadena esté relacionada con el recuento de caracteres. p.ej. una columna de cadena de base de datos para 10 caracteres (suponiendo que almacenemos cadena unicode en forma normalizada), que será de 20 bytes para utf-16. En la mayoría de los casos, funcionará así, excepto en casos extremos, solo tendrá de 5 a 8 caracteres. Pero para utf-8, la longitud de bytes común de un personaje es 1-3 para idiomas occidentales y 3-5 para idiomas de Asia. Lo que significa que necesitamos 10-50 bytes incluso para los casos comunes. Más datos, más procesamiento.

+0

No estoy de acuerdo con "No se preocupe demasiado por esos personajes, ya que no harán que su software se vea mal si no los manejó correctamente". Decir "Mi programa usa/admite UTF-16" cuando quiere decir "Mi programa usa/soporta un subconjunto de UTF-16" es poco sincero o una mentira descarada. Los errores son una cosa; intencionalmente no es compatible con la totalidad de UTF-16 no es un error. – Kevin

Cuestiones relacionadas