[Madrid-pm] Lo prometido es deuda: sobre los encodings

[DervishD]

    Hola Joaquín :)

 * Joaquin Ferrero <explorer en joaquinferrero.com> dixit:
> El dom, 04-11-2007 a las 19:22 +0100, DervishD escribió:
> > Como le prometí a Salva y a Joaquín, os cuento con más detalle el asunto
> > de los encodings y "mkdir". El código "de verdad" es largo y las partes
> > problemáticas están un poco repartidas. Además no es muy relevante
> > porque el problema se puede reproducir en pocas líneas.
> 
> La explicación es buena y se entiende...

Más vale tarde que nunca O:))
 
> Pero voy a decirlo muy claro: no estoy de acuerdo en crear el nombre
> del fichero forzando a uno distinto del que marca el sistema.

Pienso igual (aunque por distinto motivo), pero... es que no lo está
marcando el sistema. El sistema se traga *cualquier* encoding si el
locale es monobyte, y el nombre del fichero se verá mal o incluso no
puede usarse.

> ¿Por qué? Pues porque un fichero, en algunas ocasiones, "viaja" de un
> sistema de ficheros a otro, en donde seguramente la codificación será
> distinta.

Pero se convierte automaticamente. O al menos así debería de ser...

> Item más... si usamos un programa para gestionar/leer/escribir un
> fichero en un determinado sistema, si luego hacemos una migración del
> programa y del fichero a un sistema distinto, podemos tener un problema
> porque el programa no encontrará el documento.

Cierto. En este caso no pasa, y no debería pasar si usas la solución de
I18N::Langinfo + Encode.

> Creo que esta puede ser la razón por la cual las operaciones de
> ficheros no hacen la traducción: porque el nombre de un fichero lo
> debe identificar de forma unívoca. Si depende de la codificación, no
> existe esa correspondencia: no podemos garantizar su futuro acceso.

Insisto, sí podemos garantizarlo si usamos la solución que digo.

De todas formas entiendo tu postura porque comparto tu opinión sobre
utf8.

> Mi solución es muy sencilla, desde hace un par de años: siempre utf8.

Aquí es donde estoy de acuerdo contigo al 100%. Creo que ya es hora de
pasar de locales y de encodings. Me explico: locales sí, para los
formatos de fecha y hora y esas cosas, pero no para los charsets. HAY
que usar Unicode, y dentro de las codificaciones Unicode todavía me
tienen que demostrar que haya alguna con más ventajas que utf8.

Si se usa utf8 de repente todo se vuelve más simple, más portable, más
internacional y en resumen, mejor. Soy de la opinión de que la forma de
que la gente vea la luz (y aquí igual me paso de listo) es que los
programas que hago usen utf8 y fuercen utf8. Si no funcionan en un
locale monobyte... pues mala suerte.

Entiendo que hay gente que no tenía muchas opciones para pasar a utf8 y
tienen que mantener un locale monobyte, pero la solución no es escribir
software que se pegue con los locales, sino arreglar esos sistemas para
que se pueda pasar a utf8.

Sin embargo en este caso tenía las manos parcialmente atadas. El script
es para uso personal (es un audio ripper, puedes encontrarlo en
svn://home.dervishd.net/snippets, se llama "dab") y para que actúe de
backend para un par de amigos que a las malas tendrán que usarlo en un
locale que NO es utf8.

Es así y todo y me estoy planteando obligar a que funcione en utf8...

Mi único reparo para hacerlo es que ¿cómo sé que la codificación interna
de Perl será utf-8? De hecho, no lo es siempre (mira perluniintro) En
entrada/salida no hay ningún problema, hay varios pragmas que hacen el
trabajo de forma automática y forzando utf8. Genial. Pero volvemos al
mismo problema cuando interactuamos con el sistema de ficheros. Si
resulta que Perl está usando utf8 internamente, no hay problema, pero si
no... Vamos, que la cosa no es tan simple, creo.

> Este mismo año, en enero, ya he comenzado a usar en mis sistemas
> Linux, codificación utf8. Como dice el enlace, algunos programas
> todavía hacen cosas extrañas, pero cada vez son menos y en las
> siguientes versiones ya lo soportan.

Yo me estoy encontrando con bastantes problemas en las X y alguno en la
consola. Muchos programas de X que usan GTK+ insisten en decidir ellos
qué se usa en la entrada de datos, y soportan utf8 para *presentar* los
datos pero no para obtenerlos. Imposible teclear una 'ñ'... Pero como
dices, es cuestión de tiempo.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...