Re: [FUG-BR] Mysql não aceita acentos.
Esta opção é apenas para output de texto (print e echo), não tem nada a
ver com a conexão com o mysql.
Opções do módulo mysql são no formato mysql.opção.
Você realmente está disposto a dizer que não fiz a melhor solução, não?
Ajudaria se você lesse o que escrevo, e pricipalmente o porquê da solução
que usei.
Esta discussão não vai levar a nada.
Até,
Rafael.
On Sun, 25 Feb 2007 23:59:48 -0300, Eder [EMAIL PROTECTED] wrote:
Entendi,
Então isso pode ser alterado no arquivo php.ini, no default_charset, mais
mesmo assim é estranho.
Observe no código fonte do PHP em ext/mysql/php_mysql.c a função é bem
clara,
/* Returns the default character set for the current connection */
PHP_FUNCTION(mysql_client_encoding)
{...}
Att Eder.
On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote:
Não precisa de muito para fazer o teste não. Apenas rode o código a
seguir:
- teste.php
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1 /
titleCharacter-set de conexão com o mysql/title
/head
body
?php
// Ok, vamos brincar com um texto antes usando o que temos de charset
// de conexão padrão no servidor (deveria ser latin1, se não foi
ajustado
// outra coisa ao compilar a biblioteca)
mysql_connect( localhost, root, leleafar );
// Vamos ver qual é o charset padrão usado na conexão.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Bom, vamos fazer uma tabelinha com o charset latin1 no banco test
// que o mysql cria por padrão
if (mysql_query(create table if not exists `test`.`chartest` (texto
TEXT)
character set latin1;))
echo pTabela criada!/p;
else {
echo pErro ao criar a tabela./p;
exit(0);
}
// Beleza, vamos fazer um teste para guardar o texto com acentuação
$texto = áéíóçãõà;
echo pTexto para testes: $texto (deve estar aparecendo corretamente
no
navegador!)/p\n;
mysql_query(insert into `test`.`chartest` set texto = '$texto';);
// Vamos ver o que ele guardou?
$r = mysql_fetch_row(mysql_query(select texto from
`test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
// isto não deveria acontecer se seu módulo mysql estiver em
latin1
echo pOpa, o texto foi modificado! Texto retornado:
$r[0]/p\n;
mysql_close();
// Ok, o legal é que o código acima tenha como resultado o texto
permanecer igual. Isto quer dizer que nossa conexão é latin1,
// Mas, qual seria o resultado se nossa conexão fosse, por padrão, em
utf-8? Vamos descobrir.
mysql_connect( localhost, root, leleafar );
// Vamos mudar o charset da conexão apenas (deve ser a primeira coisa a
ser feita, pelo o que está na documentação);
// Leia sobre isto onde indiquei anteriormente:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
mysql_query(set NAMES utf8;);
// Vamos fazer nosso teste de descobrir qual o charset padrão para
verificar se deu certo a query anterior.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
// Deve mostrar utf8 como resultado.
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Vamos ver o que ele retorna pra gente agora?
$r = mysql_fetch_row(mysql_query(select texto from
`test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
echo pOpa, o texto foi modificado! Texto retornado:
$r[0]/p\n;
// Se o charset padrão desta conexão for utf-8, você já percebeu que o
texto foi alterado... mas nem tanto!
// Na verdade, seu texto foi retornado em utf-8, MESMO COM A TABELA
MARCADA COMO LATIN1
// Vamos conferir?
if ($texto == utf8_decode($r[0]))
echo pÉ o mesmo texto realmente, só que foi retornado em
UTF-8!/p\n;
/* Entendeu o problema? O problema não é na tabela, nem no locale, e sim
no charset usado pelo módulo php, que tem
o charset padrão dependente de como foi compilada antes a biblioteca do
mysql, pois não conheço arquivo de
configuração para esta biblioteca. */
// Vamos acabar com nossa tabela de testes
mysql_query(drop table `test`.`chartest`;);
mysql_close();
?
/body
- fim
Como te disse, no meu caso, é complicado ajustar os scripts para usar
uft8_decode ou a query de mudar o charset da conexão num site de mais
de 8
anos (onde trabalhei apenas nos 2 últimos), que passou por várias
pessoas
diferentes, e com vários setores desenvolvidos por pessoas diferentes,
quase sempre de maneira totalmente desorganizada.
A solução simples e eficiente no meu caso foi recompilar a biblioteca e
o
módulo para usarem latin1 como padrão de conexão, pois estavam em utf-8.
Acho que agora estará satisfeito, vendo o resultado disto com os
próprios
olhos.
Até,
Rafael.
On Sun, 25 Feb 2007 13:32:16 -0300, Eder [EMAIL PROTECTED]
Re: [FUG-BR] Mysql não aceita acentos.
Se você deixou o seu Apache2 com a configuração default, ele estará servindo todas as páginas com o charset UTF8. Você resolve mudando a configuração do charset do Apache2 para ISO8859-1. Alternativamente, você poderá adicionar ao cabeçalho das páginas geradas a partir do PHP uma declaração META informando que o conteúdo desta usa outro charset, da seguinte forma: meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 Se você tiver acesso a configuração do Apache, prefira a primeira opção. []'s Márcio Luís Günther mailto:[EMAIL PROTECTED] http://www.MarcioGunther.com * Esta mensagem pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas informações. O sistema de mensagens da Internet não é considerado seguro ou livre de erros. Esta empresa não se responsabiliza por opiniões ou declarações veiculadas através de e-mails. * The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Márcio Günther CS - Segurança da Informação -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eder Sent: Sunday, February 25, 2007 12:37 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Mysql não aceita acentos. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que
Re: [FUG-BR] Mysql não aceita acentos.
Como te disse, no caso do que aconteceu comigo e com nosso colega de lista, mudar o charset da tabela não resolveria. Eu tentei explicar da melhor maneira possível mas se ainda assim não acredita no que estou explicando, espero que não venha a ter o problema que tivemos. Até, Rafael. On Sun, 25 Feb 2007 12:37:17 -0300, Eder [EMAIL PROTECTED] wrote: No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. O que tinha sugerido para solução é justamente isto: recompilando o mysql-server, seria recompilada também a biblioteca, usando o mesmo charset para conexões por padrão, se o módulo do php dele fosse linkado dinamicamente isto já resolveria também o problema dentro do php (se o módulo for linkado estaticamente com a biblioteca mysql, seria necessário recompilá-lo também!), então ele não seria obrigado a usar as funções utf8 sempre que quisesse fazer uma query ao banco. Se ele não tiver um computador que seja antigo a ponto de isto ser proibitivo, é mais simples fazer o que sugeri ao invéz de tudo o que envolveria se fosse resolver de outro modo. Claro que eu estava me baseando no meu caso, num site onde existem vários sub-sites, cada um feito por um tipo de pessoa, com nível de conhecimento também variável, pior seria se eu me preocupasse em ajustar isto pelo php. E acreditei que isto também serviria para ele, até porque seria uma chamada de função a menos para cada query. O que eu tinha entendido, pela sua primeira mensagem, era que você esperava que o problema fosse solucionado com a mudança do charset da tabela, o que ele já havia tentado. Por isto, pensei que você não estivesse muito a par de outras
Re: [FUG-BR] Mysql não aceita acentos.
Em momento algum disse que não acreditava em suas explicações, tanto que não contestei o resto do email, porque o que falou está correto. Simplesmente procurei, e não encontrei nada que o justificase, inclusive compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL, mais não tive o problema, agora se eu alterar os caracteres no database do MySQL para outro tipo, os acentos não entram corretos, ou entram de forma errônea. Em Latin1 funciona corretamente. espero que não venha a ter o problema que tivemos. R = Eu espero ter sim, assim posso testar realmente se o que falou, se contesta, como posso simular o erro? Att Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Como te disse, no caso do que aconteceu comigo e com nosso colega de lista, mudar o charset da tabela não resolveria. Eu tentei explicar da melhor maneira possível mas se ainda assim não acredita no que estou explicando, espero que não venha a ter o problema que tivemos. Até, Rafael. On Sun, 25 Feb 2007 12:37:17 -0300, Eder [EMAIL PROTECTED] wrote: No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. O que tinha sugerido para solução é justamente isto: recompilando o mysql-server, seria recompilada também a biblioteca, usando o mesmo charset para conexões por padrão, se o módulo do php dele fosse linkado dinamicamente isto já resolveria também o problema dentro do php (se o módulo for linkado estaticamente com a biblioteca mysql, seria necessário recompilá-lo também!), então ele não seria obrigado a usar as funções utf8 sempre que quisesse fazer uma query ao banco. Se ele não tiver
Re: [FUG-BR] Mysql não aceita acentos.
Não precisa de muito para fazer o teste não. Apenas rode o código a seguir:
- teste.php
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
/
titleCharacter-set de conexão com o mysql/title
/head
body
?php
// Ok, vamos brincar com um texto antes usando o que temos de charset
// de conexão padrão no servidor (deveria ser latin1, se não foi ajustado
// outra coisa ao compilar a biblioteca)
mysql_connect( localhost, root, leleafar );
// Vamos ver qual é o charset padrão usado na conexão.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Bom, vamos fazer uma tabelinha com o charset latin1 no banco test
// que o mysql cria por padrão
if (mysql_query(create table if not exists `test`.`chartest` (texto TEXT)
character set latin1;))
echo pTabela criada!/p;
else {
echo pErro ao criar a tabela./p;
exit(0);
}
// Beleza, vamos fazer um teste para guardar o texto com acentuação
$texto = áéíóçãõà;
echo pTexto para testes: $texto (deve estar aparecendo corretamente no
navegador!)/p\n;
mysql_query(insert into `test`.`chartest` set texto = '$texto';);
// Vamos ver o que ele guardou?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
// isto não deveria acontecer se seu módulo mysql estiver em latin1
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
mysql_close();
// Ok, o legal é que o código acima tenha como resultado o texto
permanecer igual. Isto quer dizer que nossa conexão é latin1,
// Mas, qual seria o resultado se nossa conexão fosse, por padrão, em
utf-8? Vamos descobrir.
mysql_connect( localhost, root, leleafar );
// Vamos mudar o charset da conexão apenas (deve ser a primeira coisa a
ser feita, pelo o que está na documentação);
// Leia sobre isto onde indiquei anteriormente:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
mysql_query(set NAMES utf8;);
// Vamos fazer nosso teste de descobrir qual o charset padrão para
verificar se deu certo a query anterior.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
// Deve mostrar utf8 como resultado.
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Vamos ver o que ele retorna pra gente agora?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
// Se o charset padrão desta conexão for utf-8, você já percebeu que o
texto foi alterado... mas nem tanto!
// Na verdade, seu texto foi retornado em utf-8, MESMO COM A TABELA
MARCADA COMO LATIN1
// Vamos conferir?
if ($texto == utf8_decode($r[0]))
echo pÉ o mesmo texto realmente, só que foi retornado em
UTF-8!/p\n;
/* Entendeu o problema? O problema não é na tabela, nem no locale, e sim
no charset usado pelo módulo php, que tem
o charset padrão dependente de como foi compilada antes a biblioteca do
mysql, pois não conheço arquivo de
configuração para esta biblioteca. */
// Vamos acabar com nossa tabela de testes
mysql_query(drop table `test`.`chartest`;);
mysql_close();
?
/body
- fim
Como te disse, no meu caso, é complicado ajustar os scripts para usar
uft8_decode ou a query de mudar o charset da conexão num site de mais de 8
anos (onde trabalhei apenas nos 2 últimos), que passou por várias pessoas
diferentes, e com vários setores desenvolvidos por pessoas diferentes,
quase sempre de maneira totalmente desorganizada.
A solução simples e eficiente no meu caso foi recompilar a biblioteca e o
módulo para usarem latin1 como padrão de conexão, pois estavam em utf-8.
Acho que agora estará satisfeito, vendo o resultado disto com os próprios
olhos.
Até,
Rafael.
On Sun, 25 Feb 2007 13:32:16 -0300, Eder [EMAIL PROTECTED] wrote:
Em momento algum disse que não acreditava em suas explicações,
tanto que não contestei o resto do email, porque o que falou está
correto.
Simplesmente procurei, e não encontrei nada que o justificase, inclusive
compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL,
mais não tive o problema, agora se eu alterar os caracteres no database
do MySQL
para outro tipo, os acentos não entram corretos, ou entram de forma
errônea.
Em Latin1 funciona corretamente.
espero que não venha a ter o problema que tivemos.
R = Eu espero ter sim, assim posso testar realmente se o que falou,
se contesta, como posso simular o erro?
Att Eder.
On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote:
Como te disse, no caso do que aconteceu comigo e com nosso colega de
lista, mudar o charset da tabela não resolveria.
Eu tentei explicar da melhor maneira possível mas se
Re: [FUG-BR] Mysql não aceita acentos.
Entendi,
Então isso pode ser alterado no arquivo php.ini, no default_charset, mais
mesmo assim é estranho.
Observe no código fonte do PHP em ext/mysql/php_mysql.c a função é bem
clara,
/* Returns the default character set for the current connection */
PHP_FUNCTION(mysql_client_encoding)
{...}
Att Eder.
On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote:
Não precisa de muito para fazer o teste não. Apenas rode o código a seguir:
- teste.php
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1 /
titleCharacter-set de conexão com o mysql/title
/head
body
?php
// Ok, vamos brincar com um texto antes usando o que temos de charset
// de conexão padrão no servidor (deveria ser latin1, se não foi ajustado
// outra coisa ao compilar a biblioteca)
mysql_connect( localhost, root, leleafar );
// Vamos ver qual é o charset padrão usado na conexão.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Bom, vamos fazer uma tabelinha com o charset latin1 no banco test
// que o mysql cria por padrão
if (mysql_query(create table if not exists `test`.`chartest` (texto TEXT)
character set latin1;))
echo pTabela criada!/p;
else {
echo pErro ao criar a tabela./p;
exit(0);
}
// Beleza, vamos fazer um teste para guardar o texto com acentuação
$texto = áéíóçãõà;
echo pTexto para testes: $texto (deve estar aparecendo corretamente no
navegador!)/p\n;
mysql_query(insert into `test`.`chartest` set texto = '$texto';);
// Vamos ver o que ele guardou?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
// isto não deveria acontecer se seu módulo mysql estiver em latin1
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
mysql_close();
// Ok, o legal é que o código acima tenha como resultado o texto
permanecer igual. Isto quer dizer que nossa conexão é latin1,
// Mas, qual seria o resultado se nossa conexão fosse, por padrão, em
utf-8? Vamos descobrir.
mysql_connect( localhost, root, leleafar );
// Vamos mudar o charset da conexão apenas (deve ser a primeira coisa a
ser feita, pelo o que está na documentação);
// Leia sobre isto onde indiquei anteriormente:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
mysql_query(set NAMES utf8;);
// Vamos fazer nosso teste de descobrir qual o charset padrão para
verificar se deu certo a query anterior.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
// Deve mostrar utf8 como resultado.
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Vamos ver o que ele retorna pra gente agora?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
// Se o charset padrão desta conexão for utf-8, você já percebeu que o
texto foi alterado... mas nem tanto!
// Na verdade, seu texto foi retornado em utf-8, MESMO COM A TABELA
MARCADA COMO LATIN1
// Vamos conferir?
if ($texto == utf8_decode($r[0]))
echo pÉ o mesmo texto realmente, só que foi retornado em
UTF-8!/p\n;
/* Entendeu o problema? O problema não é na tabela, nem no locale, e sim
no charset usado pelo módulo php, que tem
o charset padrão dependente de como foi compilada antes a biblioteca do
mysql, pois não conheço arquivo de
configuração para esta biblioteca. */
// Vamos acabar com nossa tabela de testes
mysql_query(drop table `test`.`chartest`;);
mysql_close();
?
/body
- fim
Como te disse, no meu caso, é complicado ajustar os scripts para usar
uft8_decode ou a query de mudar o charset da conexão num site de mais de 8
anos (onde trabalhei apenas nos 2 últimos), que passou por várias pessoas
diferentes, e com vários setores desenvolvidos por pessoas diferentes,
quase sempre de maneira totalmente desorganizada.
A solução simples e eficiente no meu caso foi recompilar a biblioteca e o
módulo para usarem latin1 como padrão de conexão, pois estavam em utf-8.
Acho que agora estará satisfeito, vendo o resultado disto com os próprios
olhos.
Até,
Rafael.
On Sun, 25 Feb 2007 13:32:16 -0300, Eder [EMAIL PROTECTED] wrote:
Em momento algum disse que não acreditava em suas explicações,
tanto que não contestei o resto do email, porque o que falou está
correto.
Simplesmente procurei, e não encontrei nada que o justificase, inclusive
compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL,
mais não tive o problema, agora se eu alterar os caracteres no database
do MySQL
para outro tipo, os acentos não entram corretos, ou entram de forma
errônea.
Em Latin1
Re: [FUG-BR] Mysql não aceita acentos.
Olá, Basta alterar o character sets. mysql SHOW CHARACTER SET; http://dev.mysql.com/doc/refman/5.0/en/charset-mysql.html Att, eder. On 2/23/07, Rafael Fernandes [EMAIL PROTECTED] wrote: É amigo eu passei por isto e normalmente o mysql fica com o charset compilado tanto no servidor quanto no cliente (ou bibliotecas usadas por outros programas, no caso o php). O que solucionou meu problema 100% foi recompilar o mysql-server (se não me engano, isto já recompila a biblioteca mysql-server, mas confira). Recompile também o módulo mysql do php se ele foi linkado estaticamente com a biblioteca mysql. Lembre-se sempre que usamos latin1/iso-8859-1 (são a mesma coisa) e irá evitar muita dor de cabeça. Até, Rafael. On Fri, 23 Feb 2007 11:56:32 -0200, Rafael Stockler [EMAIL PROTECTED] wrote: Bom dia a todos, Estou com o seguinte problema. Tenho aqui instalado o Apache 2, php 5 e mysql 5. O problema que estou enfrentando é o fato de o mysql não estar cadastrando palavras com acentos. Verifiquei se o php estava mostrando certo e pelo q vi sim. O charset no mysql eh o utf8-general. Jah tentei colocar o latin 1 e outras e nada. Alguem já passou por isso ou saberia o q pode ser isso? Vlw. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Do not worry about your difficulties in mathematics; I can assure you that mine are still greater. Albert Einstein - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql não aceita acentos.
O problema, Eder, é que pode haver uma diferença de charset usado na conexão entre o cliente e o servidor mysql. Normalmente, no módulo php, isto acarreta em aleatoriamente você receber os dados em latin1 e utf-8, mesmo quando uma tabela está com a opção de charset em latin1. E o problema continua mesmo depois de mudado o charset de uma tabela que era utf-8 para latin1. Como disse, não é um problema no chaset usado pelo servidor, mas sim pela conexão entre o servidor e um cliente mysql, pois nessa ele tenta fazer uma conversão de charsets. Leia sobre isto aqui: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html Este problema aconteceu comigo quando migrei um banco de dados de um servidor para outro. Como o charset da tabela não foi alterado, não era para ocorrer este tipo de problema. E a única diferença entre um servidor e outro era que o charset padrão usado nas conexões era diferente (latin1 no antigo, utf-8 no novo). A única coisa que fez os resultados de queries serem consistentes foi certificando que ambos os binários (cliente e servidor) usavam o mesmo charset padrão para conexões. E infelizmente isto fica compilado com os binários, não fica em um arquivo de configuração. Senão não precisaríamos de ajustar esta opção ao compilar o mysql, certo? Então, me desculpe, mas listar os charsets disponíveis para as tabelas não resolveria o problema do nosso amigo da lista. Até, Rafael. On Sat, 24 Feb 2007 15:20:04 -0200, Eder [EMAIL PROTECTED] wrote: Olá, Basta alterar o character sets. mysql SHOW CHARACTER SET; http://dev.mysql.com/doc/refman/5.0/en/charset-mysql.html Att, eder. On 2/23/07, Rafael Fernandes [EMAIL PROTECTED] wrote: É amigo eu passei por isto e normalmente o mysql fica com o charset compilado tanto no servidor quanto no cliente (ou bibliotecas usadas por outros programas, no caso o php). O que solucionou meu problema 100% foi recompilar o mysql-server (se não me engano, isto já recompila a biblioteca mysql-server, mas confira). Recompile também o módulo mysql do php se ele foi linkado estaticamente com a biblioteca mysql. Lembre-se sempre que usamos latin1/iso-8859-1 (são a mesma coisa) e irá evitar muita dor de cabeça. Até, Rafael. On Fri, 23 Feb 2007 11:56:32 -0200, Rafael Stockler [EMAIL PROTECTED] wrote: Bom dia a todos, Estou com o seguinte problema. Tenho aqui instalado o Apache 2, php 5 e mysql 5. O problema que estou enfrentando é o fato de o mysql não estar cadastrando palavras com acentos. Verifiquei se o php estava mostrando certo e pelo q vi sim. O charset no mysql eh o utf8-general. Jah tentei colocar o latin 1 e outras e nada. Alguem já passou por isso ou saberia o q pode ser isso? Vlw. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql não aceita acentos.
Oi, O problema, Eder, é que pode haver uma diferença de charset usado na conexão entre o cliente e o servidor mysql. R = Obviamente que pode haver, por isso existem os locales. Tanto no banco quanto na linguagem, não entendo muito de PHP, mais em C, C++ basta passar o locale. Normalmente, no módulo php, isto acarreta em aleatoriamente você receber os dados em latin1 e utf-8, mesmo quando uma tabela está com a opção de charset em latin1. R = Não, defina o que é aleatoriamente no seu conceito acima. E o problema continua mesmo depois de mudado o charset de uma tabela que era utf-8 para latin1. Como disse, não é um problema no chaset usado pelo servidor, mas sim pela conexão entre o servidor e um cliente mysql, pois nessa ele tenta fazer uma conversão de charsets. Leia sobre isto aqui: R = Concordo, então no PHP set o locale, setlocale(LC_COLLATE, pt_BR.ISO8859-1); A única coisa que fez os resultados de queries serem consistentes foi certificando que ambos os binários (cliente e servidor) usavam o mesmo charset padrão para conexões. E infelizmente isto fica compilado com os binários, não fica em um arquivo de configuração. Senão não precisaríamos de ajustar esta opção ao compilar o mysql, certo? R = Errado, não é necessário recompilar o MySQL para configurar isso, se ele por padrão já é compilado com suporte aos characters. mysql SHOW VARIABLES LIKE 'coll%'; mysql SHOW VARIABLES LIKE 'character%'; No arquivo de configuração do mysql no /etc/my.cnf basta setar o locale. [mysqld] character_sets_dir=/usr/local/share/mysql/charsets/ default-character-set=utf8 default-collation=utf8_general_ci [client] default-character-set=utf8 Então, me desculpe, mas listar os charsets disponíveis para as tabelas não resolveria o problema do nosso amigo da lista. R = Realmente digitar o comando não resolveria em nada. Att Eder, On 2/24/07, Rafael Fernandes [EMAIL PROTECTED] wrote: O problema, Eder, é que pode haver uma diferença de charset usado na conexão entre o cliente e o servidor mysql. Normalmente, no módulo php, isto acarreta em aleatoriamente você receber os dados em latin1 e utf-8, mesmo quando uma tabela está com a opção de charset em latin1. E o problema continua mesmo depois de mudado o charset de uma tabela que era utf-8 para latin1. Como disse, não é um problema no chaset usado pelo servidor, mas sim pela conexão entre o servidor e um cliente mysql, pois nessa ele tenta fazer uma conversão de charsets. Leia sobre isto aqui: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html Este problema aconteceu comigo quando migrei um banco de dados de um servidor para outro. Como o charset da tabela não foi alterado, não era para ocorrer este tipo de problema. E a única diferença entre um servidor e outro era que o charset padrão usado nas conexões era diferente (latin1 no antigo, utf-8 no novo). A única coisa que fez os resultados de queries serem consistentes foi certificando que ambos os binários (cliente e servidor) usavam o mesmo charset padrão para conexões. E infelizmente isto fica compilado com os binários, não fica em um arquivo de configuração. Senão não precisaríamos de ajustar esta opção ao compilar o mysql, certo? Então, me desculpe, mas listar os charsets disponíveis para as tabelas não resolveria o problema do nosso amigo da lista. Até, Rafael. On Sat, 24 Feb 2007 15:20:04 -0200, Eder [EMAIL PROTECTED] wrote: Olá, Basta alterar o character sets. mysql SHOW CHARACTER SET; http://dev.mysql.com/doc/refman/5.0/en/charset-mysql.html Att, eder. On 2/23/07, Rafael Fernandes [EMAIL PROTECTED] wrote: É amigo eu passei por isto e normalmente o mysql fica com o charset compilado tanto no servidor quanto no cliente (ou bibliotecas usadas por outros programas, no caso o php). O que solucionou meu problema 100% foi recompilar o mysql-server (se não me engano, isto já recompila a biblioteca mysql-server, mas confira). Recompile também o módulo mysql do php se ele foi linkado estaticamente com a biblioteca mysql. Lembre-se sempre que usamos latin1/iso-8859-1 (são a mesma coisa) e irá evitar muita dor de cabeça. Até, Rafael. On Fri, 23 Feb 2007 11:56:32 -0200, Rafael Stockler [EMAIL PROTECTED] wrote: Bom dia a todos, Estou com o seguinte problema. Tenho aqui instalado o Apache 2, php 5 e mysql 5. O problema que estou enfrentando é o fato de o mysql não estar cadastrando palavras com acentos. Verifiquei se o php estava mostrando certo e pelo q vi sim. O charset no mysql eh o utf8-general. Jah tentei colocar o latin 1 e outras e nada. Alguem já passou por isso ou saberia o q pode ser isso? Vlw. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da
Re: [FUG-BR] Mysql não aceita acentos.
Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. O que tinha sugerido para solução é justamente isto: recompilando o mysql-server, seria recompilada também a biblioteca, usando o mesmo charset para conexões por padrão, se o módulo do php dele fosse linkado dinamicamente isto já resolveria também o problema dentro do php (se o módulo for linkado estaticamente com a biblioteca mysql, seria necessário recompilá-lo também!), então ele não seria obrigado a usar as funções utf8 sempre que quisesse fazer uma query ao banco. Se ele não tiver um computador que seja antigo a ponto de isto ser proibitivo, é mais simples fazer o que sugeri ao invéz de tudo o que envolveria se fosse resolver de outro modo. Claro que eu estava me baseando no meu caso, num site onde existem vários sub-sites, cada um feito por um tipo de pessoa, com nível de conhecimento também variável, pior seria se eu me preocupasse em ajustar isto pelo php. E acreditei que isto também serviria para ele, até porque seria uma chamada de função a menos para cada query. O que eu tinha entendido, pela sua primeira mensagem, era que você esperava que o problema fosse solucionado com a mudança do charset da tabela, o que ele já havia tentado. Por isto, pensei que você não estivesse muito a par de outras causas para o problema inicial, assim como a pessoa que o colocou em questão. Não foi minha intenção caçoar de você, apenas esclarecer o porquê da minha sugestão. ;) Até, Rafael. Oi, O problema, Eder, é que pode haver uma diferença de charset usado na conexão entre o cliente e o servidor mysql. R = Obviamente que pode haver, por isso existem os locales. Tanto no banco quanto na linguagem, não entendo muito de PHP, mais em C, C++ basta passar o locale. E o problema continua mesmo depois de mudado o charset de uma tabela que era utf-8 para latin1. Como disse, não é um problema no chaset usado pelo servidor, mas sim pela conexão entre o servidor e um cliente mysql, pois nessa ele tenta fazer uma conversão de charsets. Leia sobre isto aqui: R = Concordo, então no PHP set o locale, setlocale(LC_COLLATE, pt_BR.ISO8859-1); A única coisa que fez os resultados de queries serem consistentes foi certificando que ambos os binários (cliente e servidor) usavam o mesmo charset padrão para conexões. E infelizmente isto fica compilado com os binários, não fica em um arquivo de configuração. Senão
[FUG-BR] Mysql não aceita acentos.
Bom dia a todos, Estou com o seguinte problema. Tenho aqui instalado o Apache 2, php 5 e mysql 5. O problema que estou enfrentando é o fato de o mysql não estar cadastrando palavras com acentos. Verifiquei se o php estava mostrando certo e pelo q vi sim. O charset no mysql eh o utf8-general. Jah tentei colocar o latin 1 e outras e nada. Alguem já passou por isso ou saberia o q pode ser isso? Vlw. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql não aceita acentos.
É amigo eu passei por isto e normalmente o mysql fica com o charset compilado tanto no servidor quanto no cliente (ou bibliotecas usadas por outros programas, no caso o php). O que solucionou meu problema 100% foi recompilar o mysql-server (se não me engano, isto já recompila a biblioteca mysql-server, mas confira). Recompile também o módulo mysql do php se ele foi linkado estaticamente com a biblioteca mysql. Lembre-se sempre que usamos latin1/iso-8859-1 (são a mesma coisa) e irá evitar muita dor de cabeça. Até, Rafael. On Fri, 23 Feb 2007 11:56:32 -0200, Rafael Stockler [EMAIL PROTECTED] wrote: Bom dia a todos, Estou com o seguinte problema. Tenho aqui instalado o Apache 2, php 5 e mysql 5. O problema que estou enfrentando é o fato de o mysql não estar cadastrando palavras com acentos. Verifiquei se o php estava mostrando certo e pelo q vi sim. O charset no mysql eh o utf8-general. Jah tentei colocar o latin 1 e outras e nada. Alguem já passou por isso ou saberia o q pode ser isso? Vlw. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
