[SP-pm] trabalhando com UTF-8 e ISO-8859-1 simultaneamente

[Andre Carneiro]

Em 21 de outubro de 2010 06:57, Luis Motta Campos <
luismottacampos at yahoo.co.uk> escreveu:

> On 10/20/2010 02:44 PM, Stanislaw Pusep wrote:
> > Isto verifica se uma *string de octets* está de acordo com o
> > "protocolo" do UTF-8. Como dá para ver, não é nada eficiente. E,
> > antes de usar, precisa certificar-se de que todos os mecanismos
> > internos do Perl de lidar com codificações estejam desativados,
> > senão, no melhor caso, gerará uma pancada de warnings de "Wide
> > character..." Enfim, deixa pra lá a eficiência, essa foi a melhor
> > solução que encontrei depois de *anos* procurando :)
>
> Hum. Na minha curta e humilde experiência com troca de dados (*) e
> codificações, a forma mais eficiente de resolver este problema é a que
> você aparentemente nunca experimentou: fixar a codificação e informar
> seus parceiros / fornecedores / clientes da "limitação" do sistema.
>
>
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!


> Eu aconselho fortemente a documentar e divulgar amplamente que o sistema
> trabalha com UTF8 (i.e., espera input de dados neste formato e devolve
> output no mesmo formato), e recusar serviço a todo mundo que não estiver
> conformante.
>

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.

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.



stan++



>
> E não me venha com baboseiras políticas sobre não querer desagradar seu
> cliente: eles vão ficar muito satisfeitos em saber que existe um padrão,
> assim que você quebrar a resistência a mudanças e eles entenderem o que
> você está fazendo.
>
>
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 ...


> Para convencer seu supervisor, é mais simples: basta mostrar a ele a
> zorra heurística que você é obrigado a manter por causa da falta de
> padrão, e contabilizar por cima quantas horas de trabalho você teria
> disponível para investir em outros projetos por semana.
>
>
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...


> E pronto, o problema não existe mais. :)
>

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...;-)




Cheers!



-- 
André Garcia Carneiro
Analista/Desenvolvedor Perl
(11)82907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20101021/f749ebb8/attachment.html>