Formação Oracle DBA Completa


Quando usar ANSI e quando usar UTF-8

27 de novembro de 2017 1 Por Ramos de Souza Janones
Powered by Rock Convert

Estritamente falando quando você usa UTF-8 você usa o set de caracteres ANSI. Mas eu acho que você está usando o termo ANSI erroneamente. Não é culpa sua, há muitos anos o termo está sendo usado de forma errada. Provavelmente você está querendo comparar UTF-8 e ISO-8859-1/Latin 1 (que costuma ser confundido com CP1252/Windows-1252 que é outro encoding/charsetque serve o mesmo propósito e que tem características essencialmente idênticas).

O primeiro critério para escolher um ou outro é verificar com quem você vai trocar estes dados. Não adianta nada pensar em qual é melhor quando ele é incompatível com a atividade que ele será usado. Determine o requisito da compatibilidade com que será intercambiado e não se preocupe com mais nada. Se você não tem problemas de compatibilidade com nada, use o mais simples.

Se você tem total controle de como será feito o intercâmbio ou tem liberdade de escolha, para evitar conversões procure escolher a forma que as tecnologias usadas por você preferem. Se ainda isso é escolha sua aí vamos analisar outros pontos.

É mais vantajoso utilizar um tipo ANSI ao invés de um tipo UTF-8 ou vice-versa?

Vou começar discordando da resposta do Bruno quando diz que o “ANSI” está praticamente obsoleto. Ainda há muitos casos que ele não só pode ser usado, como é obrigatório. É claro que há uma onda de preferência pelo UTF-8. Isto é inegável. Mas ambos são ferramentas úteis e serão utilizados por muito tempo.

Não há dúvidas que o UTF-8 é mais moderno, mais flexível, mais completo, mais confiável na maioria dos casos e mais popular, mas fica a questão se tudo isto é necessário. A maior vantagem do “ANSI” é a sua simplicidade para a maioria dos casos.

O “ANSI” ainda tem as vantagens de performance e armazenamento discutidas abaixo.

maior vantagem do UTF-8 é a universalidade (que é relativa, não quer dizer que realmente serve para tudo, serve para todos os caracteres) e isto tem um significado ainda maior conforme ele vai ficando mais popular. Essa universalidade se dá pelo fato de permitir vários bytes para representar 1 caractere, ao mesmo que tempo que isto acaba sendo a sua principal desvantagem, o causador da maioria das dificuldades do encoding. Com mais bytes pode-se representar uma quantidade muito grande caracteres sem recorrer a artifícios. E a flexibilidade permite que o espaço ocupado não seja tão grande apesar de acabar consumindo mais processamento para processar a maioria dos algoritmos.

Mas além de ter uma implementação pesada, muitas vezes com defeitos de tão complexo que é, por definição existe a possibilidade de ambiguidades de formas para representar o mesmo caractere que causa problemas em comparações (o que você vê não é o que está representado na string) e uma string pode se tornar inválida em casos de perda de parte da informação com truncamento. Não vou nem dizer que usar UTF-8 é extremamente complexo e pouquíssimos programadores sabem usá-lo corretamente. Tudo bem que não precisa entender tudo para o caso que garantidamente usará apenas o simples, mas aí o UTF-8 não é tão vantajoso assim. Curiosamente os povos que mais se beneficiaram com ele são os que mais reclamam dele.

Um dos problemas citados é a confusão em comprimento em bytes da string e o comprimento em caracteres (ou code points como são realmente chamados). A maioria dos programadores não sabe bem o que a função/método Length de uma string retorna. De fato isso pode variar de acordo com a tecnologia usada.

Há outros problemas citados em Por que ainda se usam outras codificações além do UTF-8?.

É possível abstrair o tratamento de codepages do “ANSI” se for necessário. Na imensa maioria das vezes elas não são necessárias, mas se for dá para criar uma estrutura de dados que encapsule e abstraia esse tratamento de forma transparente para o usuário da string. Claro que não é perfeito, não resolve todos os problemas mas resolve um dos problemas citados. Mas o UTF-8 também não resolve todos os problemas. Por que ninguém fez isto (pelo menos nada público e bem conhecido)? Porque não é uma necessidade real na maioria dos casos.

Curso completo de Games, inclusive Realidade Aumentada.Powered by Rock Convert

Frontend Do Zero Ao Profissional

LEIA TAMBÉM:  W3C anuncia o DRM como uma recomendação

Por fim, de qual verão do UTF-8 estamos falando? É, ele tem versões. Tem retrocompatibilidade entre elas, mas se você tentar pegar algo gerado com uma versão mais nova usando um recurso novo e manipular com uma implementação antiga, terá dificuldades.

Existe algum ganho em performance ou armazenamento entre os tipos?

Certamente o “ANSI” é mais rápido e ocupa menos espaço que o UTF-8. Em casos específicos onde somente caracteres da tabela ASCII (até 127) sejam usados o UTF-8 pode ocupar o mesmo espaço.

Há a garantia que o “ANSI” ocupa 1 byte, o UTF-8 não. Fica claro que o UTF-8 não só a ocupação de espaço é maior mas o tempo para processar também. Quando você pode garantir o tamanho em bytes dos caracteres dá para ser mais eficiente. É possível ter algoritmos mais ou menos eficientes com UTF-8 mas a necessidade de tratar tamanhos diferentes gera um custo adicional. Não existe milagre. Podemos dizer, a grosso modo, que “ANSI” é um array e UTF-8 é uma lista ligada. Não há como chegar em um caractere em UTF-8 sem passar por outros caracteres. Mesmo o caractere individual exige uma verificação para saber se há um complemento para ele, possivelmente através de um branch no processador, que é bem caro.

É indiscutível qual ganha em performance. Dá para discutir se ela é importante. A diferença não costuma ser tão grande e outros fatores podem tornar a diferença ainda mais irrisória. Mas também há problemas que requerem a performance extrema.

O espaço ocupado é maior com UTF-8 mas a diferença não costuma ser tão grande (e se for, provavelmente você não tem muita escolha, o que é altamente improvável no mundo ocidental). Mas se existir alguma razão real que o tamanho seja importante, opte pelo “ANSI”.

Basicamente a diferença acontecerá nos caracteres acentuados. No “ANSI” o caractere sempre ocupará 1 byte e no UTF-8 ocupará 2 bytes. Não vou comparar nada além dos acentos porque o “ANSI” não vai conseguir manipular. Estamos falando de situações onde você tem escolha. Para conhecer a tabela de acentos permitidos, veja na Wikipedia. Note que os caracteres sem acento, ou seja, constantes da tabela ASCII, o UTF-8 ocupará apenas 1 byte. A maioria dos caracteres usados não possuem acento.

O que talvez possa complicar na decisão é o tamanho variável. Existem formatos de arquivos que exigem um tamanho fixo dos campos/linhas. Mas neste caso provavelmente também há o requisito para o encoding e/ou charset.

Conclusão

Lembre-se que o assunto é extremamente complexo, para falar tudo que seria necessário daria um livro.

Particularmente eu procuro usar o ISO-8859-1 em tudo o que eu faço onde tenho liberdade total. Ele é mais simples, mais fácil, mais eficiente e resolve todos os problemas que eu tenho nos softwares que eu faço. Infelizmente por um motivo ou outro acabo sendo forçado a usar o UTF-8 ou mesmo UTF-16 (este não para arquivos a não ser que realmente seja necessário) em algumas situações. Nenhum grande problema, já foi demonstrado que há vantagens nele também.

Artigos relacionado a Javascript

Artigos e dicas sobre Javascript e toda sua familia: Node.js, Angular, Ionic, React e muito mais.

– GitHub lança repositórios privados gratuitos para até três colaboradores

– Como fazer testes unitários no Node.js com NodeUnit

– Epoc.js: Projeto open source em JavaScript para Sensores de Controle Cerebral

– Migre para o Ionic Framework 4 mais fácil usando o TSLint Fixers

– Apollo lança a Plataforma GraphQL e extensão para VS Code

– As novidades do Angular 7

– Tecnologias que andam bombando no GitHub ultimamente

– Node.JS: Envie o gemidão do Whastzap para seus amigos via chamada telefônica

– Southbank Software apresenta dbKoda: uma ferramenta de desenvolvimento Open Source para MongoDB

– Começando com React Native

– React Native Do Zero Ao Profissional, Curso Sobre Criação De Apps React Native Para Android e IOS

– React: Tutoriais Fantásticos e Onde Habitam

– React – O que é Shadow DOM

– O que são middlewares em NodeJS?

– Conhecendo os super poderes dos comandos Git e GitHub

Web

Artigos e dicas sobre desenvolvimento web que você vai gostar:

– 6 TENDÊNCIAS DE UX DESIGN PARA OS PRÓXIMOS ANOS

– UX – User Experience ou Experiência do Usuário – Princípios

– Usabilidade: Tela com muitas informações ou distribuídas em várias telas?

– Entenda as diferenças entre Wireframe, Protótipo e Mockup?

Estatísticas de SEO, novas regras do Google para 2019 e Automação de Marketing Digital

– Bootstrap – O que são grids CSS

– Quando usar ANSI e quando usar UTF-8

– W3C anuncia o DRM como uma recomendação

– Crie um loading animado divertido usando CSS3

– Como descobrir se uma cor hexadecimal é escura ou clara

– Como usar tags semânticas

– O que é o GZIP e como melhora a velocidade de um site

– Como adicionar notificações (Push notification) em seu site

Siga os bons!

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Últimos posts por Ramos de Souza Janones (exibir todos)




Frontend Do Zero Ao Profissional