Archivo del sitio

Las bases de datos gritonas: una explicación a Unicode

Cuenta la cultura de Internet que escribir todo en mayúsculas es gritar, parte de la “etiqueta de Internet” (o Netiqueta) surgió de las nuevas formas de comunicación, como los BBS y los foros de discusión que llevaron incluso a la IETF a categorizar dichas reglas de etiqueta en un RFC (RFC 1855).

Es por eso que, ¡SI LES ESCRIBO ASÍ LES ESTOY GRITANDO!, ¡OYERON! …

“El grito” en bases de datos

En los inicios, cuando sólo existía ASCII, las cadenas de texto sólo podían ser representados con algunos de los 127 carácteres de 7-bit representados en la tabla ASCII:

Para los niveles de almacenamiento de la época era más que suficiente, además la cantidad de “idiomas” incorporados a la computación además del inglés era “casi nula”, así que ASCII vivió sus días de Gloria escribiendo bases de datos con simples y hermosas letras (mayúsculas y minúsculas) no acentuadas.

Sin embargo, las computadoras almacenaban bytes de 8-bits, así que nos sobraba “un bit”, muchas personas alrededor del mundo tuvieron ideas “diferentes” de cómo representar más carácteres, en general, la forma más popular fue el estandar ANSI-ISO/IEC 8859, que “más o menos” mantenía intactos los primeros 128 carácteres pero agregaba otros más como “la eñe” y la á acentuada.

Esto creó un grave problema para los “trabajadores” de las bases de datos, que ahora tenían que lidiar entre JOSE, JoSE, JOSé y JOSÉ como derivaciones del mismo escrito (pero a nivel lógico, cadenas completamente diferentes), convenciones como “todo debe escribirse en mayúsculas y sin acentos para evitar problemas” comenzaron a surgir.

Otro punto a favor de este mito ocurrió con los Code-pages, cada “idioma” en ISO-8859 tenía su propia “codificación” (ejemplo: para el alfabeto latino era ISO-8859-1) por lo que el ISO-233 (é latina con acento agudo) en el conocido latin1, representa la letra yā (ي) en ISO-8859-6 árabe lo cual significaba DESASTRE a la hora de mover aplicaciones de datos de un idioma a otro.

En definitiva, el mundo en los 90 eran distintos, apenas “saliendo” de la guerra fría, nadie se le hubiera ocurrido tener más de un idioma en un mismo computador, mucho menos almacenar datos en diversos idiomas.

Y en eso llegó Internet …

Con Internet vino el advenimiento de las comunicaciones globales y de hecho, se “enraizaron” los fundamentalistas que, con más razón, las bases de datos debían almacenar los datos con la menor complejidad posible, incluso, si eran 7-bit ASCII, que fueran los octales más bajos (las letras mayúsculas), y así se ha mantenido muchísimas cosas hasta ahora.

Con Internet llegó UNICODE, y con él una mejor forma de escribir todos los caracteres posibles inventados por el hombre (UTF-7, 8, 12 ó 16).

Unicode en parte se sincroniza con ASCII-7 en sus primeros carácteres (por eso, ARBOL en ASCII y ARBOL en UTF8 se representan igual), sin embargo “Árbol” o “ñandú” se representan con carácteres acentuados en valores octales distintos en ISO-8859-1 y en UTF-8.

¿y el espacio?

Como es imposible representar miles y miles de carácteres con solamente 8-bits, entonces UNICODE echa mano del multi-byte, es decir, un glifo o carácter puede requerir más de un byte para representarse, algunos dicen “Unicode es un sistema de 16-bits por ende una cadena UNICODE mide más que una cadena ASCII o Latin1”, es entendible este error común acerca de un encoding multi-byte, pero es errado.

En general, Unicode es multi-byte, así que aquellos (y sólo aquellos) glifos que no pudieran ser representados con 8-bits serán representados con más de un byte; ejemplo, una A ocupa los bits “0100 0001”:

A -> 0100 0001

A mide 8-bits, por ende, en UTF-8, los carácteres de la tabla desde 0-127 serán representados por un solo BYTE (la razón por la cual, “ARBOL” en ISO-8859-1 y “ARBOL” en UTF-8 lucen exactamente idénticos), el resto de carácteres y glifos serán representados por combinaciones de 2 y hasta 6 bytes.

Un buen ejercicio es crear en postgreSQL 2 bases de datos, una en SQL ASCII y otra en UTF-8, llenarla con cadenas regulares y preguntar ¿cual mide más?:

He creado una tabla “testnames”:

CREATE TABLE testnames
(
 id serial NOT NULL,
 test character varying,
 CONSTRAINT pk_test PRIMARY KEY (id)
)

La cual hemos llenado con 1000 cadenas sencillas:

insert into testnames(test) select * from  repeat('abcdef',1000);

Y luego le preguntamos a TOAST cuanto miden ambas tablas:

select pg_column_size(test), pg_column_size(repeat('abcdef',1000)) FROM testnames;

Lo cual es *no* sorprendentemente el mismo resultado:

pg1

abcdef mide exactamente igual (en bytes) en UTF-8 que en ISO-8859-1 (32Kb en espacio en disco).

¿Dónde queda la META?

El gran culpable de esta discusión es el carácter de error de encoding o -> � el cual tristemente aparece en más páginas web de las que uno se imagina; pero para algo que se cura con:

Content-Type: text/html; charset=UTF-8

O usando XML con:

<?xml version="1.0" encoding="UTF-8"?>

No entiendo por qué para “evitar” tener que codificar y re-codificar adecuadamente (o forzar una codificación en las aplicaciones a nivel programático) entonces ¿por qué no seguir escribiendo con únicamente los primeros 128 carácteres de la tabla ASCII?

Porque vivimos en un mundo globalizado.

¡YO NO ME LLAMO ASÍ!

En efecto, nuestro hermoso idioma, el español, difiere en muchísimas cosas del inglés (que valgame Dios, puede ser escrito bien con ASCII, UTF-8, ISO-8859-1 y con *casi* cualquier codepage o charset que exista), empezando por su nombre y esa letra N con sombrerito sinuoso (la Virgulilla o “rabo e’ cochino” para los venezolanos), pero igual de hermoso es el cirílico, el arameo o el árabe, por ende, pretender decirle al mundo que toda cadena plana y llana es un ASCII es un absurdo.

De hecho, como leí por allí alguna vez ¡”no existe esa cosa mal llamada el *texto plano*”, punto!.

Hay miles de millones de personas leyendo en idiomas y codificaciones de carácteres que van más allá del carácter 127, hay que respetarlos.

¡Y no!, mi nombre, mientras la Real Academia Española de la Lengua no derogue los acentos es Jesús, no es JESUS ni jesus; Es *Jesús*, con la J mayúscula (en señal de un nombre) y con la ú acentuada, es que incluso, si se escribe en mayúsculas, es ¡JESÚS!, esa regla que algunos se inventaron de que “las cosas en mayúsculas no se acentúan” no existe.

La codificación Moderna

El último incoveniente viene de la adaptación, mientras algunos profesores universitarios aún dan clases de bases de datos con viejos dinosaurios como FoxPro (ASCII), Access (ISO-8859-1) ú Oracle 8 (ANSI UNICODE) (todas de fines de los 90, cuando UTF-8 estaba en pañales) en la actualidad, interactuar con usuarios de diferentes codificaciones viene reflejado por simplemente ejecutar un:

SET NAMES = 'UTF8'

E incluso, bases de datos modernas como PostgreSQL soportan diversas codificaciones entre bases de datos y diversas versiones (COLLATIONS) de UNICODE incluso en una misma tabla, con columnas en diferentes locales; además, “ARBOL” y “arbol” y “Arbol” son completamente iguales si usamos ILIKE y otros tipos de búsquedas no-sensibles al uso de mayúsculas.

Dejo de gritar …

¡Oye!, ¡Qué ese pájaro no se llama Ñandú, sino NANDU! …

La posibilidad infinita de permitirle a una persona escribir su nombre, correctamente, con todas sus letras, acentos y carácteres diacríticos es para mí, más que suficiente, para adaptarme y hacer conversiones de CHARSET a conveniencia, hacer operaciones de “Capitalizado” y “lowercase” y agregar etiquetas META correctamente, que tener que almacenar sólo 127 carácteres por ahorrarme unos pocos bytes y un esfuerzo de codificación (y decirle a la gente que no se llama como lo registraron en su partida, sino como a mí, el DBA de turno, me da la gana llamarlo).

A ver si nos modernizamos un poco y abandonamos ese hueco en la arena donde te escondiste con tu ANSI SQL89 y tu SQL ASCII y nos alzamos de patas como las Suricatas, para ver que hay un hermoso mundo que describir allá afuera …

… y por favor, ¡con acentos!.

A %d blogueros les gusta esto: