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 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í?

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.

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)'

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.