No dejes de divulgar nuestro sitio y códigos con tus amigos, apóyanos para ampliar esta comunidad.
Solución:
UTF-8 puede almacenar el rango completo de Unicode, por lo que está bien usarlo para árabe.
Sin embargo, si se pregunta qué codificación sería más eficiente:
Todos los caracteres árabes se pueden codificar usando una sola unidad de código UTF-16 (2 bytes), pero pueden tomar 2 o 3 unidades de código UTF-8 (1 byte cada una), por lo que si solo estuviera codificando árabe, UTF-16 lo haría ser una opción más eficiente en cuanto al espacio.
Sin embargo, no solo está codificando árabe; está codificando una cantidad significativa de caracteres que se pueden almacenar en un solo byte en UTF-8, pero toman dos bytes en UTF-16; todos los caracteres de codificación html <,&,>,= y todos los nombres de los elementos html.
Es una compensación y, a menos que esté tratando con documentos grandes, no importa.
Desarrollo principalmente sitios web en árabe y estas son las dos codificaciones que utilizo:
1. Windows-1256
Esta es la codificación más común que usan los sitios web en árabe. Funciona en la mayoría de los casos (90%) para usuarios árabes.
Aquí está uno de los foros de desarrollo web árabe más grandes: http://traidnt.net/vb/. Puede ver que están usando esta codificación.
El problema con esta codificación es que si está desarrollando un sitio web para uso internacional, esta codificación no funcionará con todos los usuarios y verán galimatías en lugar del contenido.
2. UTF-8
Esta codificación resuelve el problema anterior y también funciona en urls. Quiero decir, si quieres tener palabras en árabe en tu URL, necesitas que estén en utf-8 o no funcionará.
La desventaja de esta codificación es que si va a guardar contenido árabe en una base de datos (por ejemplo, MySql) usando esta codificación (por lo que la base de datos también se codificará con utf-8), su tamaño será el doble de lo que hubiera sido. si estuviera codificado con windows-1256 (por lo que la base de datos se codificará con latin-1).
Sugiero ir con utf-8 si puede permitirse el aumento de tamaño.
UTF-8 está bien, sí. Puede codificar cualquier punto de código en el estándar Unicode.
Editado para agregar
Para que la respuesta sea más completa, sus opciones realistas son:
- UTF-8
- UTF-16
- UTF-32
Cada uno viene con ventajas y desventajas.
UTF-8
Como señala Joe Gauterin, UTF-8 es muy eficiente para textos europeos, pero puede volverse cada vez más ineficaz cuanto más se "aleja" del alfabeto latino. Si su texto es todo árabe, en realidad será más grande que el texto equivalente en UTF-16. Sin embargo, esto rara vez es un problema en la práctica en estos días de RAM barata y abundante, a menos que tenga mucho texto con el que lidiar. Más problema es que la longitud variable de la codificación hace que algunos string Operaciones difíciles y lentas. Por ejemplo, no puede obtener fácilmente el quinto carácter árabe en un string porque algunos caracteres pueden tener 1 byte de longitud (puntuación, digamos), mientras que otros tienen dos o tres. Esto hace real Procesando de cadenas lentas y propensas a errores.
Por otro lado, UTF-8 es probablemente su mejor opción si está haciendo muchos mixed Texto europeo / árabe. Cuanto más texto europeo en sus documentos, mejor será la elección de UTF-8.
UTF-16
UTF-16 le brindará una mayor eficiencia de espacio que UTF-8 si utiliza predominantemente texto árabe. Sin embargo, no sé sobre los puntos de código árabe, por lo que no sé si corre el riesgo de tener codificaciones de longitud variable aquí. (Sin embargo, supongo que esto no es un problema). Si, de hecho, tiene codificaciones de longitud variable, todas las string Los problemas de procesamiento de UTF-8 también se aplican aquí. Si no, no hay problema.
Por otro lado, si tienes mixed Textos europeos y árabes, UTF-16 será menos eficiente en el espacio. Además, si se encuentra expandiendo sus formas de texto a otros textos como, por ejemplo, chino, definitivamente regresa a las formas de longitud variable y los problemas asociados.
UTF-32
UTF-32 básicamente duplicará sus requisitos de espacio. Por otro lado, tiene un tamaño constante para todas las formas de script conocidas (y, probablemente, desconocidas). Para crudo string el procesamiento es la mejor y más rápida opción sin los problemas que le ocasionará la codificación de longitud variable. (Esto presupone que tienes un string biblioteca que sabe sobre caracteres de 32 bits, naturalmente.)
Recomendación
Mi propia recomendación es que utilice UTF-8 como formato externo (porque todo el mundo lo admite) para almacenamiento, transmisión, etc. a menos que De Verdad vea un beneficio en términos de tamaño con UTF-16. Así que cada vez que lees un string desde el mundo exterior sería UTF-8 y cada vez que pones uno en el mundo exterior, también sería UTF-8. Sin embargo, dentro de su software, a menos que tenga el hábito de manipular cadenas masivas (¡en cuyo caso recomendaría diferentes estructuras de datos de todos modos!), Recomendaría usar UTF-16 o UTF-32 en su lugar (dependiendo de si hay alguna problemas de codificación de longitud variable en sus datos UTF-16) para la eficiencia de la velocidad y la simplicidad del código.