Você já é fluente em Unicode?

Question

Quase 5 anos atrás, Joel Spolsky escreveu este artigo, "O mínimo absoluto que todo desenvolvedor de software deve saber absolutamente e positivamente sobre Unicode e conjuntos de caracteres (sem desculpas!)".

Como muitos, li-o com atenção, percebendo que já era hora de lidar com esse "substituto do ASCII".Infelizmente, 5 anos depois, sinto que voltei a adquirir alguns maus hábitos nesta área.Você já?

Não escrevo muitos aplicativos especificamente internacionais, mas ajudei a construir muitos sites ASP.NET voltados para a Internet, então acho que isso não é desculpa.

Portanto, para meu benefício (e acredito em muitos outros), posso obter alguma opinião das pessoas sobre o seguinte:

• Como “superar” o ASCII de uma vez por todas
• Orientação fundamental ao trabalhar com Unicode.
• Livros e sites recomendados (recentes) em Unicode (para desenvolvedores).
• Estado atual do Unicode (5 anos após o artigo de Joels)
• Direções futuras.

Devo admitir que tenho experiência em .NET e também ficaria feliz em obter informações sobre Unicode na estrutura .NET.É claro que isso não deve impedir ninguém com formação diferente de comentar.

Atualizar:Ver esta questão relacionada também perguntado anteriormente no StackOverflow.

Answer 1

Desde que li o artigo de Joel e alguns outros artigos do I18n, sempre fiquei de olho na minha codificação de caracteres;E realmente funciona se você fizer isso de forma consistente.Se você trabalha em uma empresa onde é padrão usar UTF-8 e todo mundo sabe/faz isso vai funcionar.

Aqui estão alguns artigos interessantes (além do artigo de Joel) sobre o assunto:

• http://www.tbray.org/ongoing/When/200x/2003/04/06/Unicode
• http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

Uma citação do primeiro artigo;Dicas para usar Unicode:

• Abrace o Unicode, não lute contra ele;provavelmente é a coisa certa a fazer e, se não fosse, você provavelmente teria que fazer isso de qualquer maneira.
• Dentro do seu software, armazene o texto como UTF-8 ou UTF-16;isto é, escolha um dos dois e continue com ele.
• Intercambiar dados com o mundo exterior utilizando XML sempre que possível;isso faz com que um monte de problemas potenciais desapareçam.
• Tente tornar seu aplicativo baseado em navegador em vez de escrever seu próprio cliente;os navegadores estão ficando muito bons em lidar com os textos do mundo.
• Se você estiver usando o código da biblioteca de outra pessoa (e é claro que está), presuma que o manuseio do Unicode está quebrado até que seja provado que está correto.
• Se você estiver pesquisando, tente entregar os problemas linguísticos e de manipulação de caracteres a alguém que os entenda.
• Vá até a Amazon ou algum outro lugar e compre a revisão mais recente do padrão Unicode impresso;ele contém muito bem tudo que você precisa saber.
• Passe algum tempo vasculhando o site Unicode e aprendendo como funcionam os gráficos de código.
• Se você tiver que fazer algum trabalho sério com línguas asiáticas, compre o livro O'Reilly sobre o assunto, de Ken Lunde.
• Se você possui um Macintosh, corra e pegue a ferramenta Unicode Font Inspection do Lord Pixel.Totalmente legal.
• Se você realmente precisar se preocupar com os dados, participe de uma das conferências Unicode duas vezes por ano.Todos os especialistas vão e se você não souber o que precisa saber, poderá encontrar alguém que saiba.

Answer 2

Passei um tempo trabalhando com software de mecanismo de pesquisa - você não acreditaria quantos sites oferecem conteúdo com cabeçalhos HTTP ou metatags que mentem sobre a codificação das páginas.Freqüentemente, você receberá um documento que contém caracteres ISO-8859 e caracteres UTF-8.

Depois de enfrentar alguns desses tipos de problemas, você começa a levar muito a sério a codificação de caracteres adequada dos dados que produz.

Answer 3

O .NET Framework usa a codificação padrão do Windows para armazenar strings, que é UTF-16.Se você não especificar uma codificação ao usar a maioria das classes de E/S de texto, você escreverá UTF-8 sem BOM e lerá primeiro verificando se há uma BOM e depois assumindo UTF-8 (tenho certeza StreamReader e StreamWriter comporte-se dessa maneira.) Isso é bastante seguro para editores de texto "burros" que não entendem uma lista técnica, mas um pouco grosseiro para editores mais inteligentes que podem exibir UTF-8 ou a situação em que você está realmente escrevendo caracteres fora do intervalo ASCII padrão .

Normalmente isso é invisível, mas pode aparecer de maneiras interessantes.Ontem eu estava trabalhando com alguém que estava usando serialização XML para serializar um objeto em uma string usando um StringWriter, e ele não conseguia descobrir por que a codificação era sempre UTF-16.Como uma string na memória será UTF-16 e isso é imposto pelo .NET, essa é a única coisa que a estrutura de serialização XML pode fazer.

Então, quando escrevo algo que não é apenas uma ferramenta descartável, especifico uma codificação UTF-8 com uma lista técnica.Tecnicamente, no .NET, você sempre estará acidentalmente ciente do Unicode, mas somente se o usuário souber detectar sua codificação como UTF-8.

Isso me faz chorar um pouco toda vez que vejo alguém perguntar: "Como faço para obter os bytes de uma corda?" e a solução sugerida usa Encoding.ASCII.GetBytes() :(

Answer 4

Regra prática:se você nunca mexer ou olhar dentro de uma string e, em vez disso, tratá-la estritamente como uma bolha de dados, ficará muito melhor.

Mesmo fazer algo tão simples como dividir palavras ou colocar strings em minúsculas torna-se difícil se você quiser fazer isso "do jeito Unicode".

E se você quiser fazer isso "do jeito Unicode", precisará de uma biblioteca muito boa.Essas coisas são incrivelmente complexas.