Hex / ASCII / Unicode

O que é um conversor Hex / ASCII / Unicode?#

O mesmo pedaço de texto pode ser escrito de três formas genuinamente diferentes, e esta ferramenta deixa ver as três ao mesmo tempo:

• Texto — os caracteres literais como os escreveria e leria (Hello 世界 🌍).
• Bytes hex — a sequência de bytes UTF-8 em bruto, em hexadecimal, um byte por par (48 65 6C 6C 6F 20 ...). É o que realmente viaja numa rede ou fica num arquivo.
• Pontos de código — os valores escalares Unicode, um U+XXXX por carácter (U+0048 U+0065 ... U+1F30D). É assim que o próprio Unicode numera caracteres, independentemente de qualquer codificação de bytes.

A razão pela qual estas três vistas importam é que elas não têm o mesmo comprimento assim que se sai do ASCII — e essa é a única fonte de mais confusão sobre codificação de texto do que qualquer outra. Um carácter é um ponto de código, mas pode ocupar de um a quatro bytes em UTF-8. O emoji do globo terrestre 🌍 é um único carácter (U+1F30D), mas em UTF-8 são quatro bytes (F0 9F 8C 8D). Se alguma vez contou mal o comprimento de uma string, viu uma base de dados rejeitar uma string por ser “longa demais”, ou observou uma operação de substring aterrar no meio de um carácter, já encontrou esta lacuna.

Edite qualquer uma das três representações e as outras duas são derivadas instantaneamente. O analisador é tolerante: a entrada hex aceita espaços, dois-pontos, hífens e prefixos 0x; a entrada de pontos de código aceita U+, \u, 0x, ou hex puro, separados por espaços, vírgulas ou pontos e vírgula.

Como usar#

1. Use o seletor de modo por cima da caixa de entrada para declarar o que está escrevendo: Texto, Hex ou Pontos de código.
2. Cole ou edite na caixa de entrada. As outras duas vistas preenchem-se automaticamente à direita.
3. Use Copiar ao lado de qualquer um dos três campos de resultado para recolher essa representação.
4. Exemplo carrega Hello 世界 🌍 para que veja como ASCII, CJK e um emoji mapeiam de forma diferente cada um. Limpar esvazia tudo.

Principais funcionalidades#

• Três vistas, uma fonte de verdade. Edite a representação que tiver; as outras são calculadas, nunca mantidas à mão.
• Bytes UTF-8, não Latin-1. A saída hex é a verdadeira sequência de bytes UTF-8 on-the-wire, que é o que quase todos os sistemas modernos usam — não o pressuposto legado de um byte por carácter.
• Conhecedor de pontos de código, incluindo caracteres astrais. A iteração for...of significa que um emoji conta como um único ponto de código, não duas metades de substituto, pelo que U+1F30D é o que vê — nunca D83C DF0D.
• Rigoroso no caminho de volta. Bytes hex que não formam UTF-8 válido (uma string de comprimento ímpar, ou um byte de continuação órfão) são reportados com um erro claro em vez de decodificados para texto corrompido. Pontos de código fora do intervalo válido, e substitutos solitários (U+D800–U+DFFF), são rejeitados.

Exemplo prático#

Carregue em Exemplo para obter Hello 世界 🌍, e as três vistas derivadas são:

Text:       Hello 世界 🌍
Hex bytes:  48 65 6C 6C 6F 20 E4 B8 96 E7 95 8C 20 F0 9F 8C 8D
Code points: U+0048 U+0065 U+006C U+006C U+006F U+0020 U+4E16 U+754C U+0020 U+1F30D

As letras ASCII H e l l o são a parte aborrecida: um byte cada, pontos de código U+0048 até U+006F. A parte interessante é o resto:

• 世 (U+4E16) são três bytes UTF-8: E4 B8 96. 界 (U+754C) são também três bytes: E7 95 8C. Um carácter, mas não um byte.
• 🌍 (U+1F30D) são quatro bytes UTF-8: F0 9F 8C 8D. O ponto de código está acima de U+FFFF, pelo que vive no plano astral do Unicode e precisa de uma sequência UTF-8 de 4 bytes — mas continua a ser um único carácter, uma entrada na lista de pontos de código.

Faça a experiência ao contrário: mude o modo para Pontos de código, cole U+1F600 U+1F604, e veja tanto o texto (emojis da família 😄 😄) como o hex UTF-8 aparecer. Essa viagem completa é exatamente como se confirma que bytes correspondem a que carácter.

FAQ#

Porque é que o meu emoji ocupa quatro bytes hex mas só um ponto de código?#

Porque UTF-8 é uma codificação de largura variável. Pontos de código abaixo de U+0080 cabem num byte; U+0080–U+07FF ocupam dois; U+0800–U+FFFF ocupam três; e qualquer coisa em ou acima de U+10000 (a maioria dos emojis, scripts históricos, símbolos musicais) ocupa quatro. O ponto de código é o nome do carácter no Unicode; os bytes são como o UTF-8 armazena esse carácter. Mesmo carácter, dois números diferentes.

Qual é a diferença entre U+XXXX e \uXXXX?#

Referem-se ao mesmo ponto de código mas vêm de mundos diferentes. U+0041 é a notação própria do Unicode. A é o escape usado em literais de string de JavaScript, Java e C. O senão: \uXXXX só contém quatro dígitos hexadecimais, pelo que não consegue exprimir diretamente um ponto de código astral como U+1F30D — as linguagens que usam \u precisam ou de um par de substitutos (🌍) ou de uma sintaxe estendida como \u{1F30D}. A entrada de pontos de código desta ferramenta aceita qualquer das formas.

Colei bytes hex e obtive um erro “UTF-8 inválido”. O que isso significa?#

Os bytes que colou não formam uma sequência UTF-8 legal — mais frequentemente porque a string hex tem comprimento ímpar (falta meio byte), um byte inicial reclama uma sequência multibyte que os bytes seguintes não completam, ou os dados foram afinal codificados noutra coisa que não UTF-8 (GBK, Shift-JIS, Latin-1 em bruto). O decodificador usa modo estrito para que o problema seja reportado em vez de produzir silenciosamente caracteres de substituição.

Posso usar isto para contar caracteres “reais” numa string?#

Sim — a contagem de pontos de código é a contagem que um usuário consideraria, e é o que a maioria das interfaces deveria limitar. Repare que Hello 世界 🌍 tem 10 caracteres por pontos de código, apesar de serem 17 bytes em UTF-8 e 11 unidades de código UTF-16 em JavaScript (string.length). Se precisa de um orçamento de caracteres para um tweet ou campo de formulário, conte pontos de código, não bytes nem string.length.