Text to UTF8 and from UTF8

[Pedro Gea]

Son muy comunes los errores de codificación al usar TOL junto a otras herramientas en los que los caracteres se muestran ilegibles. Es relativamente habitual ver escrito "España".

Adjunto un conjunto de funciones para introducir en la StdLib (o en el cuerpo de funciones compiladas si se ve conveniente) que permiten salir airoso de estas situaciones.

Las dos principales funciones propuestas son: TextFromUTF8 y TextToUTF8 que permiten codificar el texto desde o hacia la codificación ​UTF8.
Véase más información en la documentación escrita en el propio código.

Acompaño dos ejemplos de uso:

• TestToUTF8 Convertir el texto hacia UTF8 es útil al comunicarse con herramientas que lo requiren así, como es el caso de las funciones que usan TclTk.

  Text TclTkMessageBox(SetOfSet(
    @TclArgSt("-title",   "Dialogo TclYesNoQuestion"), 
    @TclArgSt("-message", TextToUTF8("¿Desea seguir con el test?")),
    @TclArgSt("-type",    "yesno"),
    @TclArgSt("-icon",    "question")
  ));
  

  Con la llamada a TextToUTF8 se evita que el primer caracter ¿ se vea como un cuadradito.

• TextFromUTF8: Esta función nos permite hacer legible el código que recibimos con estos caracteres irreconocibles:

  Text TextFromUTF8("España"); //-> "España"
  

  Estos textos en ocasiones pueden aparecer así cuando proceden de otras sistemas o plataformas o de bases de datos, etc. Por ejemplo, en la información de sincronización del paquete PubDatIne que podemos encontrar en

  Text TolPackage::Client::_.packSyncInfo::PubDatIne[3]
  

  vemos un caso en el que este problema aparece con una segunda vuelta de tuerca: "Datos públicos del INE"

  Text TextFromUTF8("Datos públicos del INE"); 
  //-> "Datos públicos del INE"
  Text TextFromUTF8(TextFromUTF8("Datos públicos del INE")); 
  //-> "Datos públicos del INE"
  

[Víctor de Buen Remiro]

El problema del que hablas depende de la codificación que use tu sistema operativo y de la utilizada por la herramienta con la que estés interactuando. La solución que propones te sirve en windows en español contra herramientas UTF-8, pues lo que estás haciendo es pasar de UTF-8 a LATIN-1 que es la codificación estándar en España. Para otros países y otros sistemas no te tendría porqué servir.

De hecho, si estás en linux lo que harías con eso es fastidiar un texto correcto. En linux se necesitaría algo que pasara de LATIN-1 y similares a UTF-8. Habría que hacer algo que funcionara en cualquier plataforma y contra cualquier herramienta, algo que pudiera distinguir de forma más o menos automática las distintas páginas de codificación, y que pasara de una a otra cuando fuera necesario. Quizás lo que habría que plantearse es una migración de TOL a Unicode, pero eso supondría quizás demasiado trabajo y finalmente tampoco sé si garantiza nada.

Con respecto a lo de la información de los paquetes es culpa mía, como casi todo. Lo tenía bien planeado pero al final se me olvidó algún detalle. La información está almacenada en una base de datos POSTGRESQL que por defecto codifica en UTF-8 pero permite consultar con cualquier otra codificación si al principio de la conexión ejecutamos una orden como ésta:

set client_encoding to 'LATIN1'

En la URL escrita PHP se puede pasar el argumento client_encoding desde TOL de forma que en linux fuera UTF-8 y en windows LATIN-1 o la que toque. Sin embargo eso está sin completar en el código de TolPackage::Client. Por el momento lo he resuelto haciendo que si no se pasa client_encoding el valor por defecto sea LATIN1, pero claro: ahora no funcionará bien en linux.

[Pedro Gea]

Las dos funciones que propongo no pretenden ser la panacea sino ayudar al usuario de TOL y para ello creo que sí son muy útiles.

Respecto a que son válidas sólo hacia y desde LATIN1, es cierto, (lo comento en el código) pero esa situación es la más común entre nosotros, es la codificación que se usa en español, inglés o portugués. Quizá podrían denominarse Utf8ToLatin1 y Latin1ToUtf8 para ser más precisos, pero quizá baste con comentar ese detalle en la descripción. Y aunque se solucionaran todos los problemas de comunicación con TOL, creo que es útil disponer de una función que permita hacer y deshacer esa codificación aunque sea para editar documentos o datos que llegan a los proyectos con esa problemática.

Respecto a lo de que en Linux no funciona, ahí me pillas, no soy consciente de que el ​ISO-8859-1 o Latin1 sea exclusivo de Windows, dudo si es algo relacionado con Linux o con la compilación de TOL y TOLBase en Linux.
En este sentido debe notarse (y no sé si en Linux pasa algo parecido) los problemas que tiene TOL (tol.exe) con la página de caracteres (en windows):
Al menos yo encuentro que lee el código usando la ​página de caracteres 850 pero internamente interpreta y muestra el Latin1. Basta con abrir tol.exe en modo diálogo y probar:

Text "È"; // -> "Ô"
// los caracteres "È" y "Ô" son el 212 en Codepage850 y Latin1 respectivamente

o esto otro:

Real È = 1; // entenderá "Real Ô = 1;"
Real Eval("Real "<<Char(212)); // el caracter Ô es el 212 en Latin1

[Víctor de Buen Remiro]

Creo que lo más razonable es crear un nuevo paquete que podría llamarse TextEncoding en el que ir incluyendo las distintas herramientas que puedan ir surgiendo.

A lo que me refería antes no es que a la posible utilidad de esas funciones, sino al hecho de que su uso en un proyecto determinado puede provocar que dicho código sea incompatible con su uso en otros sistemas.

Normalmente un proyecto se ejecuta siempre en un mismo entorno por lo que no es peligroso, pero sí que lo sería empezar emplearlas indiscriminadamente en herramientas de propósito general que no sean exclusivas de un entorno determinado.

Por eso creo que complementariamente a las funciones propuestas debería haber otras más generales, que internamente podrían usar estas y otras que surjan, que permitan programar de forma independiente de la codificación empleada.

[Víctor de Buen Remiro]

(In [3325]) Fixes #1123

[Víctor de Buen Remiro]

(In [3326]) Refs #1123