[Olpc-uruguay] Difícil la Red !!

[Francisco Castro]

2010年 08月 31日 �曜日 23:29:45 UYT��juan carlos escobar samurio�書����:
> Me presento. Mi nombre es Juan Carlos Escobar Samurio, soy estudiante del 3º
> de Informática de la UTU. Este año nos enseñaron, aunque refiriendonos a
> Visual Basic 6, de que cada caracter Unicode (los cuales en Visual basic se
> declaran como string) ocupan un byte por caracter. [...]

No, no es así.

Unicode lo que define es una relación entre caracteres y números, así a
la 'a' lo relaciona con el 97, a la 'ñ' con el 241, a 'Σ' con 931, y a
'例' con 20363. Por eso Unicode es un 'charset'.

El máximo número que utiliza unicode es 0x10FFF, un poco más de 20
bits, o sea 21 bits. Lo importante es que unicode no define en sí mismo
la manera de guardar en memoria o transmitir en paquetes estos números.

Y aquí es donde aparecen los 'encodings', es un concepto distinto, ya
que también define el método utilizado para guardar estos números
asociados a los caracteres, y por ejemplo, los que tenemos comunes por
la vuelta, son: ASCII, ISO 8859-1, UTF-8, UTF-16, UTF-32.

ASCII: Ocupa un byte por caracter, pero solo permite utilizar los
primeros 128 caracteres de unicode. Por lo que no admite ni tildes, ni
eñes, ni caracteres cirílicos ni griegos ni persa, etc... Se suele
indicar el final del string con un byte en 0.

ISO 8859-1: Es el que se usaba comúnmente por estos lares hasta hace no
tanto. Solamente permite en un byte utilizar los caracteres de unos
cuantos idiomas romances (pero poca cosa más); por eso mismo inventaron
varias variantes en ISO 8859 por ejemplo el 8859-4 para idiomas
escandinavos, 8859-6 para árabe, etc...

Y mientras que del otro lado del mundo utilizaban ISO 2022, EUC, SJIS,
Big5, entre tantos otros, se creó el concepto de Unicode para de una vez
por todas tener una asociación única en el mundo, entre caracteres y
números. Basados en unicode, se definieron los siguientes 'encodings':

UTF-8: Es el que normalmente se utiliza en todos los sistemas
'GNU/Linux' modernos como en las XO, y posee grandes ventajas: Es
compatible con ASCII (ya que los primeros 128 caracteres de unicode
coinciden con ascii) y utiliza 1 byte para representar estos caracteres,
y define un algoritmo que permite especificar los 21 bits de caracteres
de unicode (unicode completo) utilizando entre 2 a 4 bytes. También
queda reservado el byte 0 para indicar el fin del string, y además por
la forma en como fue diseñado, se puede recorrer tanto para adelante
como para atrás (cosa que no siempre ocurre).

UTF-16: Se utiliza en algunos sistemas de archivos, en algunos
protocolos raros, internamente en java y .net, y poca cosa más, ya que
en general no aporta ventajas significativas sobre UTF-8. Utiliza 2
bytes para especificar la mayoría de los caracteres de Unicode, y provee
un mecanismo obscuro y con pobre soporte para especificar los no tan
comunes en 4 bytes. Suele ser necesario agregar al principio del texto
una cierta marca odiosa llamada BOM para distinguir el UTF-16BE del
UTF-16LE, tan solo para indicar el orden que se usa al almacenar los 2
(o 4) bytes de cada caracter; cabe destacar que esto genera un montón de
problemas.

UTF-32: Se utiliza internamente en unos cuantos entornos, incluído
python al utilizar el formato u'string'. Provee (al igual que ISO
8859-1), la ventaja de que direccionar el i-ésimo caracter en O(1), sin
necesidad de recorrer el string, ya que todos los caracteres ocupan 4
bytes.

Por ejemplo, el texto 'Hola' ocupa 4 bytes en ISO 8859, 4 bytes en
UTF-8, (4*2+2)=10 bytes en UTF-16 y (4*4)=16 bytes en UTF-32.

El texto 'Cañón' ocupa 5 bytes en ISO 8859, 7 bytes en UTF-8, 10+2 bytes
en UTF-16 y 20 bytes en UTF-32.

El texto '長����' ya no se puede representar en ISO 8859, ocupa 15
bytes en UTF-8, 10+2 bytes en UTF-16, y 20 bytes en UTF-32.

Espero que esta introducción al mundo de los encodings quede clara, y
que utilicen UTF-8 ya que es el mejor :P

PD: Los que ven cuadraditos en lugar de kanji, sepan que ahí había texto
en japonés sin demasiado valor didáctico (más allá de servir de ejemplo).

Reitero: Usen UTF-8.

-- 
Francisco Castro
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 197 bytes
Descripción: Digital signature
Url        : http://lists.laptop.org/pipermail/olpc-uruguay/attachments/20100901/751d2aa0/attachment.pgp