domingo, 16 de outubro de 2016

O que você sabia sobre tamanhos de strings talvez não está tão certo assim.

Bem-vindos ao blog Preciso Estudar Sempre. Meu nome é João Paulo Maida e minha paixão é estudar.

Inicio este post com uma pergunta. Para a string abaixo, qual seria seu tamanho ?

 joão  

Embora pareça simples, não a subestime, pois se você pensou que a resposta seria 4, talvez esteja errado. Sim, você não leu errado, esta string de fato pode não possuir tamanho 4 embora possua quatro caracteres.

Porque isso acontece ?

Antes de responder a essa pergunta, explicarei qual foi a minha motivação para escrever esse post. Uma vez trabalhei em um sistema web feito em Java que possuía um formulário HTML e em um dos campos a validação de tamanho estava acusando que estávamos enviando uma string maior que permitido. Estudando o problema, descobrimos que isso acontecia porque uma das letras possuía um acento. Agora que já contextualizamos toda situação, devemos voltar para a busca de uma resposta para a nossa pergunta.

Quando desejamos descobrir o tamanho de uma string em Java utilizamos o método length(). Se dermos uma olhada na documentação dele veremos o seguinte:
Returns the length of this string. The length is equal to the number of Unicode code units in the string.
OBSERVAÇÃO: A linguagem Java está sendo usado neste post como uma forma dar corpo ao estudo do nosso problema e consequentemente da solução dele. Tal situação também pode estar ser encontrada em outras linguagens.

Então, o método length() não trabalha da forma que pensamos. Ele não conta caracteres, e sim Unicode code units. Como o próprio nome já diz, eles são unidades de códigos Unicode e quem dita o tamanho de cada unidade dessa é o tipo de encoding usado.

Um encoding é uma forma de representação de uma caractere. Cada tipo possui definições diferentes, onde nestas constam os caracteres que são aceitos e suas respectivas posições na tabela ASCII. No nosso problema o que acontecia era que o encoding type utilizado no envio do texto do browser para o servidor não aceitava caracteres com acentos.

Um dos encoding type mais conhecidos e utilizados é o UTF-8, onde ele define que um Unicode code point que vai de 0 à 127 na tabela ASCII é armazenado em uma code unit de 8 bits, e os que estão acima disso podem ser armazenados em 2, 3 ou até 6 bytes. Sua fama se deve ao fato de ele aceitar caracteres com acentos.

Note que agora introduzimos um novo elemento no nosso estudo, o code point. Na terminologia de encoding um code point é qualquer valor numérico que compõe o espaço de um código. O esquema de encoding de caracteres ASCII compreende 128 code points, o Extended ASCII define 256 code points e o Unicode compreende 1114112 code points. Neste último, um code point é representado visualmente pelo símbolo U+ seguido de uma representação hexadecimal do caractere.

A solução para problemas como este é sempre definir o encoding type do seu IO, seja ela uma página HTML, um arquivo, ou algum outro tipo de stream. Um exemplo claro da falta de definição de encoding type é quando você recebe aquele spam chinês ou indiano e quando vai abrir aparecem várias caixinhas ou pontos de interrogação. Um teste que pode ser feito em casa é criar uma página HTML qualquer, não definir o enconding da página e por um texto com acentos. Quando você for abrir essa página em seu browser notará que no lugar dos caracteres com acentos, aparecerão caracteres estranhos. Isto acontece devido ao fato do browser não saber como ele deve processar aquele texto, então ele processa da forma que ele bem achar correto.

Se você quiser entender mais da história do Unicode, recomendo fortemente a leitura do post "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)". Vale a pena a leitura.

Talvez você tenha notado que nos primeiros parágrafos eu disse que a string em questão podia não ter tamanho 4. Em algumas ocasiões ela pode apresentar tamanho 5. Isso se tornou uma grande curiosidade que me estimulou para obter mais respostas para a construção deste post. Faça o seguinte teste:

Crie uma classe Java com o mesmo conteúdo abaixo, compile e rode este programa pelo cmd do windows.

 class StringLength {  
      public static void main(String[] args) {            
           String s = "joão";  
           System.out.println("Nossa string:" + s);  
           System.out.println("O tamanho(length) da nossa string: " + s.length());  
      }       
 }  

Para compilar e rodar o programa pelo cmd utilize os seguintes comandos:

 javac StringLength.java                        //para compilar  
 java StringLength                             //para executar  

Acredito que o resultado será algo desse tipo.

Figura 1 - Resultado do primeiro teste
Quando me deparei com este resultado fiquei me perguntando duas coisas: porque a string apareceu com os caracteres quebrados e porque o length é 5 ?? Através de muita pesquisa consegui a resposta para a primeira pergunta. O code page default da console do windows é o Multilingual (encoding Latin I) e possui o código 850, então caímos no mesmo problema que estudamos acima. Este code page não consegue processar caracteres com acentos. Então devemos mudar para o code page 65001 (UTF-8), através do comando chcp 65001.
Figura 2 - Resultado do segundo teste
Agora para piorar mais ainda nossa situação, crie uma classe Java com o código acima em um projeto do Eclipse IDE. Se o seu resultado foi o mesmo que o meu você também deve estar com a mesma dúvida.
Figura 3 - Resultado do terceiro teste
PORQUE OS LENGTHS DAS STRING SÃO DIFERENTES SE O CÓDIGO JAVA É O MESMO ?

Bem, eu ainda não tenho a resposta para esta pergunta, por isso conto com vocês. Se puderem me ajudar, deixe nos comentários a resposta para este problema. A minha opinião é que a IDE leva em conta o encoding type padrão do Java (UTF-16) na exibição em seu console interno e o console do windows não leva, mas isso é a minha opinião. Quero ouvir a de vocês.

Link do GitHub: https://github.com/PrecisoEstudarSempre/StringLength.git

Dúvidas !? Sugestões ?! Críticas ou elogios ?!

Deixe aí nos comentários, me mande um e-mail ou, na nossa página do facebook.

E-mail: precisoestudarsempre@gmail.com
Facebook: https://www.facebook.com/precisoestudarsempre/

Referências:

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) - http://www.joelonsoftware.com/articles/Unicode.html

What is a Unicode code unit and a Unicode code point - https://coderanch.com/t/416952/java/java/Unicode-code-unit-Unicode-code

Documentação da classe String - https://docs.oracle.com/javase/7/docs/api/java/lang/String.html

Documentação oficial Unicode - http://www.unicode.org/versions/Unicode9.0.0/ch03.pdf#G7404

Unicode and .NET - http://csharpindepth.com/Articles/General/Unicode.aspx

encodings - different result between codePointCount and length - http://stackoverflow.com/questions/20162239/encodings-different-result-between-codepointcount-and-length

Comando Chcp - https://technet.microsoft.com/pt-br/library/bb490874.aspx

What encoding/code page is cmd.exe using - http://stackoverflow.com/questions/1259084/what-encoding-code-page-is-cmd-exe-using

What is the character encoding of String in Java? - http://stackoverflow.com/questions/4453269/what-is-the-character-encoding-of-string-in-java

Code Page Identifiers - https://msdn.microsoft.com/pt-br/library/windows/desktop/dd317756(v=vs.85).aspx

2 comentários:

Anônimo disse...

O método length() retorna o número de objetos Char da String e não o número de caracteres Unicode (um caractere Unicode pode ser representado por mais de um Char). Use a classe System.Globalization.StringInfo para trabalhar com cada caractere Unicode em vez de cada Char.

Preciso Estudar Sempre disse...

Obrigado pela contribuição e comentário meu amigo, mas poderia linkar a documentação dessa classe por favor ? Não estou encontrando.