Converter texto ou referências dentro de uma string

Cole o conteúdo no campo. A conversão ocorre no navegador sem enviar a entrada em requisições de rede. Não há entrada de arquivos nem processamento em lote.

  1. Insira o texto original ou o conteúdo com referências e acione a codificação ou a decodificação.
  2. Confira e copie o resultado em texto. Editar a entrada ou encontrar um erro de conversão apaga a saída anterior e desativa a cópia.
  3. Para outra operação, cole o resultado na entrada manualmente. Limpar esvazia os dois campos.

Referências geradas e formas reconhecidas

Um ponto de código, uma referência decimal

A entrada A你😀 produz A你😀. O emoji é representado pelo ponto de código completo, sem gerar duas referências de substitutos UTF-16. Letras e espaços também são codificados: é vira é, espaço   e LF 
. A saída não usa referências nomeadas.

Três formatos podem aparecer no mesmo texto

A decodificação reconhece decimal como A, hexadecimal como A ou A e \u com u minúsculo seguido de quatro dígitos hexadecimais, como \u0041. O ponto e vírgula é obrigatório nas referências numéricas. Os dígitos hexadecimais aceitam maiúsculas e minúsculas; o texto ao redor é mantido.

😀, 😀 e o par \uD83D\uDE00 resultam em 😀. Isso não interpreta uma string JS/JSON completa nem executa HTML.

Onde se aplicam as regras HTML estritas

he 1.2.0 aplica verificações HTML estritas à codificação e à decodificação de referências numéricas. Rejeita referências como �, €, � e �. A codificação rejeita NUL, controles C1 como U+0080, U+FFFF e substitutos sem par.

Essas verificações HTML não se aplicam ao ramo \uXXXX: \u0000 e \uFFFF são decodificados para suas unidades de código. A verificação final da saída rejeita apenas substitutos sem par.

O formato antigo �� é rejeitado, não combinado. Use 😀 para esse emoji.

Dúvidas sobre referências numéricas

Por que uma sequência aparentemente inválida continua na saída?

Só os três formatos reconhecidos são convertidos. \uZZZZ, \u{41}, \U0041, &#xZZ; e &#65 sem ponto e vírgula ficam como texto. O mesmo vale para &, números soltos como 65 66 e \n. Não é um validador de toda sintaxe possível nem um decodificador de bytes UTF-8.

A decodificação repete o processo até chegar ao caractere?

Não. Tanto A quanto \u0026#65; geram o texto literal A, não A. O texto produzido por uma substituição não é examinado novamente.

Espaços ou linhas vazias são removidos?

Não há remoção de espaços nem normalização Unicode; entrada vazia gera saída vazia. O textarea normaliza quebras reais CRLF/CR para LF. O núcleo pode codificar CR como 
, mas a decodificação numérica estrita rejeita essa referência. Nem toda entrada permite conversão de ida e volta.

Ferramentas recentes: