keparodo escribiste:¿Se hace alguna transformación de lo que lee?
Si
no se hace en binario, FTP hace la transformación de los caracteres finales de línea, lo cual es genial si transmitimos ficheros de texto, pero un desastre si se trata de otro tipo de archivos. Por eso, la inmensa mayor parte de las ocasiones, todo se hace en binario.
Es una de esas cosas que quedan de la informática antigua... tenía sentido hace 20 años, pero ahora ya no.
keparodo escribiste:¿Se traduce a binario?
Los ordenadores solo entienden binario
keparodo escribiste:No sería esta la oportunidad para que al ser transferido (o leído ¿?) en binario, yo lo pudiera entender en mi propia codificación (de mi equipo) y no tener los posteriores conflictos?
En algunos clientes FTP se puede configurar la codificación del servidor y del cliente, y se supone que hará la transformación de caracteres
si la transmisión
no es en binario.
Pero para transmisiones programadas, como la tuya, la respuesta es no. Mejor bájate el archivo y luego lo traduces.
keparodo escribiste:¿Y no puedes preguntarles qué sistemas operativos están usando? Si sabes eso, ya tienes hecho casi todo el camino.
No. No puedo mi cliente es uno, pero él atiende a por lo menos 350 clientes, cada cliente tiene una o más personas que envían sus archivos, desde distintas fuentes, equipos, etc. por lo que siquiera intentar saberlo es complicado.
Pero, al menos, los archivos deben tener un formato reconocido... Excel, Word, RTF, XML, OpenDocument... Si son solo texto, vas muy mal... ¿ni siquiera puedes saber qué cliente ha dejado qué archivo? En ese caso, con el tiempo, podrías relacionar las codificaciones que usa cada cliente. Puedes sospechar que el 99% va a trabajar con Windows, así que eso reduce las codificaciones a un par de ellas: cp1252, utf-16, (y, creo, últimamente, utf-8).
keparodo escribiste:¿En qué codificación está la base de datos?
LANG=en_US.UTF-8Y supuestamente el servidor donde tengo la aplicación es
LANG=AMERICAN_AMERICA.WE8ISO8859P15
¡Je! La base de datos está en UTF-8 y el servidor, en ISO-8859-15. ¡Qué divertido!
keparodo escribiste:Y, finalmente, me piden eliminar estos caracteres para que no sean almacenados de forma incorrecta, entiendo que eso se soluciona, al leer en la codificación correcta y al guardar en la codificación correcta, pero para hacerlo en esta última etapa, debo saber lo que leo y el problema es que es el origen el que desconozco.
Pues sí, esa es la solución. Y también el problema: si no sabes lo que recibes, un archivo de texto es indistinguible de una ristra de ceros y unos.
Hace años se publicó un artículo en la Investigación y Ciencia, donde comentaba la pervivencia de los sistemas de almacenamiento. Ponía el ejemplo de un chaval, en el 2030, donde encontraba en el desván de la casa un DVD de nuestros días, y claro, en esa época ya no existirán lectores de DVD, así que no podría leer el contenido, y aunque se hiciera con uno, necesitaría además un ordenador, y además, un sistema operativo y unos controladores... difícil... Lo peor: leyendo el contenido, los unos y ceros, de la superficie del disco, aunque técnicamente es sencillo, sería complicadísimo, y en algunos casos, imposible de entender, sin tener más información que el propio disco. En un flujo de datos, si no hay marcas, es complicado saber qué se está leyendo. Terminaba el artículo recomendando que guardáramos nuestros soportes de almacenamiento junto con instrucciones
en papel de cómo habría que leerlo
A ti te pasa lo mismo... sin más información, la única solución que se me ocurre es coger el texto y probar a decodificarlo con las codificaciones más usuales, y si el resultado no da errores, pues habremos acertado.
Sería algo así:
- Dado un texto, recorremos todas las codificaciones, desde la más popular (creemos), hasta la menos. O usas Encode->encodings() para recorrer todas.
- Convertimos el texto, desde esa codificación a la 'UTF-8', con la función from_to(), de Encode. ¡Ojo! Es 'UTF-8', así, en mayúsculas y con un guión en medio. Nada de 'utf8' ni 'UTF8'. Son codificaciones diferentes.
- El tercer argumento de from_to() es el CHECK, que indica qué debe ocurrir si la transformación falla: o sustituir el carácter extraño con U+FFFD, o morir con die() (que podemos capturar con eval{}), o "saltarlo" (no hacer nada).
- Si no sale error o no obtenemos el carácter U+FFFD, entonces sí que podemos decir (con un alto porcentaje de éxito), que hemos acertado con la codificación correcta.
