El 2004-09-19 a las 10:59 +0200, Camaleón escribió:

No entiendo cómo aún hoy en día el tema de la codificación sigue siendo un problema en los ordenadores... ni que estuviéramos trabajando con Télex. Siempre he dicho que las máquinas "hablan inglés".

;-)

Precisamente ahí está el problema. Los caracteres se representaban por un byte. O mejor dicho, son un byte. Luego, el sistema va y dice que cuando vea un 65 se pinte una 'A'. Si luego otro dice que no es una 'A' sino una 'B', a él le da igual. Esa representacion es arbitraria y humana. Claro, que en esos 255 numeros no se pueden representar todas las letras de todos los idiomas... hay unas cuantas que no cambian de sitio (las 127 primeras), y con las restantes se juega. Pero internamente siguen siendo numeros. Es el usuario el que decide como hay que pintar el número 209 diciendo que es la Ñ mayuscula. Al sistemea operativo le da igual. Simple. Fácil. Eso era antes. Ahora se han inventado el unicode. Ya no son sólo 255 numeros. De hecho, ya no se como hacen, pero tiene que ser con dos digitos, o a veces con dos digitos y a veces con uno y escapes. Y ya está liada la cosa, hasta que todo el mundo se aclare y sepa como leer el nombre de los ficheros. Yo, ahora, ya no se como hacer para manipular un string en unicode. Y no debo ser el único, porque si el konkeror se cuelga... -- Saludos Carlos Robinson

Carlos E. R. wrote:

Eso era antes. Ahora se han inventado el unicode. Ya no son sólo 255 numeros. De hecho, ya no se como hacen, pero tiene que ser con dos digitos, o a veces con dos digitos y a veces con uno y escapes.

Y ya está liada la cosa, hasta que todo el mundo se aclare y sepa como leer el nombre de los ficheros.

Pregunta... ¿no pueden coexistir los dos? Vamos, que si una aplicación / sistema operativo tiene establecido de forma predeterminada la interpretación de ficheros y caracteres en UTF-8 (por ejemplo) pero no puede "traducir" algunos de ellos, debería pasar automáticamente a modo ISO-8859-1, si tampoco puede, pues a otro sistema de codificación (que estén establecidos por el usuario), etc. Es decir, que no sea de carácter exclusivo (o uno u otro) sino suplementario (uno y otro). Saludos, -- Camaleón

El Domingo, 19 de Septiembre de 2004 14:14, Carlos E. R. escribió:

.... Precisamente ah� est� el problema. Los caracteres se representaban por un byte. O mejor dicho, son un byte. Luego, el sistema va y dice que cuando vea un 65 se pinte una 'A'. Si luego otro dice que no es una 'A' sino una 'B', a �l le da igual. Esa representacion es arbitraria y humana.

Claro, que en esos 255 numeros no se pueden representar todas las letras de todos los idiomas... hay unas cuantas que no cambian de sitio (las 127 primeras), y con las restantes se juega. Pero internamente siguen siendo numeros. Es el usuario el que decide como hay que pintar el n�mero 209 diciendo que es la � mayuscula. Al sistemea operativo le da igual. Simple. F�cil.

Eso era antes. Ahora se han inventado el unicode. Ya no son s�lo 255 numeros. De hecho, ya no se como hacen, pero tiene que ser con dos digitos, o a veces con dos digitos y a veces con uno y escapes.

Y ya est� liada la cosa, hasta que todo el mundo se aclare y sepa como leer el nombre de los ficheros.

Yo, ahora, ya no se como hacer para manipular un string en unicode. Y no debo ser el �nico, porque si el konkeror se cuelga...

-- Saludos Carlos Robinson

El unicode es un formato muy sencillo de manejar. De hecho, las primeras implementaciones de unicode eran Wide characters porque pensaron que con 2 bytes habria suficiente para todos los simbolos Bueno la version actual es de 4 bytes, aunque normalmente se usan solo 2. Las tablas de unicode se las puede uno bajar de http://www.unicode.org/ucd/ Os esplicaré brevemente en que consiste. La idea es catalogar todos los símbolos que usamos los humanos, incluso los musicales y de otra índole que pueda ser necesario usarlos en un documento en todo el mundo. A cada símbolo, se le atribuye una etiqueta (desgraciadamente en ingles) pero da igual, de la misma manera que se catalogan los arboles, las plantas, etc. A parte de un catálogo lo más exhaustivo posible de estos símbolos de todas las escrituras a las que han podido acceder esta gente, en su base de datos mantienen archivos que "mapean" codificaciones que se han usado en diversos lugares del mundo y sistemas operativos distintos (por ejemplo mac y windows nunca han usado el mismo juego de caracteres) Gracias a estos catálogos, se pueden UNIFICAR todos los documentos y convertirlos a una representación para todos idéntica. Esta es la gran ventaja de unicode, que da y dará independencia a los programas, facilidades de traducción a dichos programas (aquí uno de los mejores sistemas para hacer aplicaciones bilingües son las QT) Que pasa, que todos los símbolos que se conocen no cabrian jamas en una representación con bytes (del 0 al 255) ni con words (del 0 al 65535) Para asegurarse de que cabrán se usan 4 bytes (del 0 al 4294967296) Creen que nunca se catalogaran tantos símbolos por el momento) Que pasa, que algunos sistemas ya habian medio codificado alfabetos con una version unicode (el Word de Microsoft, y otros procesadores de texto) un poco a su manera, y con 2 bytes. Eso explica que en windows NT y 2000, algunos ficheros de texto, tengan caracteres dobles, 0 los pares y el caracter en los impares. La idea de estos era seguir usando la codificacion CP-1250 y lo que hacian era que si uno de los 2 bytes era un 0 ( el mas significativo), era la codificación CP-1250, si no, era un caracter internacional. Evidentemente, si ahora todos los carácteres que escribimos, en vez de usar 1 byte, usaramos 4, nuestros documentos ocuparian 4 veces mas. Horror, tampoco hay que ir a ese extremo verdad? Para no disparar el tamanyo de los documentos, se inventaron codificaciones de esos 4 bytes de unicode, para ahorrar espacio. Un buen ejemplo de estos y el más extendido es el UTF-8 Cual es la gracia de este sistema?, pues que ahorra mucho espacio y la mayoria de las veces, solo ocupa un byte, (aunque es injusto porque en griego, ruso, xino,etc, nunca ocuparán un solo byte por simbolo, pero ya se sabe, los primeros siempre ganan) La codificación del UTF-8 es muy sencilla. Los valores van siempre del 0 al 127, reservando el ultimo bit para indicar si hay que extender un byte más el codigo. (esto es una codificación de tamaño variable). Si el ultimo bit, es un 1 (byte de 128 a 255), se indica que se necesitan 7 bits mas, y asi, hasta que cabe el codigo de 4 bytes, si es que estos son todos diferentes de 0. Despues de marearos con el unicode, deciros, que en el fondo, es un tema muy interesante incluso para gente que no le guste la informática. Un saludo... -- ################################################ #- Urbez Santana i Roma - #- Email: urbez@linuxupc.upc.es #- Private Web: http://linuxupc.upc.es/~urbez/ ################################################

El Lunes, 20 de Septiembre de 2004 01:02, Carlos E. R. escribió:

El 2004-09-19 a las 21:51 +0200, Urbez Santana Roma escribi�:

...

La codificaci�n del UTF-8 es muy sencilla. Los valores van siempre del 0 al 127, reservando el ultimo bit para indicar si hay que extender un byte m�s el codigo. (esto es una codificaci�n de tama�o variable). Si el ultimo bit, es un 1 (byte de 128 a 255), se indica que se necesitan 7 bits mas, y asi, hasta que cabe el codigo de 4 bytes, si es que estos son todos diferentes de 0.

Ah. Interesante.

Eso quiere decir, que en lugar de tener 4.294.967.296 letras, tenemos "s�lo" 536.870.912, o sea, 2^(32-3)

Y adem�s, quiere decir que todas mis rutinas de manejo de strings y caracteres se me han ido al caraio, con perd�n. Menos mal que ya no programo :-)

-- Saludos Carlos Robinson

Hay un pequenyo detalle, utf-8 conserva el orden de comparación de strings habitual, byte a byte. Que porcierto muchas rutinas antiguas dependen de la codificación. No obstante, no se si alguna vez programando en Windows, no os ha molestado que los controles OCX, usaran wide strings? strings de 2 bytes por caracter? la verdad es que hay muy buenas librerias para manejo de strings utf-8 en QT (KDE) y en GNOME, tambien, las hay a nivel general, open source. Ademas hay otra clase de strings, que no acaban en un 0, y no dependes del cálculo de la longitud que según que aplicaciones que manejan strings es ineficiente. También hay librerias de expresiones regulares para tratar strings en unicode. -- ################################################ #- Urbez Santana i Roma - #- Email: urbez@linuxupc.upc.es #- Private Web: http://linuxupc.upc.es/~urbez/ ################################################