Como evitar problemas en la presentación de acentos y otros caracteres especiales del idioma español en bases de datos Informix

Un problema recurrente en los países de habla hispana es la captura y presentación adecuada de caracteres especiales, tales como las letras acentuadas o palabras con eñe, dentro del motor de base de datos. El presente artículo muestra como configurar adecuadamente el motor de base de datos para realizar la conversión entre los diferentes conjuntos de caracteres, así como dar algunas recomendaciones para evitar diferentes problemas, ajenos a la configuración del motor de base de datos, que impiden ver de manera adecuada la información devuelta por el motor de base de datos desde Windows y Unix.

Aquiles Loranca Sánchez, Accelerated Value Program Engineer, Certified IT Specialist , IBM

Aquiles Loranca es un entusiasta de los productos Informix, así como IT Specialist Certificado por IBM. Inició su carrera en Informix en 1997 como Ingeniero de Soporte Técnico, adquiriendo el nivel de ingeniero Dial-Up en 1998 y actualmente es ingeniero del programa Accelerated Value para productos Informix y DB2 LUW en la organización de Servicios de Software Group. Desde 1996 es profesor en la Universidad La Salle campus Condesa, en la Ciudad de México. Asimismo, es miembro del IIUG (Informix International User Group) y es el enlace de ventas para el grupo local de usuarios de Informix en la Ciudad de México desde 2002. Ha escrito varios DCFs para la organización de Soporte Técnico relacionados tanto con productos Informix como con productos DB2, y ha sido expositor en la serie de conferencias vía Internet "Charla con los Expertos de Informix" en Español.



24-10-2011

Introducción.

Español se escribe con "ñ", y es por eso que un tema común de soporte técnico es como configurar, correctamente, el motor de base de datos para la adecuada presentación de palabras acentuadas, con diérisis, así como de palabras con eñe. Desafortunadamente existen otros factores, ajenos a la configuración del motor de base de datos, que influyen en la manera en la que se insertan y recuperan los datos del tipo alfanumérico en el motor de base de datos Informix®, en este artículo analizaremos las consideraciones de configuración del motor de base de datos relacionadas con la conversión y presentación de los caracteres especiales del idioma español, así como las principales causas por las cuales, aún cuando el motor de base de datos esté bien configurado, éste no almacena o presenta los caracteres de la forma esperada.

Si bien este artículo está dirigido a todos los hispano hablantes, es de mencionar que se estará utilizando los conjuntos de caracteres "en_US" en lugar de "es_ES", ya que éstos primeros son de un uso más frecuente en América Latina. No obstante los conceptos aplican de manera similar para los conjuntos de caracteres del tipo "es_ES". Así mismo es de mencionar que el conjunto de caracteres "en_US" no contempla el ordenamiento de los caracteres acentuados como si fueran letras no acentuadas en datos del tipo NCHAR ó NVARCHAR, quedando esta cuestión fuera del alcance del presente artículo.


Un poco de historia.

Alrededor de la década de 1960, se comenzó a usar el código ASCII (American Standar Code for Information Interchange) para la representación alfanúmerica en sistemas de cómputo, usando un byte para representar un caracter. En su primera versión se usaban solo siete de los ocho bits para el manejo de letras y caracteres de control, pero ninguna letra acentuada, con diérisis o eñe. Con el tiempo el octavo bit se utilizó para presentar caracteres especiales, al que se le denominó ASCII extendido, entre los cuales se incluían acentos, la eñe mayúscula y minúscula, entre otros caracteres especiales. Sin embargo, dada la incapacidad de incluir en 128 caracteres todos los caracteres especiales de la mayoría de los idiomas, se decidió que los caracteres extendidos del ASCII (del 128 al 255), pudieran ser distintos, apareciendo diferentes conjuntos de caracteres (o "character sets") dependiendo del idioma y de la plataforma en la que se visualizaban, lo que implica que la letra "ñ" se podía representar con diferente código interno en diferentes plataformas como Windows, DOS y Unix, e incluso variar de acuerdo al idioma. En el caso de Windows el set de caracteres más usado es el denominado CP1252, en el caso de la ventana de comandos de DOS, para los estados Unidos, el más común es el designado como CP437, y en el caso de Unix, en los paises de habla hispana, se utilza el set de caracteres ISO 8859-1, también conocido como ISO-LATIN-1. El problema con el manejo de estos conjuntos de caracteres es la conversión entre ellos. Así que, en la búsqueda de un código estándar, independientemente de las plataformas, se buscó una alternativa de conjunto de caracteres universales, naciendo el estándar Unicode, teniendo algunas subvarientes, incluyendo el conjunto de caracteres conocido como UTF-8 (Universal-Character-Set Transformation Format 8-bit) que es, en la actualidad, el preferido por los paises que usan actualmente el conjnto de caracteres ISO 8859-1. Este conjunto de caracteres tiene la bondad de ser represenatdo igual independientemente de la plataforma en la que se esté trabajando, sin embrago tiene la peculiaridad de poder almacenar información en más de un byte y que será uno de los escenarios que estaremos revisando más adelante en este artículo.


Manejo de Locales.

Como mencionamos anteriormente, una alternativa para el manejo de caracteres especiales es el uso de diferentes conjunto de caracteres o "LOCALES", específicos al idioma y a la plataforma. Si bien dejaremos fuera de este apartado al conjunto de caracteres UTF-8.

Cuando el cliente y el servidor corren en la misma plataforma, y usan el mismo conjunto de caracteres, no hay mayor problema, pero cuando estamos manejando diferentes tipos de conjunto de caracteres, por ejemplo una aplicación Windows que se conecta a la base de datos a través de un driver ODBC, y éste actualiza la información de una base de datos Informix ® ubicada en un ambiente Linux, necesitamos hacer una conversión del conjunto de caracteres de la aplicación cliente a la aplicación servidor para la captura de información, y la inversa para su consulta. En este caso Informix® provee de dos variables de ambientes para realizar esta conversión:

CLIENT_LOCALE Especifica el LOCALE usado por el cliente, Windows en este caso.

DB_LOCALE Especifica el LOCALE usado por la base de datos en cuestión, Linux en este caso.

Existe una tercera variable de ambiente, denominada SERVER_LOCALE que especifica el LOCALE usado por el servidor de base de datos para sus archivos de uso específico, pero no nos avocaremos a ella en este artículo.

Para saber que LOCALE está usando nuestra base de datos en cuestion podemos usar una búsqueda como la que se muestra a continuación, cambiando "stores_demo" por su base de datos en particular:

En nuestro caso, para la base de datos stores_demo es: "en_US.819", que corresponde al set de caracteres 8859-1 del idioma Inglés de Estados Unidos.

En el caso de Windows, normalmente el set de caracteres usado para Estados Unidos corresponde al LOCALE "en_US.CP1252" aunque recomendamos revisar el caso particular del idioma para su localización geográfica específica.

Para ejemplificar el manejo de estas variables de ambiente y su conversión crearemos una tabla en la base de de datos de demo de informix (stores_demo en mi caso) con una columna del tipo SERIAL y otra del tipo VARCHAR(20), e insertaremos en ella un registro con el valor "áéíóúñÑüÜ1":

El "1" al final nos servirá de testigo para ejemplificar como son tratados los caracteres que no pertenecen al ASCII extendido en nuestras pruebas.

A fin de que podamos ver la misma información tanto en Windows como en Linux, necesitamos configurar de forma explícita el LOCALE usado por el cliente (Windows en este caso) y el LOCALE usado por el servidor (Linux), en el caso de la configuración vía ODBC esto se puede hacer a través del DNS en la pestaña "Environment" del DSN en cuestión.

Gracias a esta configuración podemos capturar y consultar la información, sin importar que sea en Unix, o en programas en Windows que usen se conecten vía ODBC a través de este DSN.

Por ejemplo, en las siguientes pantallas se puede ver la ejecución de la búsqueda:

SELECT * FROM t1;

Desde una herramienta en Windows y desde dbaccess:


Problemas frecuentes ajenos a la configuración del motor de base de datos.

Como mencionábamos anteriormente, existen factores externos a la configuración del motor de base datos que pueden ocasionar que la captura o la consulta a los datos con caracteres especiales no se realice como se desea, a continuación presento las principales causas con las que me he encontrado, sin que se pretendan abordar de forma exhaustiva todas los causas que lleven a este tipo de comportamiento.

La primera y más común es el uso de una herramienta que no utilice el conjunto de caracteres que necesitamos. En el ejemplo anterior no usé una ventana de DOS con el comando telnet. El motivo es que el comando telnet invocado desde la ventana de DOS, no usa el conjunto de caracteres "ISO 8859-1", si no el conjunto de caracteres de DOS (CP437 en mi caso), como resultado de esto la salida a mostrar se parecerá a esta:

Como podemos ver es un problema grave, por que si bien no podemos consultar la información de la manera adecuada, al capturar acentos desde la ventana de DOS podemos estar insertando caracteres para los que no existan valores correspondientes en otras plataformas, dando lugar a mensajes de error de conversión de caracteres del tipo: "Inexact character conversion during translation".

Por lo que debe asegurarse de usar un emulador de terminal que pueda manejar el conjunto de caracteres usado por su base de datos.

Asimismo, es posible que estemos usando la herramienta adecuada pero no la configuración adecuada. Por ejemplo, ejecutemos la misma búsqueda pero ahora desde el emulador de terminal de nuestra consola en Linux:

Observe que ni siquiera aparece el "1" al final. Lo que sucede es que en este caso el emulador de terminal usó el conjunto de caracteres UTF-8, por ser éste el LOCALE por omisión para el shell de sistema operativo:

Pero cambiándolo al conjunto de caracteres adecuado (Western (ISO-8859-1) en este caso), la salida es completamente distinta:

Esto también puede aplicar para otras herramientas como el cliente de telnet o ssh que utilice en su ambiente Windows. Asegúrese siempre de que el conjunto de caracteres usado por su emulador de terminal coincida con el conjunto de caracteres usado por la base de datos.


El caso particular de UTF-8.

Como hemos visto en el apartado anterior, el manejo de UTF-8 merece un trato aparte. UTF-8 en la actualidad es un recurso particularmente popular tanto en bases de datos, como en el desarrollo de aplicaciones por su capacidad de intercambio estandarizado, independientemente de la plataforma, sin embargo existen algunas consideraciones que deben observarse respecto al manejo de UTF-8 en Informix®.

En el caso de una base de datos creada con en_US.UTF-8, el valor del campo dbs_collate de la tabla sysdbslocale de la base de datos sysmaster será "en_US.57372"

Es de observarse que una base de datos de Informix® que no haya sido creada como UTF-8 no puede ser convertida automáticamente a UTF-8. Debe ser exportada a archivos planos, recreada como Unicode y cargada nuevamente. Para tener más detalle sobre la conversión a Unicode recomiendo la presentación dada por Mark Jamison en la conferencia internacional del Grupo Internacional de Usuarios Informix (IIUG) en 2008, cuyo enlace incluyo en la sección de recursos adicionales.

Asimismo, otra consideración importante, es que el conjunto de caracteres UTF-8 para los caracteres del ASCII extendido usan más de un byte, esto puede ocasionar que se use más espacio para guardar los caracteres especiales, como eñes o acentos, así como en índices que los incluyan.

Adicionalmente, al igual que sucedió con el ejemplo de una terminal configurada para manejar UTF-8 al acceder a una base de datos creada con conjunto de caracteres 8859-1, debemos tener cuidado de configurar nuestro emulador de terminal para manejar UTF-8 cuando estemos accediendo a una base de datos creada con este conjunto de caracteres. A continuación se muestra la salida de una terminal que explota el registro que insertamos con el campo: "áéíóúñÑüÜ1", pero ahora consultado de una base de datos Unicode con DB_LOCALE configurado a en_US.UTF8 y con la terminal configurada para usar el conjunto de caracteres 8859-1:


Como se puede observar, los caracteres especiales ocupan dos bytes en este caso, y son completamente ilegibles, tan sólo se puede leer el número "1" al final. Al cambiar el tipo de conjunto de caracteres a UTF-8 toda la salida es perfectamente legible.


Conclusión.

El manejo caracteres especiales en lenguas como el español, implican problemáticas específicas de presentación en pantalla y de conversión que afectan a una gran cantidad de usuarios Informix®.

En este artículo hemos revisado como configurar adecuadamente las variables de ambiente DB_LOCALE y CLIENT_LOCALE a fin de poder manejar diferentes conjuntos de caracteres entre la aplicación cliente y la base de datos.

Así mismo se han revisado las principales causas, externas a la configuración de la base de datos, que impiden ver de manera adecuada la información devuelta por el motor de base de datos Informix®

Por último que no menos importante, se ha revisado las principales implicaciones del uso del conjunto de caracteres UTF8 en una base de datos Informix®.


Recursos:

Moving to Unicode

http://www.iiug.org/iiug08/C09_Jamison_Moving_To_Unicode.pdf

Use IBM Informix 4GL to develop applications that support UTF-8 character sets

http://www.ibm.com/developerworks/data/library/techarticle/dm-0910informix4glutf8

Internationalizing UDRs

http://www.ibm.com/developerworks/data/zones/informix/library/techarticle/db_gls.html

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=767457
ArticleTitle=Como evitar problemas en la presentación de acentos y otros caracteres especiales del idioma español en bases de datos Informix
publish-date=10242011