Etiqueta

Mostrando entradas con la etiqueta #UNICODE. Mostrar todas las entradas
Mostrando entradas con la etiqueta #UNICODE. Mostrar todas las entradas

13 julio 2016

Como convertir caracteres Apple MacRoman a Unicode

Aunque "raras", existen las ocasiones en que vamos a necesitar obtener el correspondiente carácter en formato unicode, partiendo de su codificación no-unicode. En mi caso la razón es que dispongo de una fuente de caracteres Mac OS X para representación de códigos de barras, en formato no-unicode y necesito usarla desde su correspondencia unicode.

Buscando en internet, encontré una tabla con las diferencias que se pueden encontrar entre sus códigos ascii y que extracto a continuación...

...como se puede observar existen diferencias entre la codificación Mac y Unicode, por ejemplo alcaracter ê le corresponde el código 144 (no-unicode) y el 234 en formato unicode.

La manera de obtener dicho carácter en su formato unicode, partiendo de su ascii 144, sería la siguiente...
Do byteset(lBin,0,144)
Do uniconv(kUniTypeNativeCharacters,lBin,kUniTypeCharacter,lChar,kFalse,lErrorText)
...donde lBin es una variable local de tipo binario, mientras que lChar y lErrorText son de tipo carácter. La ejecución de éste código de notación, almacenará en la variable lChar el caracter ê convertido a unicode.

16 abril 2014

Soporte Multilingüe

Soporte Multilingüe con Omnis Sudio (Opción Built-in)


A partir del estudio 5.0.1, es posible editar los textos utilizados por Omnis, lo cual permite personalizarlo para adaptarlo a sus preferencias y diferencias del idioma, corregir problemas deribados del uso de diferentes teclados o cambiar la combinación de teclas a utilizar en la activación de opciones. Todos los textos personalizados serán guardados sobre el archivo “studio.stb”.

Tenga en cuenta que Omnis cargará automáticamente sólo los textos incluidos en “studio.stb”, que se correspondan con la columna cuyo nombre sea coincidente con el consignado en el parámetro “$language” de las preferencias Omnis. (Añada o edite los diferentes idiomas mediante la librería “omnisloc.lbs”, que podrá hallar bajo el directorio 'local' del raíz Omnis Studio).

Los siguientes ejemplos, muestran como cambiar los atajos de teclado asignados a la opción de mostrar la lista de tipos de letra y a la que permite comentar o des-comentar líneas de código:

Lista de tipos de letra

 

  • Presione F9 (Cmd-9 en Mac) para abrir el Catálogo.
     
  • Vaya a la pestaña "StringTable", y busque la entrada "Built-in Strings". Haga clic derecho y seleccione "Find strings", esto le permitirá localizar el STRINGID de cualquier texto utilizado por Omnis.
     
  • Sitúese sobre el cuadro de búsqueda y escriba "[] (list font size)”, haga clic derecho y cópielo sobre el portapapeles.
     
  • Ahora vuelva de nuevo al Catálogo, haga clic derecho sobre "Built-in Strings" y seleccione la opción "Edit built-in strings". Esto abrirá el editor “String Table”, mediante el cual, podremos componer nuestra traducción y/o personalización del texto.
     
  • Si es necesario añada una nueva fila a continuación de la columna STRINGID, pegue el contenido del portapapeles. Cambie el nombre de la primera columna, utilizando el código de país que corresponda a su preferencia "$language", por ejemplo, si es el español, cambie el nombre de la columna por "ES_es".
  • Copie el STRINGID sobre su columna con el texto a personalizar y cambie los símbolos "[]" por los 2 caracteres que desee utilizar.

Guarde los cambios y salga del editor "String Table", si el valor actual de la propiedad "$language" coincide con el nonbre dado a la columna que contiene el texto traducido, las nuevas teclas de acceso directo estarán listas para su uso.

Comentar o des-comentar líneas de código (Comment/Uncomment)


Por defecto, usted puede comentar o des-comentar las líneas de código previamente seleccionadas sobre el editor de métodos, mediante la pulsación de las teclas Cmd/Ctrl y ";" o "’", a continuación indicamos como cambiarlas para usar en su lugar las teclas que desee.

Para conseguirlo simplemente repita los pasos descritos en el aparado anterior, pero buscando ahora el texto "comment". Seleccione después la línea "2846!~Comment Selected Lines\; 2221", añada una fila más a la tabla de textos y situándose sobre la columna que contiene sus textos personalizados, cambie solamente el carácter “;” por la combinación de teclas que desee.

Haga lo mismo para "2847!~Uncomment Selected Lines\' 2222", cambiando el carácter "’".


Yendo más lejos


Los ejemplos anteriores ilustran los procesos que intervienen en la personalización de teclas de acceso directo. El mismo enfoque se puede utilizar para personalizar cualquier texto de los utilizados por Omnis mediante simplemente buscarlo para después editarlo, puede encontrar más información sobre como añadir soporte multi-lenguaje a sus aplicaciones Omnis, en el articulo publicado en Bastiaan's blog: http://bastiaanolij.blogspot.com.es/2013/05/part-5-adding-multi-lingual-support.html

Resumen

  1. Desde el catálogo, haga clic sobre la pestaña “STRINGTABLE”.
  2. Haga clic derecho sobre "Built-in strings" y seleccione la opción "Edit Built-in Strings" 
  3. Esto abrirá el editor “String Table” con esta tabla especial vacía (excepto la primera línea que contiene el ID A)
  4. Luego haga clic derecho en "Built-in strings" y seleccione la opción "Find Strings"

La ventana de búsqueda nos permite realizar búsquedas de textos localizaod en el “Studio Core“, los “dam’s”, y otras librerías del entorno Omnis, en ellas encontraremos los textos que queramos traducir, naturalmente primero tendremos que tener claro que es lo que queremos traducir para poderlos buscar, normalmente desearemos traducir aquello que afecta a la interface del usuario y no lo correspondiente al entorno de programación Omnis Studio.

09 abril 2014

De No-Unicode a Unicode (Parte 10 de 10)

Conclusión


En esta serie de 10 artículos, he querido hacer una breve explicación sobre como Omnis Studio aborda la compleja cuestión de la codificación Unicode. Seguramente a usted ahora le surjan algunas preguntas sobre esto, le animo a que las platee, en el grupo “omnisstudio” (http://groups.google.com/group/omnisstudio?hl=es). Si le ha parecido útil la información le pediría deje algún comentario, comparta la información en las redes sociales o al menos haga “click” en +1.

Estaré agradecido por cualesquiera preguntas y/o comentarios desee plantear sobre el tema a la comunidad omnis. A través de éste blog seguiré atento ante cualquier novedad que se presente en las futuras actualizaciones de Omnis Studio.

Es posible que usted ya haya actualizado sus versiones no-Unicode de Omnis a Unicode, si es así, ¿Porqué no plantearse ahora la internacionalización de su aplicación? Ahora es posible, con algo de esfuerzo podrá extender el abanico de clientes hasta lugares insospechados, quien sabe si Japón o China. ¿Ya ha hecho ésto también? Entonces le animo a que comparta su experiencia con la creciente comunidad Omnis de habla hispana.

Muchas gracias por la atención prestada durante la publicación de esta serie.

Reciba un cordial saludo.

02 abril 2014

De No-Unicode a Unicode (Parte 9 de 10)

Localización


Con el termino “localización” Omnis hace referencia al proceso previo necesario, para la distribución de una aplicación entre clientes finales localizados en diferentes países y que por tanto usan diferentes grafías de caracteres e idioma. En la práctica, esto significa que tendremos que traducir cualquier texto que sea visible al cliente a los idiomas que desea sean soportados por su aplicación, pero también es posible que tenga que modificar el modo en que se manejaran los datos, el tipo de ordenación, etc.

Para localizar su aplicación, en primer lugar deberá cambiar ciertas cosas tanto en el propio Omnis, como  en todas las cadenas de texto y etiquetas que contenga su librería. Si va a distribuir su aplicación a través de la web, sólo tendrá que traducir los textos de su librería o dicho más concretamente, todo lo que vaya a ser visible sobre el navegador del usuario.

Omnis Studio cuenta con diversas herramientas, tanto para traducir el propio Omnis, como para sus archivos de librería, en futuros artículos hablaremos más concretamente sobre el uso de éstas herramientas, en ésta serie de 10 artículos, tan sólo pretendo exponer en términos generales como Omnis trata la codificación Unicode.

Aún no he recibido muchos comentarios sobre si los artículos expuestos en éste blog, están resultado útiles para la comunidad de desarrolladores Omnis de habla hispana, pero espero sinceramente que así estén resultando, no obstante (querido lector) sería muy animador poder contar con su opinión al respecto.

La “localización” del propio Omnis.

La “localización” del run-time Omnis le permitirá cambiar los elementos que indicamos a continuación, algunos de ellos podrán ser observados por el usuario final, mientras que otros sólo afectan a cómo se gestionarán los datos de tipo “Character” y “Number”, hablamos de los siguientes:

  • Denominación de los días de la semana y meses del año.
  • Caracteres separadores.
  • Los textos de “Yes/no”, “OK/Cancel”, “True/False”, “Am/Pm” y “On/Off”.
  • La forma de ordenación a utilizar con el uso de “National”

Todas sus librerías comparten las especificaciones que habrán sido guardadas en un archivo de datos Omnis, denominado omnisloc.df1, se trata de hecho, de la base de datos de localización y que podrá encontrar dentro de la carpeta “local”, situada bajo el directorio raíz de su instalación Omnis. La librería “omnisloc.lbr”, le permitirá añadir y modificar información según los diferentes idiomas a soportar en su aplicación.

Cada registro en la base de datos de localización (omnisloc.df1) contiene un conjunto completo de datos en correspondencia con un idioma. También contiene un identificador de idioma actual, es decir, el registro actual o configuración en uso.

La librería “omnisloc.lbs” ha sido actualizada para soportar Unicode. El campo que antes se llamaba “sort order” ahora se denomina “locale”. Además, y sólo en la versión Unicode, podrá encontrar una nueva casilla de verificación denominada “Use Locale For Defaulted Items”. Esto determinará la configuración regional a utilizar según las diferencias que se pueden encontrar en cada lengua y del modo siguiente:

  • Si la casilla de verificación “Use Locale...” está marcada, los valores por defecto se tomarán de la configuración guardada en el registro del lenguaje (omnisloc.df1).
  • Si no está marcada, los valores por defecto serán tomados de la configuración regional indicada en el sistema operativo.

La “localización” de una librería.

Omnis proporciona dos opciones para traducir textos y etiquetas incluidas en su aplicación:

  • La librería “translation”.
    La librería (trans.lbs), situada en el directorio raíz Omnis, permite la traducción de textos y las etiquetas de su librería, podrá exportar todos los literales contenidos en su librería para así poder traducirlos, para después ser importados de nuevo a su librería.
  • Uso de “String Tablas”.
    Mediante “String Tables”, podrá traducir dinámicamente textos y etiquetas de su aplicación, use la utilidad “String Table Editor” para configurar tablas conteniendo conjuntos de palabras para los diferentes idiomas, también dispone de algunas utilidades que le ayudaran en la traducción, podrá encontrar la utilidad “String Table Editor” bajo el menú “Tools>>Add Ons”.

Una herramienta similar a ésta, incluida desde la versión 5 de Studio, nos permite, incluso la traducción en diferentes idiomas de cada texto usado por la propia aplicación Omnis, pero no hablaremos de ella en ésta ocasión, lo dejaremos para un futuro artículo.

26 marzo 2014

De No-Unicode a Unicode (Parte 8 de 10)

Conversión de archivos de datos Omnis (df1)

  • ¡¡ CUIDADO !!
    Haga una copia de seguridad de sus archivos, antes de convertirlos en una versión Unicode de Omnis Studio.

Desde la versión 4.3 (y 4.3.x) Unicode, Omnis Studio incluye un conversor de los datos e índices contenidos en ficheros df1 de Omnis. En el caso de encontrar datos de tipo “Character” almacenados en campos de tipo “Binay”, (por ejemplo, al guardar un documento creado con un editor de textos externo) no se llevará cabo ningún tipo de conversión.

Al abrir un archivo de datos Omnis con una versión Unicode, se le pedirá que confirme si desea realmente realizar la conversión. Si pulsa sobre el botón “Sí”, Omnis mostrará un cuadro de diálogo con las siguientes opciones:

  • Rápida (Quick)
    Los índices son eliminados y después reconstruidos, los datos no se convierten. Ésta opción puede resultar útil en los casos en que el archivo a convertir únicamente contenga caracteres de 7 bits, tenga en cuenta que Omnis no realizará comprobación alguna en cuanto a esto, será responsabilidad suya.

  • Completa (Full)
    Se lleva a cabo la conversión completa del archivo.

Cuando el fichero es abierto desde comandos


A los comandos “Open data file” y  “Prompt for data file” se les ha añadido la opción “Convert without user prompts”. Si esta opción está activada, no se mostrará el diálogo para conversión mencionado anteriormente, pero si podrá seleccionar, (como parte del comando), si desea usar "Quick Unicode conversion" o "Full Unicode conversion", de éste modo podrá indicar el nivel de conversión que desee.

Compruebe cabalmente si los resultados de la conversión son los deseados, no deseche la copia de seguridad del archivo de datos no-Unicode y que realizo antes de la conversión, al menos hasta que esté completamente seguro de que los datos ha sido convertidos con éxito. Realice algunas pruebas con los datos desde su aplicación. Normalmente usted hará esto con una nueva versión de Omnis Studio, pero cuando la librería es convertida a Unicode al igual que sus archivos de datos, deberá tener especial precaución por los posibles problemas que se puedan presentar.

Datos tipo “Character” y “Binary” bajo Unicode

No es posible concatenar una variable de tipo “Character” con otra de tipo “Binary” cuando se está trabajando con una versión Unicode de Omnis Studio. El opción correcta sería usar $readfile para leer un archivo y guardarlo sobre una variable binaria, para después analizarlo. La asignación de datos de tipo “Characer” a “Binary” y viceversa es probable que cause problemas, sobre todo al usar Unicode, y debe ser por tanto evitado.

19 marzo 2014

De No-Unicode a Unicode (Parte 7 de 10)

Conversión de Librerías


Al abrir una librería Omnis con una versión Unicode, se le pedirá que convierta el archivo. Se trata de una conversión total, incluyendo los caracteres menores del 128. Una vez que la librería ha sido convertida a Unicode, no podrá volver a utilizarse como versión no-Unicode.

Control de versiones (VCS)

La versión Unicode de Omnis VCS construye librerías que funcionan únicamente con versiones Unicode de Omnis Studio. Sólo las versiones no-Unicode de VCS pueden construir bibliotecas ejecutables tanto con versiones Unicode, como no-Unicode.

Edición de textos en campos con barras de desplazamiento

La propiedad $righttoleft fue añadida con la intención de permitir la entrada de texto en los campos de edición con desplazamiento de derecha ha izquierda y con la finalidad de (por ejemplo) permitir la introducción de datos con escritura árabe. Esta propiedad ha sido mejorada para que en un campo con varias líneas de texto, muestre la barra de desplazamiento vertical situada a la izquierda.

Oracle8 DAM (Unicode)

Se ha creado una nueva propiedad de sesión para DAM de Oracle8 (DAMORA8), disponible en sólo con el DAM Unicode.
  • $nationaltonclob
    $nationaltonclob puede ser usado para modificar la asignación predeterminada para los tipos de datos Omnis “Character” y “National”. Por defecto, los tipos “Character” y “National” creados con un tamaño superior a $maxvarchar2 son relacionados con el tipo de datos NCLOB, pero, fijando la propiedad $nationaltonclob a kTrue, sólo los campos de tipo “National” mayores de $maxvarchar2 serán asignados como NCLOB. De éste modo los campos de tipo “Character” mayores de $maxvarchar2 serán asignados como no-Unicode CLOB y podrían sufrir pérdida de datos por truncamiento, si es el caso que contienen caracteres Unicode.

12 marzo 2014

De No-Unicode a Unicode (Parte 6 de 10)

El componente FormFile


Las propiedades $filereadencoding y $filewriteencoding del componente FormFile, introducido en la versión 4.0 de Studio, fueron modificadas en la versión 4.1, de modo que la constante kFFEncoding permitiese el uso del grupo kUniType… y poder así indicar la codificación del archivo. En el caso de la propiedad $filereadencoding podrán usarse todas las constantes del grupo excepto kUniTypeCharacter, y en el caso de la propiedad $filewriteencoding excepto kUniTypeAuto y kUniTypeCharacter .

Además, también se dispone de una constante kUniTypeBinary para identificar los archivos que se tratarán como datos binarios sin procesar, el código antiguo sigue estando soportado.

El componente Fileops


El componente Fileops contiene dos nuevos métodos, $readcharacter() y $writecharacter(), que permiten la lectura y/o escritura de datos en formato Unicode.
  • $readcharacter(encoding,variable) Lee un fichero almacenando sus caracteres en variable; encoding podrá ser una constante del grupo kUniType…, excepto kUniTypeBinary o kUniTypeCharacter.

  • $writecharacter(encoding,variable) Sustituye el contenido del archivo, con los datos  de variable; encoding podrá ser una constante del grupo kUniType…, excepto kUniTypeAuto, kUniTypeBinary o kUniTypeCharacter.

Cuando se usan las opciones Import/Export y Report File


Es posible especificar la codificación de los archivos de texto que se generan al usarse las opciones de importación y exportación, así como al enviar un informe a un archivo de texto, esto podrá hacerse mediante las propiedades $importencoding y $exportencoding:
  • $importencoding Especifica la codificación que se utilizará para los datos importados, tanto al importar desde un puerto, como cuando el archivo de importación no contiene una cabecera Unicode BOM. Podrá usarse cualquiera de las constantes del grupo kUniType..., con excepción de kUniTypeAuto, kUniTypeCharacter, kUniTypeBinary y las kUniTypeUTF32….

  • $exportencoding Especifica la codificación que se utilizará en la exportación de datos, tanto al imprimir sobre un puerto o sobre un archivo de texto. Podrá usarse cualquiera de las constantes del grupo kUniType..., con excepción de kUniTypeAuto, kUniTypeCharacter y kUniTypeBinary.

  • $exportbom Si es “true”, indicará que la propiedad $exportencoding deberá usar una codificación Unicode, se creará la marca Unicode BOM al inicio del archivo de salida.

Todas éstas propiedades pueden ser localizadas entre las preferencias Omnis ($root.$prefs). Cuando se trata de un servidor multi-hilo, existirá un valor separado para cada una de estas propiedades, en correspondencia con cada hilo.

06 marzo 2014

De No-Unicode a Unicode (Parte 5 de 10)

Conversión de datos Unicode

La función uniconv() permite convertir caracteres Unicode de un tipo a otro.

Su sintaxis es: uniconv(srctype,src,dsttype,dst,bom,errtext)

Convierte src y guarda el resultado en dst. Devolverá cero o un valor distinto de cero junto con el texto de error en errtext. src y dst pueden ser variables de tipo binario o carácter, en función de los valores usados en srctype y dsttype.

bom es un valor booleano: si es cierto, dst será “Unicode Byte Order Marker” (BOM).

srctype y dsttype podrán ser cualquiera de las siguientes constates kUniType...

kUniTypeAuto

La codificación de origen es detectada automáticamente y sólo puede ser usado en alusión al origen de datos.

kUniTypeUTF8

Los datos son guardados en una variable binaria y codificados en UTF-8.

kUniTypeUTF16BE

Los datos son guardados en una variable binaria y codificados en UTF-16BE.

kUniTypeUTF16LE

Los datos son guardados en una variable binaria y codificados en UTF-16LE.

kUniTypeUTF16

Los datos son guardados en una variable binaria y codificados en UTF-16LE si la plataforma es “little-endian” o en UTF-16BE si la plataforma en uso es “big-endian”. Esto asegura estar usando la codificación apropiada según el sistema operativo en uso.

kUniTypeUTF32BE

Los datos son guardados en una variable binaria y codificados en UTF-32BE.

kUniTypeUTF32LE

Los datos son guardados en una variable binaria y codificados en UTF-32LE.

kUniTypeUTF32

Los datos son guardados en una variable binaria y codificados en UTF-32LE si la plataforma es “little-endian” o en UTF-32BE si la plataforma en uso es “big-endian”. Ésto asegura estar usando la codificación apropiada según el sistema operativo en uso.

kUniTypeNativeCharacters

Los datos son guardados en una variable binaria, donde cada byte es un carácter del juego de caracteres “Latin 1” según el sistema operativo en uso (Ansi, si se trata de Windows, MacRoman si es un Mac, e ISO-8859-1 si es Unix.

kUniTypeCharacter

Los datos son guardados en una variable de tipo carácter.

En los casos de kUniTypeAnsiThai, kUniTypeAnsiCentralEuropean, kUniTypeAnsiCyrillic, kUniTypeAnsiLatin1, kUniTypeAnsiGreek, kUniTypeAnsiTurkish, kUniTypeAnsiHebrew, kUniTypeAnsiArabic, kUniTypeAnsiBaltic, y kUniTypeAnsiVietnamese, los datos son guardados en una variable binaria, y contiene datos de tipo carácter, donde cada byte es codificado usándose para ello el conjunto de códigos ANSI estándar.

26 febrero 2014

De No-Unicode a Unicode (Parte 4 de 10)

Representación de caracteres

 

Dependiendo del tipo de letra/fuente y del sistema operativo en uso, un mismo carácter puede no ser siempre representado del mismo modo y lo mismo ocurrirá al trabajar con textos que requieren pares suplentes. En términos generales, los mejores resultados se obtendrá mediante la normalización del texto usando para ello la función nfc(), ya que (generalmente) los diferencias se producen con el uso de caracteres compuestos.

Introducción de caracteres


Para la introducción/edición de textos y siempre que sea posible se recomienda utilizar  normalización nfc(). Si tenemos caracteres compuestos entre los datos, se requerirán varias pulsaciones de teclas de desplazamiento izquierda/derecha para saltar uno de éstos caracteres y es posible que cuando copie texto sobre el portapapeles, éste no contenga después exactamente lo que parecía haberse copiado.

Omnis, lleva a cabo automáticamente la normalización NFC de los caracteres pegados desde el portapapeles, pero tenga en cuenta que esto no se producirá cuando el hecho suceda desde el cliente web.

Conversión de caracteres


Las funciones siguientes le permitirán convertir un carácter específico de entre un conjunto de caracteres (cadena) a su valor Unicode y lo mismo en sentido inverso.

  • unicode(cadena,posición[,valor-hex])
    devuelve el valor Unicode del carácter indicado en posición. La primera posición de cadena es 1. Si el valor bolean “valor-hex” es cierto (por defecto es falso) se obtendrá su representación en formato hexadecimal, en el formato:  'U+h'.
  • unichr(num1[,num2]…)
    devuelve una cadena formada por la concatenación de los códigos de caracteres Unicode suministrados. Cada código es un número o una cadena en la forma 'U+h', donde h está formado por los de 1-6 caracteres que representan un valor hexadecimal.

Estas funciones están disponibles tanto desde el lado del cliente remoto, como localmente. (si se intentasen utilizar con una versión no-Unicode de Omnis, se producirá un error, cualquier biblioteca desarrollada con una versión Unicode es incompatible con no-Unicode)

Identificador de configuración regional (LCID)


La función locale() devuelve el identificador de configuración regional (LCID) del sistema/máquina en uso. El LCID especifica el formato de los separadores de decimales, miles, listas, tipos de moneda, unidades de medida, fecha y orden de clasificación. La configuración regional se especifica a nivel de sistema operativo y se encuentra en la forma "idioma_país", donde idioma es el nombre ISO639, y el país el ISO3166. Por ejemplo, la configuración regional para el Reino Unido es: “en_GB”.

Comprobación versión Unicode


La función isunicode() devolverá verdadero, siempre y cuando la función sea ejecutada desde una versión Unicode de Omnis Studio. isunicode() también funciona desde el cliente web, e indica si es o no compatible Unicode.

19 febrero 2014

De No-Unicode a Unicode (Parte 3 de 10)

Comparando textos

Omnis utiliza dos tipos de comparación entre cadenas de caracteres:
  • Comparación entre cadenas con valores UTF-8, conocida como: comparación de caracteres.
  • Comparación de acuerdo a las reglas de entorno locales, indicadas en el fichero de datos de localización (localisation data file), en éste caso y antes de llevarse a cabo la comparación, los datos entrantes son normalizados. Esto se denomina como comparación nacional (National). El uso de “National” por parte del usuario, permitirá garantizar el correcto uso de los caracteres correspondientes a su localidad. Tenga en cuenta que el uso de “National” podrá hacer caso omiso de otras reglas de codificación superiores.
Deberá usarse la función natcmp() para realizar comparaciones de tipo “National”. Tenga en cuenta que dicha función no está disponible del lado del cliente Web.

Omnis también realiza comparación de textos por muchas motivos diferentes y en ocasiones muy diversas, pero a continuación mencionaremos las más importantes.
  • Al ordenar listas
  • Al realizar búsquedas en listas
  • Al manejar índices de archivos de datos (df1)
  • En expresiones, como por ejemplo en una sentencia “if”
En todos los casos Omnis soporta el uso de variables de carácter (UTF-8) y nacional (National).

Al ordenar listas

Cuando se usa el tipo carácter, Omnis utiliza la comparación de caracteres (UTF-8) y cuando se usa el tipo nacional, Omnis utiliza la comparación nacional (National).

Al realizar búsquedas en listas

Cuando se usa el tipo de carácter, Omnis utiliza la comparación de caracteres. En el caso de listas que contienen una columna de caracteres de tipo nacional se usará “National”. Tipos especiales de búsqueda, como por ejemplo, búsquedas mediante un cálculo, se trataran como de tipo carácter, sin embargo, podrá hacer uso de la función natcmp() como parte del cálculo, con el fin de forzar el uso de la comparación “National”.

Al manejar índices de archivos de datos (df1)

Si son declarados como de tipo “National”, se usara éste.

En expresiones

Para garantizar el correcto comportamiento de las expresiones donde se evalúen caracteres, debe previamente normalizar su valor mediante el uso de la función nfc(), nfd() (vistas en la parte II) o bien la función natcmp(), según le interese.

12 febrero 2014

De No-Unicode a Unicode (Parte 2 de 10)

La normalización de caracteres

Originalmente, Unicode se componía un conjunto de caracteres de 16 bits, y fue ampliado posteriormente hasta incluir el U+10FFFF y probablemente no será la última vez que se produzca una extensión.

Windows y Mac OS X aún representan cadenas de caracteres Unicode utilizando matrices de números enteros abreviados (16-bit), lo cual no representa un problema ya que el estándar UTF-16 permite que los códigos U+10000 y mayores puedan ser representados mediante pares de valores de 16 bits, lo cual puede dejar un par libre (sin uso), conocido como par suplente.

Internamente Omnis usa UTF-32 para representar los códigos, es decir, cada código ocupa 32 bits, por lo que el valor de cada uno de ellos puede estar entre 0 y U+10FFFF inclusive. Esto permite un procesamiento sencillo de las cadenas de caracteres, ya que cada código ocupa el mismo espacio de memoria.

Unicode permite un alto número de variantes entre los caracteres a representar. Por ejemplo, considere las posibles variantes de la letra E, con acento circunflejo, con un punto por debajo o su representación en vietnamita, este carácter de hecho consta de cinco posibles representaciones en formato Unicode:

U+0045          corresponde a la letra mayúscula latina E
U+0302          con acento circunflejo
U+0323          con un punto debajo
U+00CA         mayúscula con acento circunflejo
U+1EB8         mayúscula con punto debajo
U+1EC6         mayúscula con acento circunflejo y el punto por debajo

Un carácter representado por más de un código es conocido como carácter compuesto (composite), mientras que uno representado por un único código, es conocido como carácter pre-compuesto (pre-composed).

En lo que respecta a su "forma final", a cada una de éstas representaciones generalmente le corresponde una única grafía, lo cual conlleva algunas consecuencias interesantes en lo que respecta a su uso con Omnis y que iremos exponiendo en las sucesivas entregas de éste tutorial. Con el término "forma final" hacemos referencia al carácter que finalmente se desea obtener, en el ejemplo anterior, el carácter "forma final" sería: .

Con el término normalización hacemos referencia a la conversión de una cadena de caracteres a un formato estándar Unicode. Una vez normalizada, una cadena de caracteres Unicode tiene una única representación posible, permitiendo de ese modo su comparación con otras cadenas de caracteres. El estándar Unicode recomienda el uso de uno de los dos siguiente métodos de normalización:
  • Descomposición regulada, denominada NFD: Los caracteres pre-composed son sustituidos por caracteres composite equivalentes.
  • Descomposición regulada (NFD), seguida de pre-composed, denominada NFC: Después de llevarse a cabo el NFD, todos los caracteres composite resultantes son sustituidos por sus equivalentes pre-composed, si los hubiere.
Para realizar la normalización de cadenas de caracteres Omnis proporciona las siguientes dos funciones:
  • nfd(cadena): Ejecuta un NFD y devuelve la cadena normalizada. 
  • nfc(cadena): Ejecuta un NFC y devuelve la cadena normalizada.
Estas funciones no están disponibles para su uso en métodos del cliente web, es decir ejecutándose del lado del cliente.