Guia de codificação de caracteres

Os computadores só podem entender representações binárias como1e0. O processamento de qualquer outra coisa requer algum tipo de mapeamento do texto do mundo real para sua representação binária. This mapping is what we know as character encoding or simply just as encoding.

Por exemplo, a primeira letra da nossa mensagem, “T”, em US-ASCIIencodes to “01010100”.

O mapeamento de caracteres para suas representações binárias pode variar bastante em termos dos caracteres que eles incluem. O número de caracteres incluídos em um mapeamento pode variar de apenas alguns para todos os caracteres em uso prático. The set of characters that are included in a mapping definition is formally called a charset.

Por exemplo,ASCII has a charset of 128 characters.

Um ponto de código é uma abstração que separa um caractere de sua codificação real. A code point is an integer reference to a particular character.

Podemos representar o próprio inteiro em bases decimais simples ou bases alternativas como hexadecimal ou octal. Usamos bases alternativas para facilitar a referência de grandes números.

Por exemplo, a primeira letra da nossa mensagem, T, em Unicode, possui um ponto de código "U + 0054" (ou 84 em decimal).

Um dos primeiros esquemas de codificação, chamado ASCII (Código Padrão Americano para Troca de Informações), usa um esquema de codificação de byte único. Isso significa essencialmente queeach character in ASCII is represented with seven-bit binary numbers. Isso ainda deixa um bit livre em cada byte!

O conjunto de 128 caracteres ASCII abrange alfabetos ingleses em maiúsculas e minúsculas, dígitos e alguns caracteres especiais e de controle.

Vamos definir um método simples em Java para exibir a representação binária de um caractere em um esquema de codificação específico:

Agora, o caractere ‘T 'possui um ponto de código 84 em US-ASCII (ASCII é referido como US-ASCII em Java).

E se usarmos nosso método utilitário, podemos ver sua representação binária:

Como esperado, é uma representação binária de sete bits para o caractere 'T'.

The original ASCII left the most significant bit of every byte unused. Ao mesmo tempo, o ASCII deixou muitos caracteres não representados, especialmente para idiomas diferentes do inglês.

Isso levou a um esforço para utilizar esse bit não utilizado e incluir 128 caracteres adicionais.

There were several variations of the ASCII encoding scheme proposed and adopted over the time. Eles foram vagamente chamados de “extensões ASCII”.

Muitas das extensões ASCII tiveram diferentes níveis de sucesso, mas, obviamente, isso não foi bom o suficiente para uma adoção mais ampla, pois muitos caracteres ainda não estavam representados.

One of the more popular ASCII extensions was ISO-8859-1, também conhecido como “ISO Latin 1”.

À medida que a necessidade de acomodar mais e mais caracteres, os esquemas de codificação de byte único, como o ASCII, não eram sustentáveis.

Isso deu origem a esquemas de codificação de vários bytes, que têm uma capacidade muito melhor, embora com o custo de requisitos de espaço maiores.

BIG5 e SHIFT-JIS são exemplos demulti-byte character encoding schemes which started to use one as well as two bytes to represent wider charsets. A maioria deles foi criada para a necessidade de representar scripts chineses e similares, com um número significativamente maior de caracteres.

Vamos agora chamar o métodoconvertToBinary cominput como ‘語 ', um caractere chinês, eencoding como“ Big5 ”:

A saída acima mostra que a codificação Big5 usa dois bytes para representar o caractere ‘語 '.

Umcomprehensive list das codificações de caracteres, junto com seus aliases, é mantido pela Autoridade Internacional de Números.

UTF-32 éan encoding scheme for Unicode that employs four bytes to represent every code point definido por Unicode. Obviamente, é ineficiente em espaço usar quatro bytes para cada caractere.

Vamos ver como um caractere simples como 'T' é representado em UTF-32. Usaremos o métodoconvertToBinary introduzido anteriormente:

A saída acima mostra o uso de quatro bytes para representar o caractere ‘T ', onde os três primeiros bytes são apenas espaço desperdiçado.

UTF-8 éanother encoding scheme for Unicode which employs a variable length of bytes to encode. Embora ele use um único byte para codificar caracteres em geral, ele pode usar um número maior de bytes, se necessário, economizando espaço.

Vamos chamar novamente o métodoconvertToBinary com entrada como 'T' e codificação como “UTF-8”:

A saída é exatamente semelhante ao ASCII usando apenas um byte. De fato, o UTF-8 é completamente compatível com o ASCII.

Vamos chamar novamente o métodoconvertToBinary com entrada como '語' e codificação como “UTF-8”:

Como podemos ver aqui, o UTF-8 usa três bytes para representar o caractere ‘語 '. This is known as variable-width encoding.

UTF-8, devido à sua eficiência de espaço, é a codificação mais comum usada na web.

A plataforma Java depende muito de uma propriedade chamadathe default charset. The Java Virtual Machine (JVM) determines the default charset during start-up.

Isso depende do código do idioma e do conjunto de caracteres do sistema operacional subjacente no qual a JVM está sendo executada. Por exemplo, no MacOS, o conjunto de caracteres padrão é UTF-8.

Vamos ver como podemos determinar o conjunto de caracteres padrão:

Se executarmos esse trecho de código em uma máquina Windows, obteremos a saída:

Agora, “windows-1252” é o conjunto de caracteres padrão da plataforma Windows em inglês, que neste caso determinou o conjunto de caracteres padrão da JVM em execução no Windows.

Muitas das APIs Java usam o conjunto de caracteres padrão, conforme determinado pela JVM. Para nomear alguns:

Então, isso significa que se executássemos nosso exemplo sem especificar o conjunto de caracteres:

então usaria o conjunto de caracteres padrão para decodificá-lo.

E há várias APIs que fazem essa mesma escolha por padrão.

O conjunto de caracteres padrão, portanto, assume uma importância que não podemos ignorar com segurança.

Como vimos, o conjunto de caracteres padrão em Java é determinado dinamicamente quando a JVM é iniciada. Isso torna a plataforma menos confiável ou propensa a erros quando usada em diferentes sistemas operacionais.

Por exemplo, se executarmos

no macOS, ele usará UTF-8.

Se tentarmos o mesmo snippet no Windows, ele usará o Windows-1252 para decodificar o mesmo texto.

Ou imagine gravar um arquivo no macOS e depois ler o mesmo arquivo no Windows.

Não é difícil entender que, devido aos diferentes esquemas de codificação, isso pode levar à perda ou corrupção de dados.

A determinação do conjunto de caracteres padrão em Java leva a duas propriedades do sistema:

Agora, é intuitivo substituir essas propriedades do sistema por meio de argumentos de linha de comando:

No entanto, é importante observar que essas propriedades são somente leitura em Java. Their usage as above is not present in the documentation. A substituição dessas propriedades do sistema pode não ter um comportamento desejado ou previsível.

Portanto,we should avoid overriding the default charset in Java.

Há umJava Enhancement Proposal (JEP) which prescribes using “UTF-8” as the default charset in Java em vez de basear-se no conjunto de caracteres do local e do sistema operacional.

Esse JEP está em um estado preliminar a partir de agora e, quando (espero!) For aprovado, resolverá a maioria dos problemas que discutimos anteriormente.

Observe que as APIs mais recentes, como aquelas emjava.nio.file.Files, não usam o conjunto de caracteres padrão. Os métodos nessas APIs leem ou gravam fluxos de caracteres com charset como UTF-8 em vez do charset padrão.

Devemos normalmentechoose to specify a charset when dealing with text instead of relying on the default settings. Podemos declarar explicitamente a codificação que queremos usar nas classes que lidam com conversões de caracteres em bytes.

Felizmente, nosso exemplo já está especificando o conjunto de caracteres. We just need to select the right one and let Java do the rest.

Devemos perceber até agora que caracteres acentuados como ‘ç 'não estão presentes no esquema de codificação ASCII e, portanto, precisamos de uma codificação que os inclua. Talvez, UTF-8?

Vamos tentar, agora vamos executar o métododecodeText com a mesma entrada, mas codificando como “UTF-8”:

Bingo! Podemos ver a saída que esperávamos ver agora.

Aqui, definimos a codificação que consideramos mais adequada às nossas necessidades no construtor deInputStreamReader. Normalmente, esse é o método mais seguro de lidar com caracteres e conversões de bytes em Java.

Da mesma forma,OutputStreamWritere muitas outras APIs oferecem suporte à configuração de um esquema de codificação por meio de seu construtor.

Quando decodificamos uma sequência de bytes, existem casos em que não é legal para oCharset fornecido, ou então não é um Unicode legal de dezesseis bits. Em outras palavras, a sequência de bytes fornecida não possui mapeamento nosCharset especificados.

Existem três estratégias predefinidas (ouCodingErrorAction) quando a sequência de entrada tem entrada malformada:

OmalformedInputAction padrão paraCharsetDecoder is REPORT,e omalformedInputAction padrão do decodificador padrão emInputStreamReader éREPLACE.

Vamos definir uma função de decodificação que recebe umCharset especificado, um tipoCodingErrorAction e uma string a ser decodificada:

Portanto, se decodificarmos “O padrão de fachada é um padrão de design de software”. comUS_ASCII, a saída para cada estratégia seria diferente. Primeiro, usamosCodingErrorAction.IGNORE que ignora caracteres ilegais:

Para o segundo teste, usamosCodingErrorAction.REPLACE que coloca � em vez dos caracteres ilegais:

Para o terceiro teste, usamosCodingErrorAction.REPORT que leva a arremessarMalformedInputException:

Na maioria dos casos, um editor de texto é onde os textos se originam. Existem numerosos editores de texto na escolha popular, incluindo vi, Bloco de Notas e MS Word. A maioria desses editores de texto nos permite selecionar o esquema de codificação. Portanto, devemos sempre garantir que eles sejam apropriados para o texto que estamos manipulando.

Depois de criar textos em um editor, precisamos armazená-los em algum sistema de arquivos. O sistema de arquivos depende do sistema operacional no qual está sendo executado. A maioria dos sistemas operacionais possui suporte inerente a vários esquemas de codificação. No entanto, ainda pode haver casos em que uma conversão de codificação leva à perda de dados.

Os textos quando transferidos através de uma rede usando um protocolo como FTP (File Transfer Protocol) também envolvem a conversão entre codificações de caracteres. Para qualquer coisa codificada em Unicode, é mais seguro transferir como binário para minimizar o risco de perda na conversão. No entanto, a transferência de texto em uma rede é uma das causas menos frequentes de corrupção de dados.

A maioria dos bancos de dados populares, como Oracle e MySQL, suporta a escolha do esquema de codificação de caracteres na instalação ou criação de bancos de dados. Devemos escolher isso de acordo com os textos que esperamos armazenar no banco de dados. Este é um dos locais mais frequentes em que a corrupção de dados de texto ocorre devido à conversão de codificações.

Finalmente, na maioria dos aplicativos da web, criamos textos e os passamos por diferentes camadas com a intenção de visualizá-los em uma interface do usuário, como um navegador. Aqui também é imperativo escolhermos a codificação correta de caracteres que pode exibir os caracteres corretamente. Navegadores mais populares como o Chrome, Edge permitem escolher a codificação de caracteres através de suas configurações.