8 replies to this topic

[Igor Brites]

Fala pessoal!! Meu primeiro post aki no fórum, espero q vcs possam me ajudar:

acho q o problema q eu to tendo, td mundo já deve ter passado um dia, por isso acho q vai ser fácil de vcs me ajudarem.

Tenho um banco MySQL, onde as tabelas estão com collation utf8_general_ci, e na minha página tenho a tag meta assim:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

Tinha ouvido falar q era suficiente pra eu trazer e gravar os dados no banco sem problema, mas ainda to tendo q usar o utf8_encode() em tudo, e tá ficando o código mais mal feito possível!!!

Então se alguém souber me falar pq tá acontecendo isso, eu agradeço demais!!!

Vlw!!!!

Obs: Já mudei esse encode nas configurações do php.ini e do Apache, por isso não sei mais oq fazer.

[Willian Gustavo Veiga]

Bom dia, tudo bem?

E a conexão com o banco de dados usa qual charset? Tente configura-la como UTF-8...

Um abraço.

[Igor Brites]

Bom dia, tudo bem?

E a conexão com o banco de dados usa qual charset? Tente configura-la como UTF-8...

Um abraço.

Blza Willian?? Vlw pela rapidez na resposta!

Então, já tá tbm com charset utf8. Tipo, não tem nada pra dar errado, mas dá, hehehe.

Se vc tiver outra ideia e puder mandar te agradeço demais!!

Vlw!

Attached Files

•  tabela.JPG   34.81KB   9 downloads

[Willian Gustavo Veiga]

Boa tarde, tudo bem?

Então... parece que você está falando do charset das tabelas. Eu estou falando do charset da conexão com o banco de dados. São duas coisas diferentes.

Veja as funções mysql_set_charset e mysql_client_encoding.

Um abraço. tudo de bom.

Edição feita por: Willian Gustavo Veiga, 28/12/2009, 12:32.

[Igor Brites]

Boa tarde, tudo bem?

Então... parece que você está falando do charset das tabelas. Eu estou falando do charset da conexão com o banco de dados. São duas coisas diferentes.

Veja as funções mysql_set_charset e mysql_client_encoding.

Um abraço. tudo de bom.

Willian, vc salvou o dia!!!

Realmente testei o charset com o mysql_client_encoding e tava latin1. Aí eu só troquei com o mysql_set_charset pra utf8 e funfou!!!

Fico te devendo essa!!!

Vlw!!!

[Paulo Freitas]

Você na verdade tem pelo menos 2 opções de collations para usar a codificação UTF-8 em bancos de dados que podem muito bem variar de acordo com as necessidades:

• utf8_general_ci: compara strings usando regras gerais de linguagem com comparação de caso-insensitivo (padrão)
• utf8_unicode_ci: compara strings usando a tabela DUCET (Default Unicode Collation Element Table) do padrão Unicode

A diferença básica entre ambos collations é que nas comparações do utf8_general_ci todos os caracteres acentuados são substituídos pelos respectivos caracteres não-acentuados. Isto é: ã se transforma em a, ü se transforma em u e por aí vai. E é justamente por isto que ele é menos preciso. No caso do caractere ß, por exemplo, ele será convertido para s - eis o problema: a conversão se dá por um único caractere.
No utf8_unicode_ci, este caractere ß por exemplo será comparado como ss, o que é o correto; dentre outros casos. Eis o motivo dele ser mais preciso. E é justamente pelo motivo dele trabalhar com uma tabela de substituições que o torna mais lento (nada muito significante, mas enfim...).

De modo geral, você deve usar utf8_general_ci por ele ser mais rápido e utf8_unicode_ci por ele ser mais preciso. A decisão fica por tua conta: performance ou precisão.

[]’sAté mais

[Igor Brites]

Você na verdade tem pelo menos 2 opções de collations para usar a codificação UTF-8 em bancos de dados que podem muito bem variar de acordo com as necessidades:

• utf8_general_ci: compara strings usando regras gerais de linguagem com comparação de caso-insensitivo (padrão)
• utf8_unicode_ci: compara strings usando a tabela DUCET (Default Unicode Collation Element Table) do padrão Unicode

A diferença básica entre ambos collations é que nas comparações do utf8_general_ci todos os caracteres acentuados são substituídos pelos respectivos caracteres não-acentuados. Isto é: ã se transforma em a, ü se transforma em u e por aí vai. E é justamente por isto que ele é menos preciso. No caso do caractere ß, por exemplo, ele será convertido para s - eis o problema: a conversão se dá por um único caractere.
No utf8_unicode_ci, este caractere ß por exemplo será comparado como ss, o que é o correto; dentre outros casos. Eis o motivo dele ser mais preciso. E é justamente pelo motivo dele trabalhar com uma tabela de substituições que o torna mais lento (nada muito significante, mas enfim...).

De modo geral, você deve usar utf8_general_ci por ele ser mais rápido e utf8_unicode_ci por ele ser mais preciso. A decisão fica por tua conta: performance ou precisão.

[]’s

Fala Paulo!

Boa ideia essa sua tbm!! Vou ver com o analista aki se ele topa, mas acho q vai sim.

Vlw a todos os que ajudaram aí!!!

Futuramente serei eu q vou ajudar o povo (se eu entender alguma coisa né? XD)!!!

Flw!!!

['' sem.Ponto]

comparações do utf8_general_ci todos os caracteres acentuados são substituídos pelos respectivos caracteres não-acentuados. Isto é: ã se transforma em a, ü se transforma em u e por aí vai.

O que você descreveu aí para utf8_general_ci ocorre com utf8_unicode_ci...

Nunca testei utf8_general_ci, mas com utf8_unicode_ci, se eu tenho por exemplo guaraná cadastrado no banco de dados e eu buscar por guarana, o registro é localizado. Ou seja, os acentos são ignorados, isso para mim é ótimo, por isso utilizo esse collation.

Você não trocou as bolas não? Ou isso ocorre com os 2 collations?

[Paulo Freitas]

O que você descreveu aí para utf8_general_ci ocorre com utf8_unicode_ci...

Nunca testei utf8_general_ci, mas com utf8_unicode_ci, se eu tenho por exemplo guaraná cadastrado no banco de dados e eu buscar por guarana, o registro é localizado. Ou seja, os acentos são ignorados, isso para mim é ótimo, por isso utilizo esse collation.

Você não trocou as bolas não? Ou isso ocorre com os 2 collations?

Isto ocorre nos 2 collations, a diferença é o exemplo do caso do caractere ß, que no utf8_general_ci é substituído por um único caractere - isto é, ocorrem substituições 1 para 1, enquanto no utf8_unicode_ci as substituições são 1 para N. Minhas sinceras desculpas se não fui claro.

Vale lembrar que o manual possui mais detalhes sobre: MySQL 5.1 Reference Manual :: 9 Internationalization and Localization :: 9.1 Character Set Support :: 9.1.13 Character Sets and Collations That MySQL Supports :: 9.1.13.1 Unicode Character Sets

[]’sAté mais