Programación de aplicaciones con datos Unicode y varios CCSID
Si la aplicación maneja datos Unicode o datos que están en esquemas de codificación diferentes, debe tener en cuenta varias técnicas de programación y recomendaciones en Db2.
Db2 siempre devuelve datos a la aplicación en el CCSID que utiliza la aplicación para los datos. Este CCSID se denomina esquema de codificación de la aplicación.
Consejo : Siga las siguientes recomendaciones generales para escribir y preparar sus programas de aplicación.
- Si es posible, utilice datos Unicode o EBCDIC, pero no ambos. Si elige utilizar varios esquemas de codificación, tenga en cuenta las posibles implicaciones de pérdida de datos y rendimiento:
- Gestionar varios CCSID en su aplicación puede resultar difícil. Para asegurarse de no perder los datos, debe controlar adónde van los datos, una vía de acceso que puede incluir muchos módulos.
- Muchos entornos, como CICS® Transaction Gateway y IBM® MQ , se basan en mensajes. En estos casos, todo el mensaje debe estar en un único esquema de codificación. Puesto que todo el mensaje está en una codificación, el flujo de unos datos por la aplicación en EBCDIC y otros en Unicode tiene poco sentido. Todavía debe convertirlos todos en una única codificación, como Unicode, justo antes de realizar la transmisión del mensaje.
- Las tablas de Db2 deben estar en el mismo esquema de codificación. No puede hacer que unas columnas sean Unicode y otras sean EBCDIC. Si su aplicación procesa unas columnas en Unicode y otras en EBCDIC, se producirá la conversión de caracteres, lo que probablemente aumentará la sobrecarga del rendimiento.
- Si utiliza datos Unicode en aplicaciones COBOL o PL/I, utilice el coprocesador.
- Si su aplicación COBOL, PL/I, C/C++ o de ensamblador gestiona datos Unicode, no coloque literales en el código fuente de la aplicación. Dado que estos compiladores de lenguaje no admiten código fuente Unicode, pueden interpretar erróneamente estos valores literales. En su lugar, coloque estos valores literales en un archivo o en una tabla de Db2 donde se pueda acceder al inicio del programa para cargar los valores. (Los archivos y las variables host no se precompilan ni compilan como código fuente de la aplicación.)
- Si en los datos se produce una conversión con expansión o con contracción, la longitud de los datos podría cambiar. Tenga en cuenta que esta longitud cambia cuando se utilizan las funciones LENGTH, CHARACTER_LENGTH, SUBSTRING y SUBSTR con la serie convertida. Para CHARACTER_LENGTH y SUBSTRING, utilice las opciones CODEUNITS16 y CODEUNITS32 para especificar cómo desea que Db2 calcule la longitud.
- Si necesita representar caracteres de varios conjuntos de caracteres basados en el alfabeto latino, como Latin-1 y Latin-4, plantéese utilizar Unicode para el esquema de codificación de su aplicación. Un CCSID SBCS no tiene suficientes elementos de código para representar todos los caracteres que la combinación de los dos conjuntos de caracteres requiere. Por ejemplo, supongamos que su aplicación utiliza un CCSID EBCDIC, como el 277 o el 1069. Es posible que tenga datos representados en la base de datos en Unicode, pero que la aplicación no pueda recuperarlos sin una sustitución. Si su aplicación debe manejar un lenguaje cada vez, puede configurar su infraestructura de una de las formas siguientes:
- Disponga una versión de su aplicación que utilice el CCSID 277 y otra versión que utilice el CCSID 1069. Disponga también dos subsistemas correspondientes, uno que utilice el CCSID 277 y otro que utilice el CCSID 1069. (No puede tener varios CCSID EBCDIC en un subsistema Db2.)
- Almacene los datos en Unicode y disponga una versión de su aplicación que utilice el CCSID 277 y otra versión que utilice el CCSID 1069. A continuación, enlace estas aplicaciones con diferentes valores para la opción de enlace ENCODING.
- Almacene los datos en Unicode y disponga una versión de su aplicación que utilice un CCSID EBCIC y otra versión que utilice Unicode.