Lo hice y lo entendí

El blog de Vicente Navarro
15 jun

Juegos de caracteres: ASCII, CP850, ISO-8859-15, Unicode, UTF-8, etc.

Hemos hablado ya en algunas entradas anteriores sobre juegos de caracteres:

Si bien muchos visitantes pueden tener claro ¿qué es un juego de caracteres?, también es posible que muchos otros se sientan un poco perdidos entre todas estas siglas y no entiendan por qué los nombres de los ficheros o su contenido, que se ven bien en un sistema operativo, no se ven bien en otro.

Teoría básica de ordenadores es que éstos sólo saben de unos y ceros. Afortunadamente, con unos y ceros, gracias al sistema binario se puede representar cualquier número. Por tanto, los ordenadores básicamente sólo saben manejar números.

Parecerá una perogrullada, pero en este punto es necesario recordar que las letras no son números. Mientras que los unos y ceros se convierten en un número decimal como los que solemos usar de forma natural, no hay ninguna regla matemática que asocie unos y ceros con una letra.

Sin embargo, sí que podemos definir reglas arbitrarias para que los ordenadores puedan trabajar con letras asociando letras/caracteres determinados a un número determinado, lo que llamaremos “juego de caracteres. El juego de caracteres más famoso es el ASCII (American Standard Code for Information Interchange), creado en 1960 para los teletipos de la época. Es un sistema en el que a cada carácter le asignamos un número de 7 bits (del 0 al 127) que nos permite tener 128 caracteres, de los cuales 33 son de control necesarios en los antiguos teletipos pero mayormente obsoletos hoy en día, y los 95 restantes son los números 0-9, las letras mayúsculas (sin la “Ñ”) A-Z, las letras minúsculas (sin la “ñ”) a-z, así como los siguientes signos de puntuación:

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

En este sistema, por ejemplo a la “a” le corresponde el número 97 y a la “J” el número 74.

Es evidente que el juego de caracteres ASCII presenta una visión bastante anglocéntrica de la informática, ya que es excluyente con todas las personas que tenemos el vicio de usar lenguas distintas al inglés y necesitamos caracteres como la ñ, la ç o la ß. Es por eso que cuando los teletipos quedaron atrás y los ordenadores trajeron los “bytes” o, lo que es lo mismo, los números de 8 bits (del 0 al 255), los juegos de caracteres pudieron empezar a usar 128 caracteres más de los que tenía ASCII, en los que se incluyeron los símbolos necesarios para idiomas europeos diferentes al inglés.

A finales de los 80 yo hacía mis pinitos en BASIC con un Amstrad PC-1512 usando el GW-BASIC de Microsoft sobre lo que debía ser alguna versión de MS-DOS 3. Me encantaba ponerle cuadritos a todo con unos caracteres gráficos muy chulos que tenía el sistema que permitían hacer cuadros de una línea, de dos líneas o de combinaciones de una y dos líneas:

│ ─ ┼ ┤ ├ ┴ ┬ ┐ ┌ ┘ └ ║ ═ ╬ ╣ ╠ ╩ ╦ ╗ ╔ ╝ ╚ ╫ ╪ ╡ ╞ ╢ ╟ ╧ ╤ ╨ ╥ ╖ ╙ ╜ ╓ ╕ ╛ ╘ ╒

Eran los precursores de los cuadros de diálogo actuales:

╒════╤╤════╕
│    ││    │
╒══╪════╧╧════╪══╕
│  │          │  │
╔══╪══╛          ╘══╪══╗
║  │   RECORDANDO   │  ║
╟──┤      LOS       ├──╢
║  │ VIEJOS TIEMPOS │  ║
╚══╪══╕          ╒══╪══╝
│  │          │  │
╘══╪════╤╤════╪══╛
│    ││    │
╘════╧╧════╛

Pues bien, precisamente mi primer palo a causa de los juegos de caracteres vino precisamente por estos caracteres gráficos. Cuando yo me llevaba mi programita en BASIC a otro PC resulta que mis cuadraditos no se veían como en el PC donde yo lo había programado sino que salían letras acentuadas y caracteres raros.

En aquellos momentos no sabía por qué ocurría eso, pero hoy en día sé que lo que me pasaba era que yo había desarrollado mi programita en un sistema que usaba el juego de caracteres de MS-DOS CP437, que es el que se usa en sistemas ingleses, mientras que todos los otros ordenadores estaban configurados para usar el juego de caracteres CP850, el estándar en países de Europa Occidental de habla no inglesa.

El CP437, aunque contiene bastantes caracteres de lenguas no inglesas, como muchas vocales acentuadas y la eñe, curiosamente, se dejó muchos otros absolutamente necesarios en otros idiomas, como es el caso de casi todas las vocales acentuadas en mayúsculas Á, Í, Ó, Ú (la É si está). Sorprendentemente, en cambio lleva un símbolo de de pesetas “₧”, cuando en realidad en España siempre usábamos la abreviatura “Ptas”, con letras. Todas estas curiosidades sobre la -mala- internacionalización del CP437 las podemos leer en la WikiPedia:

CP437 has a series of international characters, mainly values 128 to 175 (80H to AFh). However, it lacks many characters important to several Western languages:

  • It lacks many characters for Spanish (Á, Í, Ó, Ú), French, (À, Â, È, Ê, Ë, Ì, Î, Ï, Ò, Ô, Œ, œ, Ù, Û), and Portuguese (Ã, ã, Õ, õ).
  • It has umlauts for German (Ä, ä, Ö, ö, Ü, ü), but sharp S (ß) must be represented with the beta symbol (β).
  • It has Scandinavic Æ, æ, Å, å, but lacks Ø and ø (character number 237, empty set, may be used as a surrogate, but is not properly displayed within a word).

Along with the cent (¢), pound sterling (£) and yen/yuan (¥) currency symbols, it has a couple of European currency symbols, for the florin (ƒ, Netherlands) and the peseta (₧, Spain). The presence of the last is a real surprise, since the Spanish peseta was never an internationally relevant currency, and also never had a symbol of its own; it was simply abbreviated as “Pt”, “Pta”, “Pts”, or “Ptas”. The only related fact is that Spanish models of the IBM electric typewriter also had a single type devoted to it.

El CP850 contiene los símbolos gráficos necesarios sólo para hacer gráficos de una o de dos líneas pero no los símbolos necesarios para combinar una y dos líneas y justamente esos, los de las esquinas e intersecciones, eran los que eran reemplazados por caracteres internacionales como letras acentuadas:

│ ─ ┼ ┤ ├ ┴ ┬ ┐ ┌ ┘ └ ║ ═ ╬ ╣ ╠ ╩ ╦ ╗ ╔ ╝ ╚

El CP437 resulta que es el juego de caracteres que viene por defecto en las tarjetas de vídeo VGA (y antes de ella, las EGA, CGA y MDA). Por tanto, es el que se usa incluso hoy en día para mostrarnos la BIOS, el que se usa en GRUB y el de los primeros instantes del arranque de Linux. También es el juego de caracteres de por defecto de MS-DOS hasta que se ejecutan los famosos comandos de los ficheros de arranque de MS-DOS que cargan el juego de caracteres 850 en nuestra consola EGA/VGA:

CONFIG.SYS:

COUNTRY=034,850,C:\DOS\COUNTRY.SYS
DEVICE=C:\DOS\DISPLAY.SYS CON=(EGA,,1)

AUTOEXEC.BAT:

MODE CON CODEPAGE PREPARE=((850) C:\DOS\EGA.CPI)
MODE CON CODEPAGE SELECT=850

Y precisamente esto era lo que me pasaba con mi famoso programita: que lo había desarrollado en un PC que no tenía ni CONFIG.SYS ni AUTOEXEC.BAT ni ninguna inicialización mínima y, por tanto, yo usaba el CP437, mientras que el resto de PCs en España usaban el CP850.

A diferencia de ASCII que es un juego de caracteres de 7 bits, tanto el CP437 como el CP850 son juegos de caracteres de 8 bits, con 256 posibles caracteres. Los caracteres del 32 al 127 son los mismos que los de ASCII.

Otro juego de caracteres de 8 bits muy importante es el ISO-8859-1, también llamado a menudo latin1, estandarizado en 1992. Es el juego de caracteres que se ha usado durante mucho tiempo típicamente en Linux, aunque poco a poco, cada vez es más común el uso de UTF-8. De los 256 posibles caracteres sólo tiene 191 asignados: los de ASCII, algunos signos de puntuación más y caracteres necesarios para un soporte casi completo de los idiomas europeos basados en letras latinas. Sin embargo, no lleva los caracteres gráficos para hacer cajas de CP850. Bien al contrario, el CP850 sí que contiene todos los caracteres que hay en el ISO-8859-1, pero en un orden totalmente distinto que no tiene ningún sentido y que dificulta enormemente la ordenación alfabética. Seguro que por eso la organización ISO redefinió el orden.

Estos son los caracteres internacionales de ISO-8859-1. Podemos ver que están perfectamente clasificados por mayúsculas/minúsculas y en orden alfabético:

À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö Ø Ù Ú Û Ü Ý Þ ß à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ø ù ú û ü ý þ ÿ

Estos son los caracteres internacionales de CP850. Podemos ver que su ordenación es totalmente arbitraria:

Ç ü é â ä à å ç ê ë è ï î ì Ä Å É æ Æ ô ö ò û ù ÿ Ö Ü ø Ø á í ó ú ñ Ñ Á Â À ã Ã ð Ð Ê Ë È Í Î Ï Ì Ó ß Ô Ò õ Õ þ Þ Ú Û Ù ý Ý

Windows no usa CP850 como hacía MS-DOS, sino que usa el juego de caracteres Windows-1252. Windows-1252 es un superconjunto de ISO-8859-1, de forma que contiene los 191 caracteres de ISO-8859-1 y además rellena muchos de los 32 huecos que éste dejaba hasta rellenar casi todos los huecos disponibles.

Cuando llegó el Euro, Microsoft incluyó el caracter del Euro (€) en la posición 128 del Windows-1252 y para MS-DOS creó el CP858, que reemplazaba la i sin punto (ı) del CP850 por el símbolo del Euro. ISO, por su lado, estandarizó el ISO-8859-15 (también llamado latin9), que reemplazaba algunos dignos de puntuación del ISO-8859-1 por el símbolo del Euro y por algunos caracteres internacionales que faltaban:

€ Š š Ž ž Œ œ Ÿ

Pero claro, si antes decíamos que el ASCII era “anglocéntrico”, todos estos juegos de caracteres que hemos comentado son “latinocéntricos”, ya que al ser de 8 bits, con sólo 255 caracteres posibles como máximo, se dejan fuera a todos los caracteres de idiomas no basados en el latín. Y, de hecho, otros idiomas tienen muchos más símbolos que 255, como el Chino o el Japonés.

Por eso se estandarizó el Unicode. Unicode es un juego de caracteres que asocia unos 100.000 símbolos con otros tantos números, siendo los primeros 256 los mismos que los de ISO-8859-1. Esos 100.000 símbolos permiten trabajar con textos de casi cualquier idioma existente, y normalmente cara uno de ellos se expresa como “U+el número de caracter en hexadecimal”, siendo, por ejemplo, j=U+006A, Á=U+00C1, Ɛ=U+0190, tal y como podemos comprobar en la tabla de caracteres Unicode de la Wikipedia: Mapping of Unicode Characters.

Sin embargo, 100.000 números no caben ni en 8 bits (256 como máximo) ni en 16 bits (65536 como máximo). Necesitamos, como mínimo, 17 bits, de modo que, sabiendo que los procesadores manejan enteros de 8, 16, 32, 64, 128 bits, etc., vemos que teóricamente necesitaríamos al menos 32 bits para almacenar un carácter Unicode. Pero usar 4 bytes en almacenar cada carácter es un absoluto despilfarro, especialmente si usas un idioma europeo occidental y todos los símbolos que necesitas caben en un sólo byte. Es por eso que se inventaron diferentes formas de codificar el Unicode. Las más conocidas y usadas son UTF-8 y UTF-16, pero hay varias más.

UTF-8 usa:

  • 1 byte para codificar los 128 caracteres de ASCII
  • 2 bytes para codificar los caracteres latinos internacionales (p.e. la á, la ñ o la ç) así como algunos alfabetos como el griego, cirílico, hebreo y árabe.
  • 3 bytes para codificar los caracteres restantes del Basic Multilingual Plane, un subconjunto de Unicode que incluye la prácticamente todos los caracteres Unicode necesarios.
  • 4 bytes para el resto

UTF-16 usa:

  • 2 bytes para los caracteres del Basic Multilingual Plane
  • 4 bytes para el resto

UTF-8 es la codificación de Unicode que cada vez más se usa en Linux. UTF-16 es la codificación de Unicode que usa Windows desde Windows 2000. Windows NT usaba UCS-2, una codificación obsoleta casi igual a UTF-16 pero que no permite la posibilidad de usar más de 2 bytes, por lo que esos “caracteres extra” que necesitan dos palabras de 2 bytes no se pueden representar.

Así, si creamos un fichero en Windows/Unicode/UTF-16 con el siguiente contenido:

Palabras con eñe y acentos como último, camión o herejía.

y lo examinamos con la utilidad hexdump, veremos que, efectivamente, cada letra usa dos bytes, siendo el primero siempre 00:

$ hexdump -C fichero_UTF16.txt 
00000000  ff fe 50 00 61 00 6c 00  61 00 62 00 72 00 61 00  |..P.a.l.a.b.r.a.|
00000010  73 00 20 00 63 00 6f 00  6e 00 20 00 65 00 f1 00  |s. .c.o.n. .e...|
00000020  65 00 20 00 79 00 20 00  61 00 63 00 65 00 6e 00  |e. .y. .a.c.e.n.|
00000030  74 00 6f 00 73 00 20 00  63 00 6f 00 6d 00 6f 00  |t.o.s. .c.o.m.o.|
00000040  20 00 fa 00 6c 00 74 00  69 00 6d 00 6f 00 2c 00  | ...l.t.i.m.o.,.|
00000050  20 00 63 00 61 00 6d 00  69 00 f3 00 6e 00 20 00  | .c.a.m.i...n. .|
00000060  6f 00 20 00 68 00 65 00  72 00 65 00 6a 00 ed 00  |o. .h.e.r.e.j...|
00000070  61 00 2e 00 ff fe 0a 00                           |a.......|

Si guardamos el mismo fichero en UTF-8, veremos que esta vez sólo se usa más de un byte en la eñe y en los acentos, para los que se usan dos bytes. En este caso, se necesita casi la mitad de espacio:

$ hexdump -C fichero_UTF8.txt 
00000000  50 61 6c 61 62 72 61 73  20 63 6f 6e 20 65 c3 b1  |Palabras con e..|
00000010  65 20 79 20 61 63 65 6e  74 6f 73 20 63 6f 6d 6f  |e y acentos como|
00000020  20 c3 ba 6c 74 69 6d 6f  2c 20 63 61 6d 69 c3 b3  | ..ltimo, cami..|
00000030  6e 20 6f 20 68 65 72 65  6a c3 ad 61 2e 0a        |n o herej..a..|
0000003e

La omnipresencia de los juegos de caracteres

Los juegos de caracteres están por todos los lados. Nos rodean. Cada vez que escribas o leas un texto en un ordenador, piensa que en la caché, en la memoria, en el disco duro, cada letra está representada por un número de 1, 2, 3 o 4 bytes. Siempre se usa uno, no puede ser de otra forma. Normalmente no nos importa cuál se use. Usamos el que venga por defecto en el sistema y ya está.

El problema viene cuando queremos compartir datos y ficheros entre distintos sistemas. Y no sólo estoy hablando de compartir ficheros entre Windows y MS-DOS o entre Windows y Linux. El problema también puede ocurrir entre dos Windows o entre dos Linux si tienen juegos de caracteres distintos. Incluso cuando Linux, sin comunicarse con nungún Windows, accede a un sistema de ficheros de Windows como FAT o NTFS o viceversa. En estos casos tenemos que asegurarnos de convertir los ficheros y datos convenientemente.

De cómo conservar los caracteres en los nombre de fichero ya he hablado antes en las entradas que mencionaba al principio. Sólo me gustaría recordar de dichas entradas que la utilidad para Linux convmv (con paquete disponible en Debian) puede ser una forma bastante sencilla de convertir nombres de ficheros de un sistema de caracteres a otro si necesitamos hacerlo.

Esta vez me gustaría acentuar el hecho de que el contenido del los ficheros, al igual que ocurría con sus nombres, también usan un juego de caracteres. Incluso en Windows, donde el sistema suele intentar abstraernos de cualquier cosa que huele mínimamente a bajo nivel, tenemos claros ejemplos de la necesidad de saber un poco qué son los juegos de caracteres. Sin ir más lejos, ahí tenemos el bloc de notas de Windows, probablemente la utilidad más sencilla que pueda haber: un programa que no podría tener menos opciones (abrir, guardar, copiar, pegar, selección de fuente y poco más). Pues bien, hasta el bloc de notas de Windows nos da la opción, cuando abrimos un documento y cuando lo guardamos, para elegir la codificación de caracteres que queremos usar:

Con este ejemplo nos podemos dar cuenta de la relevancia de tener siempre en cuenta la codificación de caracteres que estamos usando.

Por cierto, Microsoft tiene una forma peculiar de llamar a las codificaciones de caracteres: ANSI es Windows-1252, Unicode es UTF-16, y UTF-8 es UTF-8.

El WordPad también permite elegir el juego de caracteres, pero curiosamente, nos permite leer y grabar de formato MS-DOS (CP850), nos permite usar “Unicode” (que en realidad es UTF-16) y no nos permite seleccionar UTF-8:

El Notepad++ es un editor de texto con licencia GPL para Windows que aconsejo fervientemente a todos aquellos que a menudo trabajen con ficheros de texto en Windows. Entre muchas otras útiles funcionalidades, fijaos en qué bien dotado está en el apartado de la gestión de la codificación de los caracteres:

Por supuesto, como tantas otras veces, Linux no sólo no se queda atrás, sino que es capaz de superar a Windows en funcionalidad. Incluso el sencillo editor de textos de GNOME nos permite elegir cualquier juego de caracteres para abrir y para guardar nuestros ficheros:

Además, en la línea de comandos de Linux, tenemos la excelente utilidad iconv para convertir entre juegos de caracteres:

$ echo "Palabras con eñe y acentos como último, camión o herejía." | \
iconv -f UTF-8 -t iso-8859-15 > fichero_ISO-8859-15.txt

$ cat fichero_ISO-8859-15.txt
Palabras con e�e y acentos como �ltimo, cami�n o herej�a.

$ iconv -f iso-8859-15 -t UTF-8 fichero_ISO-8859-15.txt > fichero_UTF-8.txt

$ cat fichero_UTF-8.txt 
Palabras con eñe y acentos como último, camión o herejía.

Cuando hablamos de juegos de caracteres, no tenemos que olvidarnos de la fuente que usamos para mostrar el contenido. Hemos dicho que Unicode contiene unos 100.000 caracteres: ¿Tienen todas las fuentes que solemos usar todos los 100.000 caracteres? La respuesta es que no. Fijémonos en que a veces hay fuentes que ni siquiera tienen acentos y eñes, conque imaginémonos si tendrán los caracteres arábicos o hebreos.

Es por eso que aunque abramos un fichero codificado en, por ejemplo, UTF-8 o UTF-16, si la fuente que nos muestra su contenido no contiene un determinado símbolo, no lo veremos bien.

El UTF-8 and Unicode FAQ for Unix/Linux menciona el fichero UTF-8-demo.txt, un fichero que, codificado en UTF-8, contiene multitud de caracteres de los que nosotros consideraríamos extremadamente poco habituales. Puede ser un buen ejercicio abrir dicho fichero (especificando que es UTF-8, claro) para ver qué partes del texto aparecen correctamente y cuáles no.

Usando el Text Editor de GNOME, por ejemplo, gracias a la librería Pango podemos ver el UTF-8-demo.txt casi perfecto, aunque tenemos que fijarnos en que los caracteres diferentes a los latinos que no existan en la fuente seleccionada actualmente los coge de otras fuentes que sí que los tenga, y lo podemos comprobar en el hecho de que aunque cambiemos la fuente, éstos no cambian:

En cambio, en Windows no se produce tal reemplazo. Si abrimos el UTF-8-demo.txt con el Notepad++ y la fuente por defecto, la Courier, vemos que muchos símbolos no son mostrados:

Para solucionar este problema, Microsoft tiene la fuente Arial Unicode (Description of the Arial Unicode MS font in Word 2002), una fuente de unos 22MB que contiene una selección de caracteres muchísimo más amplia con la idea de que sea usada en todos los casos en los que nos falte algún símbolo, aunque siguen sin estar todos los que aparecen en UTF-8-demo.txt:

Los navegadores (Firefox, Internet Explorer, etc.), siendo como son uno de los vehículos para mostrar textos más usados hoy en día, también tienen que considerar los juegos de caracteres.

En esta misma página, en el código HTML, inmediatamente tras el <html><head> lo primero que aparece es:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

siguiendo las recomendaciones del W3C (Setting the HTTP charset parameter). En este caso UTF-8 porque la base de datos de WordPress está codificada así, pero también podría haber sido:

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

o

<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

Esto nos permite escribir el documento HTML en el juego de caracteres que queramos, aunque si queremos hacerlo independiente de éste, podemos usar caracteres ASCII y usar los caracteres nombrados que tiene HTML (Character Entities in HTML & XHTML). Por ejemplo, para escribir la “á” podemos poner &aacute;, y para escribir la “Ñ” podemos poner &Ntilde;. Asimismo, podemos usar cualquier caracter Unicode poniendo su número en decimal o hexadecimal. Por ejemplo, para escribir el caracter Unicode U+8449, que es 葉 podemos poner en el HTML &#33865; o &#x8449; (Unicode and HTML).

Si el documento HTML no llevara un Content-Type/charset, siempre podríamos especificarlo a mano en el menú que todos los navegadores llevan a tal efecto:

Los juegos de caracteres no sólo están en los ordenadores. ¿No te ha pasado nunca que te hayan mandado un SMS con el móvil y que los acentos y las eñes no hayan llegado bien? Eso es porque el servicio de SMSs por GSM contempla tres posibles alfabetos: uno de 7 bits con el que podemos mandar 160 caracteres y que no incluye la mayoría de vocales acentuadas pero sí la eñe mayúscula y minúscula, uno de 8 bits con el que podemos mandar 140 caracteres y otro Unicode con el que sólo podemos mandar 70 caracteres.

En mi móvil actual, cuando comienzo a escribir un SMS me dice que tengo 0/160 caracteres disponibles, pero tan pronto como escribo una vocal acentuada me dice que sólo tengo 1/70 caracteres disponibles. Eso es porque pasa a usar el alfabeto Unicode y no el de 8 bits. Cuando pongo una eñe me sigue dejando usar 160 caracteres. Curiosamente, con el móvil que tenía antes no me pasaba esto y me dejaba usar 160 caracteres incluso con caracteres acentuados. Si no me equivoco, porque usaba un juego de caracteres de 7 bits diferente al GSM 03.38 y por eso los caracteres “especiales” podían no salir bien en terminales de otros fabricantes o de otros países:

Moraleja: Los juegos de caracteres nos rodean y están por todos lados, así tenemos que saber que están ahí y conocerlos para que no nos pillen por sorpresa.

¿O nunca has rellenado un formulario para comprar un vuelo sin acentos pensando en que si los ponías seguro que el nombre o la dirección saldrían mal?

¿O nunca has hecho una transferencia de dinero a través de tu Banco/Caja por Internet y los acentos y las eñes te han aparecido en el justificante que te envían después con caracteres raros?

Es la desgracia que tenemos de no haber sido los europeos los que inventáramos la informática e Internet y que lo hayan hecho los anglosajones. Y menos mal que la mayor parte de caracteres que usamos son los mismos que los del inglés. Imaginémonos qué problemas deben de tener frecuentemente los japoneses, chinos, árabes, rusos, griegos, tailandeses, etc.

:wq

Entradas relacionadas

17 Comentarios a “Juegos de caracteres: ASCII, CP850, ISO-8859-15, Unicode, UTF-8, etc.”

  • David dice:

    Muy buen artículo, ahora me queda más claro todo el tema de los juegos de caracteres que siempre me había vuelto bastante loco.

  • Maks3w dice:

    Es un artículo imprescindible para completar el anterior.

    Muy bueno, si señor.

  • AlBundy dice:

    Toda esta información puede encontrarse sin problemas en la red; lo relamente difícil es juntarla y componer con ella un único artículo que resulte coherente. Y tú lo has logrado. En 2 palabras: im-presionante.

    Sólo me limitaré a aportar mi granito de arena sobre los caracteres gráficos para hacer recuadros en modo texto.
    La consola de Linux permite hacer menús simples usando estos caracteres gráficos a la manera de los antiguos terminales. Concretamente, el kernel emula el primitivo soporte para “gráficos” de los terminales VT100, que consistía en los 32 caracteres del DEC Special Graphics Character set. El código octal correspondiente a cada uno de estos 32 caracteres podemos averiguarlo en la tabla 3-9 de la guía de usuario del VT100 ( http://vt100.net/docs/vt100-ug/ ).

    En http://vt100.net/dec/vt220/glyphs aparecen los glifos que un VT220 era capaz de representar en pantalla (no he sido capaz de encontrar un gráfico con sólo los glifos del VT100). Los 32 caracteres gráficos que el kernel es capaz de representar corresponden a las 2 primeras columnas de los gráficos.

    Para usar estos caracteres gráficos, debemos entrar en un “modo gráfico”, algo que se consigue, obviamente, con las secuencias de escape que se indican en console_codes(4). Si queremos volver a “modo normal”, usaremos otra secuencia de escape. Ejemplos (cuidado con las comillas simples):


    echo -e 'e(0`abcdefghijklmnñopqrstuvwxyz{}|~e(B'


    echo -e 'e(0lqqqqqqwqqqqqqqknx HOLA x MUNDO xntqqqqqqnqqqqwqqunx x x xnmqqqqqqvqqqqvqqje(B'

    El modo gráfico DEC sólo será de utilidad a aquellos que todavía sigan (sigamos) usando codificaciones ISO-8859-[1-15], ya que estas codificaciones no soportan caracteres gráficos. Por el contrario, Unicode sí soporta caracteres gráficos con barras simples, dobles y mezcladas ( http://en.wikipedia.org/wiki/Western_Latin_character_sets_%28computing%29 ), por lo que podemos usarlos directamente, siempre y cuando nuestro comando echo entienda la utilización de caracteres unicode (u).

    Saludos

  • Iker dice:

    Excelente articulo. Ahora lo entiendo mucho mejor.

  • Tito dice:

    Excelente artículo, como todos los demás.

    Cuando paso un CD de música a mp3, primero extraigo a formato wav. Para poner los tag del mp3 (canción, autor, año, etc), escribo esta información en un fichero de texto plano de unha forma conveniente. Utilizo un script, que extrae los datos de este fichero y junto con lame, procede a comprimir y añadir los tag. Para que el texto salga correctamente en los mp3, hay que transformar de utf-8 a CP1252, que hago con

    iconv -f UTF-8 -t CP1252

    Con el formato ogg vorbis no hay que convertir nada.

    Saludos,

  • @David, @Maks3w, @Iker ¡Gracias!

    @AlBundy Pues gracias por partida doble por completar la entrada con esa información tan interesante. La verdad es que aunque alguna vez he usado terminales como los que comentas, nunca me había parado a pensar en cómo gestionarían lo de los juegos de caracteres.

    @Tito Muy interesante el ejemplo de los ID3. Nunca me había fijado en que esa también es una importante fuente de problemas con los juegos de caracteres. La WikiPedia (ID3) comenta algunos de dichos problemas. ¡Gracias!

  • Bytecoders dice:

    Muy buen artículo. A mí también me pasa lo que tu comentas con los SMS y no había caído en que viniera por el juego de caracteres.

    Realmente una entrada muy interesante.

  • Iván dice:

    Otro artículo para guardar y tenerlo de referencia. Lo tendré que leer de nuevo más despacio para terminar de asimilarlo bien.

    Saludos, Iván.

  • Ringmaster dice:

    Excelente aportación a la enciclopedia del conocimiento global.
    Veo que también utilizas el potente Notepad ++ :-)

  • @Bytecoders, @Iván, @Ringmaster ¡Gracias!

  • Soledad dice:

    Hola: me podés explicar entonces, como es posible que en un windows todas mis letras acentuadas aparezcan con símbolos “rusos”, y como hago para cambiarlos? Me pasa sobre todo en los menúes y en las ventanas de instalación.

  • @Soledad Revisa si tienes todo correcto en el diálogo de “Opciones Regionales” del “Panel de Control”. Es posible que tengas por ahí seleccionado en alguna de las pestañas algún idioma diferente al Castellano.

  • Soledad dice:

    Hola, gracias por tu comentario, pero no, no es eso… ya me he fijado, y re fijado y recontra fijado, he entrado y salidos al panel de control un millón de veces, pero nada… no es ese el problema…
    Alguna otra sugerencia????
    Saludos.
    Soledad

  • sonia dice:

    excelente articulo, lo he aplicado pero me salen simbolos raros “�” , tengo un archivo xml en utf-8 y una hoja de estilo xsl que lo transforma tambien en utf-8 realizo la conversion en el servidor (windows) mediante una pagina asp, pero salen con codificacion utf-16, alguien me podria decir a que deba esto.
    Gracias

  • telenauta dice:

    Tito dijo:
    para que el texto salga correctamente en los mp3, hay que transformar de utf-8 a CP1252, que hago con

    Solo un comentario: eso solo es necesario para tags id3v1. Con tags id3v2 ya se soporta unicode y no hace falta convertirlos.

  • Juan Felipe dice:

    Cordial saludo,

    Tengo un problema con un sitio que estoy desarrollando, resulta que cuando lo escribí, el notepad++ lo tenía configurado con formato ANSI y los formularios los tenía con accept-charset=”utf-8″ de igual forma en el meta charset=”utf-8″; el problema es que estoy intentando validar mi sitio segun la especificacion de la W3C y me genera el error “Sorry! This document can not be checked.”, según parece el tipo del archivo influye en esto, cosa que no sabía.

    Ahora no sé como hacer para no tener que modificar el formato de todos los archivos que componen el sitio y para no tener que cambiar de utf-8 a ANSI ya que tengo comentarios y publicaciones almacenadas con el juego de caracteres utf-8. Ahora, el otro inconveniente que tampoco me percaté cuando inicié el desarrollo de la aplicacion es que la base de datos se diseñó con cotejamiento latin1_swedish_ci.

    Mejor dicho no resuelvo todavía como arreglar mi sitio ya que en funcionalidad está correcta y permite y muestra caracteres especiales de forma correcta, pero no cumple con los estandares de la W3C, que es lo que estoy buscando.

    Espero que alguien me pueda dar una solucion teniendo en cuenta todas estas variables, Gracias.

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro