>> 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 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 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 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 > -- "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
