Foro - Perl en Español

Cuento con unos TXT que analizo con la ayuda de un script, y este me devuelve un archivo resultado que contiene los UPDATES que debo realizar a la DB.

El problemilla es que en dicho archivo resultado me encuentro con caracteres del tipo "Fray Cay Rodr�guez 325 2" y lo que quiero es evitar actualizar la DB con esos caracteres. Estoy al tanto de que se trata de la codificación del TXT pero ¿cómo puedo resolverlo?

Saludos.

Pues para resolverlo debes averiguar en qué codificación de caracteres están esos archivos de texto, y en qué codificación debes entregarlos a la base de datos.

Luego, con el módulo Encode, lo tienes resuelto (o casi resuelto).

Pues la codificación de los archivos es UTF-8 Unicode, mientras que haciendo la siguiente consulta a la db "SELECT * FROM pg_database;" obtengo el siguiente resultado:



Donde el encoding es cero, y si no me equivoco según ESTA TABLA parecería contar con la codificación SQL_ASCII.

Mañana le echaré un ojo al módulo Encode que me has facilitado a ver si lo pillo. Intuyo que debo de hacer el llamado e indicar la codificación final que necesito que se muestre, ¿no es así?

Bueno, pues entonces la solución es sencilla. Solo te queda hacer una llamada from_to() de Encode para transformarlo a ASCII.

from_to($texto, 'utf8', 'ascii');

Lo malo es que... en ASCII no hay espacio para todos los caracteres Unicode, así que algunos quedarán fuera. ¿Seguro que es ASCII? ¿No será ASCII extendido o latin 1 o latin 15 o iso-8859-15? (Este último es la codificación de europea del centro-oeste. Contiene la mayor parte de los caracteres tildados europeos y el signo del €uro).

También puedes definir un

use open IN => ':utf8';

al principio, para que Perl traduzca todos los textos desde utf8 a Unicode, y luego usar el encode() de Encode:

my $texto_en_latin1 = encode($texto, 'latin1');

Por estos foros hay algunos hilos al respecto de cómo tratar con diferentes codificaciones.

Fíjate que me he equivocado... Los archivos TXT que analizo tienen la codificación Occidental (iso-8859-15) según el editor Gedit, y luego, desde la terminal, si hago
, obtengo la iso-8859-1

Y es increíble, pero no consigo hacer una (buena) conversión, sea cual fuere la salida: utf8, latin1, ascii, etc. Cuando digo buena, digo donde consiga ver bien formado algún carácter.

Por empezar, todos éstos TXT que recibo para analizar no logro verlos del todo bien con ningún editor. Puedo notar y/o averiguar con la codificación que los abren pero son siempre los mismos caracteres que se ven a malas.
Luego, si hago un volcado de alguno de estos TXT con el comando

consigo ver que a esos caracteres mal interpretados le corresponden códigos hexadecimales como xDD donde se ve un Ý en lugar de í (con tilde), xBE donde se ve un ¾ en lugar de una ó (también tildada)...

Me explico: He probado haciendo uso del pragma open de Perl para conseguir una salida en otra codificación que no sea la misma y hasta probando con la MISMA pero lamentablemente, NADA.



Haciendo uso de la función binmode() de Perl, también...

y NADA.

También me he topado con ÉSTE BUEN SITE donde aconseja también cambiar las variables de entorno para que Perl no "adivine" de manera errónea la codificación y no tengamos problema con el procesado interno.

Y también ÉSTE Modulo de CPAN que hace uso de los comandos iconv y unac (propios de Linux, el segundo se debe instalar en algunas dristos según tengo entendido), donde el primero permite el traspaso de una codificación a otra y con el segundo comando hacer un reemplazo de una letra con tilde por la MISMA sin tilde y la encuentro buena porque la he probado con una cadena super básica y funciona bien, pero cuando analizo los TXT esto ya NO funciona.

He leído mucho y también por estos foros pero no le encuentro la vuelta al asunto. Me parece que no resta otra que editar los archivos txt en binario y evitar todo este rollo de la codificación. ¿¿Qué me dices??

Saludos.

A ver... he vuelto a leer el primer mensaje de este hilo. Dices que analizas unos archivos para luego meter la información en la base de datos.

Los archivos 'parece' que están en ISO-8859-1, pero el problema está luego en la base de datos: si la codificación que usa es SQL-ASCII, se supone que estamos hablando de una codificación ASCII-extendido (códigos de carácter de 0 a 255).

Como es una base de datos PostgreSQL, podrías probar las funciones de cambio de codificación que el propio motor de base de datos posee (sección 20.2.3.)

O usar el script, desde luego. Pero si sale mal es que alguna de las presunciones falla.

Cuando dices que "ves" un carácter "Ý" correspondiente a un byte 0xDD, no nos confirma que esté en ISO-8859-1, porque resulta que ese código también coincide con la codificación UTF8 o Unicode. Ni siquiera podemos confirmar en qué codificación está tu terminal (la que estás usando para ver ese hexdump). Lo mismo pasa con el código 0xBE (coincide "¾" en ambas codificaciones).

Así que lo primero es saber en qué codificación están los archivos.

Como dices que 0xDD debe corresponder a una 'í', de la lectura del texto que lo rodea, lo único que tenemos que hacer es mirar las distintas codificaciones estándares, y buscar aquella que muestre una 'í' con un carácter 0xDD... y... mirando, mirando... no he encontrado ninguna. Y eso que me he visto docenas. Así que no sabemos en qué codificación está ese archivo.

¿Puedes enviarme un archivo o parte de uno, en un adjunto, en un mensaje privado? Me pica la curiosidad...

Me he enterado de esa posibilidad de cambiar la codificación de la base como tal me lo has aconsejado pero es que no tengo permitido un cambio así en el sitio donde trabajo e intuyo que por algo deben de seguir manteniéndola en esa codificación (que según yo creo y consulté vía SQL como te dije en este hilo se trata de SQL_ASCII)

Respecto de los bytes de dichos archivos binarios, gracias por la aclaración, yo supuse que dependían y variaban en torno a la codificación con la que se encontraban pero veo que no se trata del contenido binario sino del Set de caracteres con el que adopten uno u otro carácter (su representación según el set).

Hay una cosilla de la que quizás no me supe explicar del todo bien en mi primer mensaje y es que es cierto que interpreto esos archivos PERO finalmente (o de forma inmediata) NO actualizo la DB, simplemente declaro las sentencias UPDATE, es decir, imprimo las sentencias en un archivo PARA LUEEEEGO, SÍ, ser corridas en la DB. No sé si sirve de algo esta aclaración pero viene a colación porque el problema radica en estos print() del archivo de salida y no al mirar la DB.

Te envío entonces por privado algún fragmento de los archivos a ver si me puedes ayudar.

Otra cosa, por si de algo también sirve, esos archivos que recibo son resultados de un software que extrae (para luego volcarlo) dicha información de una base de datos MS SQL Server.

Ahora... es cierto también ÉSTO que dice Wikipedia, en el ante último párrafo, que el reemplazo que hace el editor puede destrozar el byte original (aquél que mal interpreta) haciendo imposible la recuperación del mismo Porque esto me deja pensando (y temiendo) si el archivo que vuelca, dicho software puede ser producto de re-procesos o re-codificaciones que afecten el archivo binario que llega a mis manos ¡Ja, Ja, Ja! Puede que sea una alocada lo que menciono, en fin... no me pareció estar de más preguntar por esto xD

Por cierto, desconocía la codificación de caracteres de mi terminal, y por si te interesa me pone 'Unicode (UTF-8)'

reLlene escribiste:Me he enterado de esa posibilidad de cambiar la codificación de la base como tal me lo has aconsejado pero es que no tengo permitido un cambio así en el sitio donde trabajo e intuyo que por algo deben de seguir manteniéndola en esa codificación (que según yo creo y consulté vía SQL como te dije en este hilo se trata de SQL_ASCII)

No, yo no digo que se cambie la codificación en la que está trabajando la base de datos, sino que la base de datos puede hacer, por sí misma, la conversión de la codificación (el trabajo que tu estás intentando resolver con un script) de los datos que le llegan o los datos que entrega. Ella puede seguir almacenando los datos en SQL_ASCII, pero podemos decirle que los datos de entrada están en una determinada codificación, y que se encargue ella de hacer el cambio a SQL_ASCII. Y lo mismo a la salida. (Ver más de esto más abajo).

reLlene escribiste:Respecto de los bytes de dichos archivos binarios, gracias por la aclaración, yo supuse que dependían y variaban en torno a la codificación con la que se encontraban pero veo que no se trata del contenido binario sino del Set de caracteres con el que adopten uno u otro carácter (su representación según el set).

No exactamente... esto es un problema a tres bandas:

1. los bytes del propio archivo
2. la transformación que hace la pantalla (la terminal) a códigos de carácter (lo que llamamos la codificación de caracteres)
3. la presentación de los caracteres en pantalla (según el código obtenido en el paso anterior, el sistema necesita localizar el "dibujo" dentro del juego -set- de caracteres, para mostrarlo)

Por ejemplo, en el archivo podrían estar este grupo de bytes:
Como el sistema trabaja en una codificación UTF-8, sabe que los debe traducir a los caracteres Unicode siguientes:
y ahora va al archivo que guarda el juego de caracteres y busca la definición de esos caracteres, los compone, y los muestra en pantalla.

Es lo mismo que hacer un programa en Perl así, para mostrarlos:
o así:
(Si no ves esos caracteres es que no tienes una fuente de letras con los últimos símbolos Unicode. Te aconsejo que te instales la fuente de letras Symbola).

reLlene escribiste:Hay una cosilla de la que quizás no me supe explicar del todo bien en mi primer mensaje y es que es cierto que interpreto esos archivos PERO finalmente (o de forma inmediata) NO actualizo la DB, simplemente declaro las sentencias UPDATE, es decir, imprimo las sentencias en un archivo PARA LUEEEEGO, SÍ, ser corridas en la DB. No sé si sirve de algo esta aclaración pero viene a colación porque el problema radica en estos print() del archivo de salida y no al mirar la DB.

Bueno, nada impide que hagas, desde el programa, la conexión a la base de datos, y hagas los UPDATE directamente. Te ahorras un paso a un archivo intermedio. Tu eliges qué forma es la que te resulta más fácil.

reLlene escribiste:Otra cosa, por si de algo también sirve, esos archivos que recibo son resultados de un software que extrae (para luego volcarlo) dicha información de una base de datos MS SQL Server.

Pues "algo" debe hacer ese software, porque genera algo que no corresponde con nada estándar...

Ya te he contestado por privado que la única solución que veo es la de la conversión "manual" de los caracteres, uno a uno, mediante una transliteración:



PERO... con eso solo estamos generando texto en utf8... y solo necesitamos que lo genere en algo parecido a SQL_ASCII (los caracteres del 0 al 127 son los ASCII de toda la vida, y los del 128 al 255, PostgreSQL los deja tal cual).

Queda (le quitamos la salida en codificación utf8):
y ya tenemos una salida en iso-8859-1, perfecta para lo que queremos.

Si, por ejemplo, supiéramos qué codificación es realmente, en la que están los datos, solo tendríamos que colocar un

al principio del archivo SQL que generas, para indicarle a la base de datos en qué codificación va a recibir los datos. Y ella hará la conversión de forma automática.

reLlene escribiste:Por cierto, desconocía la codificación de caracteres de mi terminal, y por si te interesa me pone 'Unicode (UTF-8)'

Algo normal en nuestros días.

Dejo algunas citas que compartí con explorer vía privado por si a algún "agraciado" (como yo) le sirve...

explorer escribiste:Bueno.... después de mirarlo un rato, he llegado a la conclusión de que no corresponde a ninguna codificación estándar moderna. O este archivo está siendo generado por un sistema muy antiguo o ha pasado por un programa de filtrado que no está haciendo bien su trabajo.

La única solución que se me ocurre es, entonces, la del filtrado manual, carácter a carácter.

Con el siguiente programa Perl se hace la transformación a UTF-8:

perl -CO -pE 'use utf8; tr/\xDD\xAC\xBE/íºó/;' input.TXT
y ya salen correctos los caracteres.

reLlene escribiste:¡¡¡Es buenísima esa línea para el reemplazo!!! ¡¡¡Puedo valerme inclusive del comodín * (asterisco) para hacerlo sobre el directorio donde alojo todos los archivos previo al análisis de los mismos!!!

explorer escribiste:Sí, pero la salida es de todos los archivos juntos. Si te vale el resultado así, perfecto. Es una solución muy cómoda.

reLlene escribiste:...Quiero "filtrar" sólo aquellas líneas para detectar TODOS estos caracteres (mal formados) y "adivinar" de qué caracteres se trata.

explorer escribiste:El comando grep moderno tiene una opción -P con la que se permiten usar patrones de expresión regular iguales a los de Perl: grep -P "\xac" input.TXT Pero, en ese caso, ¿por qué darle más vueltas? Lo hacemos con el propio Perl: perl -nE '/\xac/ and print' input.TXT Ahora bien, lo que realmente quieres hacer es sacar todas las líneas que contengan caracteres superiores al 127. Entonces con esta línea te vale:

perl -nE '/[\x80-\xFF]/ and print' input.TXT

reLlene escribiste:... como te he dicho, hago uso de la opción -b desde vim para ver el archivo (con codificación desconocida) en modo binario y noto que aquellos caracteres mal formados se muestran entre paréntesis y resaltados, como <DD> tratándose del byte 0xDD. Y lo que quiero es "filtrar" sólo aquellas líneas para detectar TODOS estos caracteres y "adivinar" de qué caracteres se trata... Me responde con una advertencia de vim "no coincide <ac"

explorer escribiste:Ese ángulo lo pone Vim solo en el momento de mostrarte el archivo en formato binario, pero realmente, no existe en el archivo. Lo que hay en el archivo es lo que ves con el volcado hexadecimal (con el comando hexdump, por ejemplo).

por un momento le he echado un ojo a las codificaciones estándares esas que me has pasado y crei toparme con la codificación de los binarios. Hablo de la Windows-1252 ó CP-1252, una codificación del alfabeto latino que DOS y Windows trata, parece también ser Occidental.

Pues entonces, me dediqué a correr la sentencia SQL que me aconsejaste:



pero no resultó, pues por empezar me devolvía el siguiente error: Invalid value for parameter 'client_encoding' donde value puse 'WIN1252', tal cual pone en ésta tabla de conjunto de caracteres (aunque en la parte superior del sitio veo que parece que se trata de la versión 8.1 de PostgreSQL y luego vi que aquel enlace que tu me dejaste era para la 8.0 pero siendo sincero desconozco la version, deberia de hacer la consulta a la base, si mal no entiendo, ¿cierto? Porque parece que hay diferencias en las tablas de ambas versiones ), también probé poniendo 'WINDOWS-1252' y 'CP1252' pero ¡¡seguía devolviendo el mismo error!! Es entonces que me digné a consultar con



y esto me devolvió lo que parece es la codificación cliente (no servidor) de la base actual donde hago la consulta: SQL_ASCII. Traté de cambiarla con SET client_encoding TO 'UTF8' para ver si conseguía algo, pero nada, al volver a consultar con SHOW client_encoding, otra vez: SQL_ASCII.

Es entonces donde me di por vencido porque me veía medio perdido y estaba en lo erróneo al creer que esa era la codificación cuando enrealidad NO era el caso.
No obstante, me apunte la siguiente aclaración, por si en algún futuro la llego a prescindir, que hace en ese sitio sobre SQL_ASCII. La dejo a continuación:

"The SQL_ASCII setting behaves considerably differently from the other settings. When the server character set is SQL_ASCII, the server interprets byte values 0-127 according to the ASCII standard, while byte values 128-255 are taken as uninterpreted characters. No encoding conversion will be done when the setting is SQL_ASCII. Thus, this setting is not so much a declaration that a specific encoding is in use, as a declaration of ignorance about the encoding. In most cases, if you are working with any non-ASCII data, it is unwise to use the SQL_ASCII setting, because PostgreSQL will be unable to help you by converting or validating non-ASCII characters."

Volviendo a los binarios y ya mirando para otro lado, notaba que al hacer el reemplazo de bytes en los mismos (aquellos que estaban dentro del rango 0x80-0xFF), todavía me restaban otros que, viendo el binario volcando en hexadecimal, llevaban la secuencia EF BF BD (los 3 consecutivos) para representar un 'Unicode block' y si pasaba ese binario a UTF-8 veía un "mojibake", es decir, si contaba con la siguiente secuencia en hexadecimal: 0x66 0xEF 0xBF 0xBD 0x72, desde un editor de texto como el gedit veía f�r, donde el primer y último carácter se logra representar correctamente pero no así los 3 dentro.

Y volviendo a Wikipedia,

"La secuencia EF BF BD es representada por los caracteres � por tratarse de caracteres ilegales para el UTF8, es decir no están dentro del rango de los 0x00–0x7F "

El punto es... que parece que en donde están estos últimos hexadecimales (los que se encuentran contiguos: EF BF BD) se pierde el byte original que debe ser mostrado. Con esto me refiero a que en TODO lugar dónde se encuentren estos bytes consecutivos puede haber tanto una 'á' cómo una 'é', una 'í', un camello, un delfín o lo que fuere, pero SE DESCONOCE. Me explico:

En el siguiente fragmento ('Cay Rodr...guez'), donde hay puntos debe haber una 'í'(acentuada)

00001100 43 61 79 20 52 6f 64 72 ef bf bd 67 75 65 7a 20 |Cay Rodr...guez |

0x72 es una r
0xEF 0xBF 0xBD
0x67 es una g

Y en éste otro 'n Formaci...n|20' una 'ó'(también acentuada)

00004940 6e 20 46 6f 72 6d 61 63 69 ef bf bd 6e 7c 32 30 |n Formaci...n|20|

0x69 es una i
0xEF 0xBF 0xBD
0x6e es una n

Pero no hay rastro alguno, ni un byte antes ni después del que fiarme para poder hacer el reemplazo a como debo.

Agradezco de tu paciencia, explorer, y la de cualquier otro usuario que me esté leyendo para brindarme una mano.