Re: caracteres en UTF8

Alvaro Herrera escribió:
> Juan Martínez escribió:
>> Alvaro Herrera escribió:
>>> Juan Martínez escribió:
>>>
>>>>> P.D.: los servidores son linux, pero las maquinas desde donde saco y
>>>>> repongo la bd son windows
>>>> Ahi está tu problema :-) . En linux es tan simple con:
>>>>
>>>> pgdump bd > bd_dump.sql
>>>>
>>>> Y en el otro servidor:
>>>>
>>>> psql bd < bd_dump.sql
>>> No, el que el sistema operativo sea Windows no tiene nada que ver con el
>>> problema.
>> Si puede ser parte del problema.
>> Por razones muy sencillas. He visto algunas versiones de WIN2k y WINXP
>> en donde curiosamente UTF8 no viene activado de fabrica.
>
> Y eso que tiene que ver? Postgres usa mecanismos UTF8 internos.

Eso no lo sabia. Pense que usaba los recursos del sistema, o mas bien,
le dejaba esta tarea a quien le corresponde hacerla (al SO que este
corriendo).

> Para
> lo unico que usa el sistema operativo es strcoll(), que se usa para
> ordenamientos, no para entrada/salida ni conversiones de codificacion.

Entiendo.

>> Entonces, más de alguna vez me ha tocado lidiar con hasefrosh donde
>> definitivamente no decodifica un archivo particular. El problema se
>> soluciona activando el charset en su configuración.
>
> Postgres no decodifica archivos.

Como que no?
Que son las bases de datos a bajo nivel?. Ok. Me imagino que las guarda
en binario. Pero aun asi eso no se necesita decodificar?

>> El tema es que en linux la localizacion y el charset es bastante mas
>> facil de saber, ademas, uno en linux normalmente activa una o dos
>> localizaciones con sus respectivos charset... Te has fijado cuantos
>> vienen activados en Windows?
>
> Y eso que tiene que ver?

Con lo que dije un par de parrafos antes.

>>> Si los servidores estuvieran todos en Linux, y las bases de
>>> datos fueran todas iguales a como son ahora, tendría exactamente el
>>> mismo problema que hoy tiene.
>> El colistero dijo que los servidores estaban en linux.
>
> Unos servidores estan en Linux, los otros estan en Windows. Ademas, si
> los servidores estan en Linux, eso debilita tu argumento puesto que tu
> decias que con los servidores en Linux no tendria este problema, lo cual
> es evidentemente falso puesto que si los tiene.

A ver. El problema que yo sospechaba era que Windows tenia que ver en la
decodificacion cuando, por ejemplo, desde pgAdmin se hace un dump. Yo
pense, si la BD esta en UTF8, y windows no tiene soporte UTF8 activado,
entonces, problemas de decodificacion. Se entiende?

>> Raya para la suma. Como puedes convertir transparentemente los datos de
>> una tabla que se le metieron datos en codificaciones incorrectas?
>
> Un error de codificacion en "algunos" datos nunca va a ser
> "transparente" de solucionar, en ningun sistema operativo. Pero ese
> tampoco era tu punto original;

No no... Ese es el tema original de la discusion. Yo no intente poner un
nuevo issue... Digamos que alguien queria saber como se arregla. Una
forma es buscar por la raiz (equivocadamente segun parece).

> No se me malentienda -- yo no adoro Windows y a decir verdad, ni
> siquiera lo uso.

No es necesario adorarlo para usarlo :-)

> Pero aca tienen la mania de echarle la culpa a Windows
> a cosas que tienen otras explicaciones, lo cual me fastidia porque esta
> no es una lista anti-Windows,

Huh. No se si se entendio mal mi punto. No intente agredir a Windows por
que si.

Solo pense que podria tener algo que ver. Es mas, como indica la
netiquette, cuando hice la broma sobre el lugar del problema, añadi el
correspondiente emoticon.

En fin. Lo importante tiene que ver con que el problema no es de windows
(se descarta mi teoria) y el problema al parecer se debe solucionar
"manualmente", ya sea haciendo los UPDATE's necesarios para corregir en
la BD, o de frenton, editar el dump.

--
Juan Martinez G. Mac Iver # 370
Departamento de Informatica 4997900 - 4997934
Universidad Miguel de Cervantes Santiago - Chile
http://download.bblug.usla.org.ar/netiquette.png