Archivos Mensuales: octubre 2014

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!.

[OpenLDAP] Password policies

He incorporado una nueva entrada sobre openLDAP, referente a los password policies (política de contraseñas).

Puedes leerla acá: http://blog.phenobarbital.info/2014/10/openldap-password-policies/

Del por qué Lácteos los Andes usa UPC y no EAN

y otras absurdas afirmaciones …

 

Mientras dictaba una charla-taller de postgreSQL y programación en PL/Python, se me ocurrió hacer algo bastante simpático y que a Python se le da bastante bien y es una operación matemática, más especificamente para validar el código de barras de los productos (código EAN) y puse a mis compañeros a escribir una sencilla función en PL/Python y que, combinada con un Dominio, funcionaba de maravilla.

Eso, me llevó a escribir el siguiente artículo en mi blog técnico.

para saber más: http://blog.phenobarbital.info/2014/10/crear-un-dominio-en-postgresql-para-validar-codigos-de-barra/

 

Sin embargo un resultado imprevisto surgió de dicho ejercicio, y es que al taller nos enviaban refrigerios variados de Lácteos Los Andes (naranjada y jugos) y al intentar probar nuestra función de códigos de barra, los códigos de barra de dichos productos fallaban …

¿Cómo puede ser eso?, ¿cómo la industria láctea “bandera” del Estado Venezolano puede estar emitiendo códigos de barra corruptos en sus propios productos? …

Pues para quien no lo crea, acá una foto:

Choco-Lat Lacteos Los Andes

Choco-Lat Lacteos Los Andes

El producto es un “Choco-Lat”, bebida achocolatada hecha por Lácteos Los Andes en las plantas de Nueva Bolivia, Estado Mérida y Cabudare, Estado Lara, también lo verifiqué en el Papelón con Limón y el jugo mixto.

codigo_barras

Entre otras cosas:

  • El código tiene un valor par (12) de longitud, lo que lo hace un UPC Americano (Universal product Code)
  • Aunque el código de empresa está bien (709862) al no empezar en cero (0709862) falla el reconocimiento por ser un código de producto erróneo para el checksum digit asociado.
  • Si el código de producto fuera 01201 y no 01301, el checksum sería 4, el código sería: 709862012014 y la función indicaría que es un código válido.
  • 709 es el código GS1 para Noruega (en EAN)
  • El Global Trade Item Number válido para ese producto debería ser: 00709862013011

Tal vez Lácteos Los Andes buscaba “ahorrarse dólares con GS1” dirán alguien por allí, sin embargo, este es un trámite que sugiere el propio organismo regulador SENCAMER (Una institución del Estado) y la representación de GS1 en Venezuela (Adscrita a FONDONORMA) emite códigos EAN completamente gratis a las empresas que se inscriban y paguen una membresía anual en GS1 de Venezuela.


GLN 0709862000004
UPCPrefix 709862
GS1Prefix 0709862
CompanyName Lacteos Los Andes, C.A.
StreetAddress Apartado 51442
City Caracas
ZipCode 1050-A
StateProvince
Country Venezuela
PrefixStatus Active
ModifiedDate 2013-11-22T00:00:00

¿Por qué entonces, en vez de usar códigos EAN universalmente aceptados, echa mano de códigos UPC americanos?

Como dice la propia página de GS1:

GTIN-12 (UPC-A): this is a 12-digit number used primarily in North America

Esta bien, ellos son buena-nota con el Imperio y decidieron etiquetar no con el universal EAN-13 o GTIN-14 sino con UPC-A americano y pagar los 2500US$ (con renovación anual de 500US$) que UCC exige por usar el código, mientras que en Venezuela, con el apoyo de SENCAMER, le pagas una membresía anual en bolívares a GS1 de Venezuela, con emisión de códigos EAN-13 completamente GRATIS.

Pero no, UPC/GTIN-12 es un código más chevere, porque tal vez pensamos exportar papelón con limón para USA.

Sigan mi nuevo (viejo) blog!

Mi blog phenobarbital.info se había quedado sin hosting por casi un año, he vuelto a recuperarlo de sus respaldos y está ahora online.

Será netamente técnico con algunas dosis de frikismo geek, así que los espero por allá y lo sigan tanto como a este.

Si notan mucha publicidad en ese blog, bueno, les pido disculpas de antemano, el blog está en un hosting VPS que se debe pagar y aunque trato en lo posible de seguir en mi ruta de publicar lo más que pueda sobre software libre y abierto en español, necesito cubrir los gastos del VPS y los ads son una forma de hacerlo.

Espero no les molesten mucho, le den algunos “clicks” y mantengan vivo ese blog.

 

Gracias y por allá los espero!.

 

[OpenLDAP] Bitácora de instalación

He decidido recuperar mi blog técnico, y para comenzar su uso, he incluído una completa guía de instalación, configuración y personalización del servicio de directorio OpenLDAP bajo Debian GNU/Linux.

Espero poder contar con sus visitas y comentarios en esta nueva etapa de documentación en mi blog.

Gracias y allá nos vemos!

A %d blogueros les gusta esto: