[FUG-BR] Mysql não aceita acentos.

Eder ederbsd em gmail.com
Domingo Fevereiro 25 13:32:16 BRT 2007


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 <ragatol at netsite.com.br> 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 <ederbsd at gmail.com> 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 <ragatol at netsite.com.br> 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 <ragatol at netsite.com.br> 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 <ederbsd at gmail.com> 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 <ragatol at netsite.com.br> 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
> >> >> >> <rafael.stockler at gmail.com> 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
> >>
> >
> >
>
>
> -------------------------
> 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


Mais detalhes sobre a lista de discussão freebsd