Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Boa tarde pessoal!
Tiro um extrato do Bradesco em formato .txt, copio e colo pra um campo texto no mysql. Aí uma das linhas do extrato está assim:
DATA HISTÓRICO DOCTO CRÉDITO DÉBITO SALDO
Se eu tentar:
$extrato = str_replace("HISTÓRICO", "bla bla", $extrato);
Simplesmente não vai!
Se eu tentar:
$extrato = str_replace("HISTÓRICO", "bla bla", $extrato);
Também não!
Na hora de exibir no php aparece:
HIST�RICO / CR�DITO / D�BITO
O que posso fazer?
Talvez seja uma pergunta bem estúpida, mas estou há anos sem mexer com isso e to totalmente enferrujado. Tentei fazer uma busca e não encontrei nada... :/
Obrigado
Isso né?
<meta http-equiv="Content-Type" content="text/html; charset="utf-8" />
Já estava... :/
Não importa qual escolha: UTF-8, Ansi/ISO-8859-1 ou qualquer outro. Entretanto, deve manter em todos os arquivos assim.
Você deverá verificar em 4 lugares a codificação:
- A definição do charset do HTML (tag meta);
- A definição do charset do arquivo (você pode verificar em um editor de texto como o notepad++);
- A definição do charset utilizado para o banco de dados (no caso de utilizar Ansi/ISO-8859-1, no SGDB MySQL por exemplo, você definirá o charset como Latin1);Existem outras soluções paliativas, mas como o nome mesmo já diz, são apenas temporárias (como definir header PHP). Podem não solucionar o seu problema em específico.
Tem uma aspas a mais na sua meta tag:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Olha que estranho...
Na verdade estava dessa forma que você passou, GABRIEL HEMING, sem essa aspas. Aí fui re-digitar o código e coloquei da forma que coloquei ali (com uma aspas a mais) e agora funcionou! :wacko:
Tá exibindo certinho agora:
DATA HISTÓRICO DOCTO CRÉDITO DÉBITO SALDO
Problema é que o str_replace continua não "dando conta".
Pelo menos na hora do echo"$extrato"; não tá aparecendo mais ���.
Se você colocou com uma aspas a mais, a tag não está correndo, significa que não está sendo reconhecida e o arquivo pode não ser UTF-8. Verifique o que está utilizando para o SGBD e nos arquivos.
A título de curiosidade, essa palestra explica bem os problemas de encoding... Todas as soluções que usamos são paleativas, e não resolvem necessariamente o problema.
http://www.slideshare.net/dextra/minicurso-encoding-tdc2012-13988649
Putz, fiquei mais perdido ainda. Não imaginei que tivesse tão enferrujado depois desse tempo todo.
Fala do tipo do campo texto do sql?? utf8_general_ci
Antes tava latin2_general_ci, que foi o padrão quando o bd foi criado...
Ou nada ver isso?
A título de curiosidade, essa palestra explica bem os problemas de encoding... Todas as soluções que usamos são paleativas, e não resolvem necessariamente o problema.
http://www.slideshare.net/dextra/minicurso-encoding-tdc2012-13988649
Opa, vou dar uma olhada, obrigado!!
Tem impacto sim. Se já existiam registros no SGBD enquanto a codificação era latin2, ao alterar a codificação para utf8, os dados já inseridos continuarão em latin2. Você terá que convertê-los.
Ainda assim, antes de escolher um padrão definitivo, verifique o formato que os arquivos estão sendo salvos. Você deve manter no mesmo formato.
Coloca no seu código a codificação utf-8 unicode. Deve funcionar, sem precisar no replace.