<br><br><div class="gmail_quote">Em 21 de outubro de 2010 06:57, Luis Motta Campos <span dir="ltr"><<a href="mailto:luismottacampos@yahoo.co.uk">luismottacampos@yahoo.co.uk</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 10/20/2010 02:44 PM, Stanislaw Pusep wrote:<br>
> Isto verifica se uma *string de octets* está de acordo com o<br>
> "protocolo" do UTF-8. Como dá para ver, não é nada eficiente. E,<br>
> antes de usar, precisa certificar-se de que todos os mecanismos<br>
> internos do Perl de lidar com codificações estejam desativados,<br>
> senão, no melhor caso, gerará uma pancada de warnings de "Wide<br>
> character..." Enfim, deixa pra lá a eficiência, essa foi a melhor<br>
> solução que encontrei depois de *anos* procurando :)<br>
<br>
</div>Hum. Na minha curta e humilde experiência com troca de dados (*) e<br>
codificações, a forma mais eficiente de resolver este problema é a que<br>
você aparentemente nunca experimentou: fixar a codificação e informar<br>
seus parceiros / fornecedores / clientes da "limitação" do sistema.<br>
<br></blockquote><div><br></div><div>Não adianta nada fixar, se o cabeçalho do XML diz que o conteúdo é UTF-8 quando nem todo o conteúdo do XML ou do diabo é UTF-8. Sim, isso acontece!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Eu aconselho fortemente a documentar e divulgar amplamente que o sistema<br>
trabalha com UTF8 (i.e., espera input de dados neste formato e devolve<br>
output no mesmo formato), e recusar serviço a todo mundo que não estiver<br>
conformante.<br></blockquote><div><br></div><div>Não, o sistema não trabalha com utf-8. Trabalha com ISO. ESSE é o problema!!! No final de tudo, a base está em ISO, no entanto, na grande maioria das vezes os XMLSs e páginas estão com suas respectivas codificações cagadas... A solução menos 'dolorida' por aqui foi criar tabelas de tradução de caracteres, incluindo mesmo para os caracteres com codificação cagada(utf-8 sem flag ativada e coisas do tipo). E a conversão ocorre para UTF-8 primeiro, por abranger um número maior de caracteres e então, no final de tudo, converter para ISO novamente. Funciona bem para a maioria dos casos, mas sempre sobram uns probleminhas.</div>
<div><br></div><div>O Stanislav, que trabalha aqui comigo atualmente, sugeriu uma solução específica utilizando iconv e um algoritmo que ele tirou de uma função do PHP(não me recordo qual), que funciona muito bem! Mas, é uma solução específica. De repente, um de vocês, ou até mesmo eu consiga uma boa solução genérica partindo do que o Stan fez.</div>
<div><br></div><div><br></div><div><br></div><div>stan++</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
E não me venha com baboseiras políticas sobre não querer desagradar seu<br>
cliente: eles vão ficar muito satisfeitos em saber que existe um padrão,<br>
assim que você quebrar a resistência a mudanças e eles entenderem o que<br>
você está fazendo.<br>
<br></blockquote><div><br></div><div>Clientes não estão nem aí para isso! O que eles querem resultado, e dane-se como faremos isso! Quem se importa em 'agradar o cliente' é a área comercial, que está se lixando para os problemas de TI(mas deveria...), e infelizmente isso acaba afetando o 'andar' e algumas vezes, a qualidade do trabalho, sim. E sei que você já viu esse filme antes por aqui :D Por aí já não sei ...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Para convencer seu supervisor, é mais simples: basta mostrar a ele a<br>
zorra heurística que você é obrigado a manter por causa da falta de<br>
padrão, e contabilizar por cima quantas horas de trabalho você teria<br>
disponível para investir em outros projetos por semana.<br>
<br></blockquote><div><br></div><div>Não tenho problemas com o meu supervisor, ele está totalmente por dentro dos problemas e do que é necessário, e a tendência realmente e felizmente é caminharmos para uma padronização 'de fato'. Mas os problemas que existem agora, e precisam ser solucionados agora, mesmo sem padronização! Ossos do ofício...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
E pronto, o problema não existe mais. :)<br></blockquote><div><br></div><div>Muito pelo contrário! Mas ainda bem que tem problema para resolver. Um pouco de desafio de vez em quando nunca fez mal pra ninguém...;-)</div><div>
</div><div><br></div><div><br></div><div><br></div><div>Cheers!</div><div><br></div><div><br></div><div><br></div></div>-- <br>André Garcia Carneiro<br>Analista/Desenvolvedor Perl<br>(11)82907780<br>