Re: Problemas con Caracteres Especiales

Buenos dias, tengo un problemilla
habia una B.D. con todos los datos escritos en UTF-8
x alguna equivocacion, lo pasaron a SQL_ASCII
al hacer eso, se perdio la correcion de los datos quedando caracteres
extraños :S
(82 - JESÃÆ'Å¡S ) las vocales con tilde y ñ
yo me acuerdo anteriormente, cuando me habia pasado esto, hacia un backup
comprimido con el pgadmin3, y luego lo volvia restaurar en una B.D. con
UTF-8 y se regresaba a su estado normal, pero ahora nada de nada :S,
habria una forma de arreglar este error

Agradesco su ayuda.

--
Miguel Panuera C.
STsoft Developer
mpanuera(at)gmail(dot)com
m(dot)panuera(at)stsoftperu(dot)com

Miguel Panuera escribió:
> Buenos dias, tengo un problemilla
> habia una B.D. con todos los datos escritos en UTF-8
> x alguna equivocacion, lo pasaron a SQL_ASCII
> al hacer eso, se perdio la correcion de los datos quedando caracteres
> extraños :S
> (82 - JESÃÆ'Å¡S ) las vocales con tilde y ñ
> yo me acuerdo anteriormente, cuando me habia pasado esto, hacia un backup
> comprimido con el pgadmin3, y luego lo volvia restaurar en una B.D. con
> UTF-8 y se regresaba a su estado normal, pero ahora nada de nada :S,
> habria una forma de arreglar este error

El problema que tienes aquí es que el proceso ocurrió más de una vez,
es decir, se tomó un string en UTF8 como si fuera Latin1, y se convirtió
a UTF8; luego se volvió a tomar como si fuera Latin1 y se volvió a
convertir a UTF8, y así.

El truco es darse cuenta que cada vez que tomas un string en UTF8 y lo
miras como si fuera en Latin1 aparece una de esas A con ~ (Ã). Si te
fijas acá hay cuatro caracteres marcadores de inicio de caracter
multibyte: Ã Æ Ã Â Así que uno pensaría que este proceso ocurrió 3
veces.

El problema es que es redificil saber cuantas veces ocurrio esto para
cada registro ... en el caso de JESÚS parece haber pasado tres veces,
pero a JULIÁN le puede haber pasado dos o a VERÓNICA le puede haber
pasado cuatro veces o ninguna. Así que arreglarlo se ve difícil.

Con estos casos raros que aparecen cada vez me convenzo más que es mala
idea usar Latin1 como server_encoding :-(

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"We're here to devour each other alive" (Hobbes)

--- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
escribió:

> Miguel Panuera escribió:
> > Buenos dias, tengo un problemilla
> > habia una B.D. con todos los datos escritos en
> UTF-8
> > x alguna equivocacion, lo pasaron a SQL_ASCII
> > al hacer eso, se perdio la correcion de los datos
> quedando caracteres
> > extraños :S
> > (82 - JESÃÆ'Å¡S ) las vocales con tilde
> y ñ
> > yo me acuerdo anteriormente, cuando me habia
> pasado esto, hacia un backup
> > comprimido con el pgadmin3, y luego lo volvia
> restaurar en una B.D. con
> > UTF-8 y se regresaba a su estado normal, pero
> ahora nada de nada :S,
> > habria una forma de arreglar este error
>
> El problema que tienes aquí es que el proceso
> ocurrió más de una vez,
> es decir, se tomó un string en UTF8 como si fuera
> Latin1, y se convirtió
> a UTF8; luego se volvió a tomar como si fuera
> Latin1 y se volvió a
> convertir a UTF8, y así.
>
> El truco es darse cuenta que cada vez que tomas un
> string en UTF8 y lo
> miras como si fuera en Latin1 aparece una de esas A
> con ~ (Ã). Si te
> fijas acá hay cuatro caracteres marcadores de
> inicio de caracter
> multibyte: Ã Æ Ã Â Así que uno pensaría que
> este proceso ocurrió 3
> veces.
>
> El problema es que es redificil saber cuantas veces
> ocurrio esto para
> cada registro ... en el caso de JESÚS parece haber
> pasado tres veces,
> pero a JULIÁN le puede haber pasado dos o a
> VERÓNICA le puede haber
> pasado cuatro veces o ninguna. Así que arreglarlo
> se ve difícil.
>
>
> Con estos casos raros que aparecen cada vez me
> convenzo más que es mala
> idea usar Latin1 como server_encoding :-(
>

Yo uso latin1 y no tengo problemas, pero lo he usado
desde la instalacion de postgresql, la creacion de la
base y hasta los clientes todo en Latin1, ahi si fue
coherente.

El otro dia probe y pude en windows xp por primera vez
hacer funcionar UTF-8 en windows sin usar una
configuracion regional europea.

Ahi instale un postgresql con utf-8 por primera vez,
voy a tratar de emular la configuracion y como lo arme
por que fue de suerte o casualidad y no lo documente.

Igual ahora estoy probando un Debian para servidor y
un ubunto para terminal, esperando que en poco tiempo
windows para mi sea historia.

Atte.
Gabriel Hermes Colina Zambra

> --
> Alvaro Herrera Valdivia, Chile ICBM: S 39º
> 49' 18.1", W 73º 13' 56.4"
> "We're here to devour each other alive"
> (Hobbes)
> --
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

Gabriel Hermes Colina Zambra escribió:

> --- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> escribió:
>
> > Con estos casos raros que aparecen cada vez me
> > convenzo más que es mala
> > idea usar Latin1 como server_encoding :-(
> >
>
> Yo uso latin1 y no tengo problemas, pero lo he usado
> desde la instalacion de postgresql, la creacion de la
> base y hasta los clientes todo en Latin1, ahi si fue
> coherente.

El problema ocurre cuando la BD esta en Latin1 y los clientes envian en
UTF8. Al hacer la reconversion, los caracteres se guardan corruptos. Y
como Latin1 no hace chequeo de validez, se guardan incorrectamente.

Cuando es al reves, no hay problema, porque el servidor rechaza
caracteres UTF8 que no forman secuencias validas (UTF8 tiene chequeo de
validez a diferencia de Latin1).

Cuando la BD es SQL_ASCII tampoco ocurre este problema, porque el
servidor no hace reconversion de caracteres (pero tiene otros problemas
que se manifiestan cuando se conecta un cliente con una codificacion A y
los lee un cliente con una condificacion B).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

llege a resolver el problema con un script en php, :D
dentro de un momento les paso el codigo, no esta muy bien programado :S,
pero funciona :p

El día 23/08/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
>
> Gabriel Hermes Colina Zambra escribió:
>
> > --- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> > escribió:
> >
> > > Con estos casos raros que aparecen cada vez me
> > > convenzo más que es mala
> > > idea usar Latin1 como server_encoding :-(
> > >
> >
> > Yo uso latin1 y no tengo problemas, pero lo he usado
> > desde la instalacion de postgresql, la creacion de la
> > base y hasta los clientes todo en Latin1, ahi si fue
> > coherente.
>
> El problema ocurre cuando la BD esta en Latin1 y los clientes envian en
> UTF8. Al hacer la reconversion, los caracteres se guardan corruptos. Y
> como Latin1 no hace chequeo de validez, se guardan incorrectamente.
>
> Cuando es al reves, no hay problema, porque el servidor rechaza
> caracteres UTF8 que no forman secuencias validas (UTF8 tiene chequeo de
> validez a diferencia de Latin1).
>
> Cuando la BD es SQL_ASCII tampoco ocurre este problema, porque el
> servidor no hace reconversion de caracteres (pero tiene otros problemas
> que se manifiestan cuando se conecta un cliente con una codificacion A y
> los lee un cliente con una condificacion B).
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

--
Miguel Panuera C.
STsoft Developer
mpanuera(at)gmail(dot)com
m(dot)panuera(at)stsoftperu(dot)com

cada caracter extraño va a devolver una serie de numeros
"195131198146195133194161"
simplemente asignamos a cada cadena de numeros una letra para hacer el
cambio en la funcion ObtenerLetra

case "a195131198146195133194161b":
$Letra="Ú"; break;

<?php
header('Content-Type: text/html; charset=UTF-8');
function CambiarPalabra($Palabra){
$Data="";
$Op=0;$Op1=0;
$Ini=-1;$Fin=-1;
$i=0;
while ($i<strlen($Palabra)){
$ord = ord($Palabra[$i]);
if (utf8_encode(chr($ord)) != utf8_decode(chr($ord))){
if ($Op==0){
if ($Ini!=-1){
//Falta modificar si se encuentran mas de 2
caracteres extraños separados en una misma palabra
}
$Ini=$i;
}
$Data.=$ord;
$Op=1;
}
else {
if ($Op==1){
$Fin=$i;
}
$Op=0;
}
$i++;
}
$Izq=substr($Palabra,0,$Ini);
$Der=substr($Palabra,$Fin);
$Letra=ObtenerLetra($Data);
$Word=$Izq.$Letra.$Der;
return $Word;
}
function ObtenerLetra($Num){
$Letra="???";
$Num="a".$Num."b";
switch ($Num) {
case "a195131198146195133194161b":
$Letra="Ú"; break;
case "a195131198146195162226130172197147b":
$Letra="Ó"; break;
case "a195131198146195130194141b":
$Letra="Í"; break;
case "a195131198146195130194129b":
$Letra="Á"; break;
case "a195131198146195162226130172194176b":
$Letra="É"; break;
case "a195131198146195162226130172203156b":
$Letra="Ñ"; break;
case
"a195131198146195133194161195131198146195162226130172203156b":
$Letra="ÚÑ"; break;
case "a195131197161195131226128152b":
$Letra="ÚÑ"; break;
case "a195131194141b":
$Letra="Í"; break;
case "a195131226128152b":
$Letra="Ñ"; break;
case "a195145b":
$Letra="Ñ"; break;
case "a195137b":
$Letra="É"; break;
case "a195131226128154195130194176b":
$Letra="ro."; break;
case "a195130194176b":
$Letra="ro."; break;
case "a195131226128156b":
$Letra="Ó"; break;
case "a195131226128176b":
$Letra="É"; break;
}
if ($Letra=="???"){
echo "<br>$Num<br>"; //Muestra el codigo de la letra no
encontrada para agregarlo
}
return $Letra;
}
$LINK = pg_connect("host=localhost user=postgres password=postgres
dbname=base");
$Sql="select usua_id, usua_nombre from usuarios";
$Query=pg_query($Sql);
$Sql="";
while ($Fila = pg_fetch_row($Query)){
$filas++;
$Encode=utf8_encode($Fila[1]);
$Decode=utf8_decode($Fila[1]);
$Nombres="";
if ($Encode!=$Decode){
$aNombre = split(" ",$Fila[1]);
foreach ($aNombre as $Palabra){
$newPalabra=$Palabra;
if (utf8_encode($Palabra)!=utf8_decode($Palabra)){
$newPalabra=CambiarPalabra($Palabra);
}
else {

}
$Nombres.=$newPalabra.' ';
}
$Nombres=trim($Nombres);
echo $Fila[0]." - ".$Nombres."<br>";
$Sql.="update usuarios set usua_direccion='$Nombres' where
usua_id=".$Fila[0].";";
}
}
$Query=pg_query($Sql);
echo $Sql;
?>

El día 23/08/07, Miguel Panuera <mpanuera(at)gmail(dot)com> escribió:
>
> llege a resolver el problema con un script en php, :D
> dentro de un momento les paso el codigo, no esta muy bien programado :S,
> pero funciona :p
>
>
> El día 23/08/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> >
> > Gabriel Hermes Colina Zambra escribió:
> >
> > > --- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> > > escribió:
> > >
> > > > Con estos casos raros que aparecen cada vez me
> > > > convenzo más que es mala
> > > > idea usar Latin1 como server_encoding :-(
> > > >
> > >
> > > Yo uso latin1 y no tengo problemas, pero lo he usado
> > > desde la instalacion de postgresql, la creacion de la
> > > base y hasta los clientes todo en Latin1, ahi si fue
> > > coherente.
> >
> > El problema ocurre cuando la BD esta en Latin1 y los clientes envian en
> > UTF8. Al hacer la reconversion, los caracteres se guardan corruptos. Y
> >
> > como Latin1 no hace chequeo de validez, se guardan incorrectamente.
> >
> > Cuando es al reves, no hay problema, porque el servidor rechaza
> > caracteres UTF8 que no forman secuencias validas (UTF8 tiene chequeo de
> > validez a diferencia de Latin1).
> >
> > Cuando la BD es SQL_ASCII tampoco ocurre este problema, porque el
> > servidor no hace reconversion de caracteres (pero tiene otros problemas
> > que se manifiestan cuando se conecta un cliente con una codificacion A y
> >
> > los lee un cliente con una condificacion B).
> >
> > --
> > Alvaro Herrera
> > http://www.CommandPrompt.com/
> > The PostgreSQL Company - Command Prompt, Inc.
> >
>
>
>
> --
> Miguel Panuera C.
> STsoft Developer
> mpanuera(at)gmail(dot)com
> m(dot)panuera(at)stsoftperu(dot)com
>

de funcionar funciona :P, no esta bien hechecito pero funciona

Gracias a todos los que me ayudaron :D

--
Miguel Panuera C.
STsoft Developer
mpanuera(at)gmail(dot)com
m(dot)panuera(at)stsoftperu(dot)com