Escape / Unescape de JSON

Como funciona

1. Cole sua string : insira o texto para escapar, pode ser texto simples contendo aspas, quebras de linha, barras invertidas ou qualquer outro caractere especial.
2. Escolha escapar ou reverter escape : selecione se você quer escapar texto para incorporar em JSON, ou reverter o escape de uma string JSON em texto legível.
3. Copie o resultado : a saída escapada ou com escape revertido aparece instantaneamente. Copie-a para usar no seu código ou nos seus dados.

Por que usar o escape JSON ?

As strings JSON têm regras de escape estritas, aspas duplas devem virar \", quebras de linha \n, barras invertidas \\ e tabulações \t. Não escapar corretamente esses caracteres provoca erros de análise JSON que quebram APIs, arquivos de configuração e pipelines de dados. Esta ferramenta cuida automaticamente de todo o escape e reversão de escape, eliminando o localizar-substituir manual e evitando bugs sutis causados por sequências de escape perdidas.

Funcionalidades

• Cobertura de escape completa : trata aspas, barras invertidas, quebras de linha, tabulações, retornos de carro e sequências de escape Unicode.
• Bidirecional : ao mesmo tempo escapar (texto → string JSON) e reverter escape (string JSON → texto) em uma única ferramenta.
• Resultados instantâneos : a saída é atualizada à medida que você digita, sem atraso.
• Copiar para a área de transferência : cópia em um clique do resultado escapado ou com escape revertido.
• Privacidade em primeiro lugar : todo o processamento é feito localmente, strings sensíveis nunca saem do seu dispositivo.

Perguntas frequentes

Quais caracteres o escape JSON trata ?

JSON exige o escape de : aspas duplas ("), barra invertida (\), barra normal (/), quebra de linha (\n), retorno de carro (\r), tabulação (\t), quebra de página (\f), retrocesso (\b) e caracteres Unicode acima de U+FFFF. Esta ferramenta trata todos eles.

Por que meu erro de análise JSON é devido ao escape ?

As causas comuns incluem aspas duplas não escapadas dentro de um valor de string, quebras de linha literais em uma string (devem ser \n) e barras invertidas não escapadas. Cole sua string quebrada aqui para escapá-la corretamente.

Isso inclui as aspas envolventes ?

Por padrão, a ferramenta escapa o conteúdo sem envolver em aspas, para que você possa colar o resultado dentro da sua string JSON. Ative a opção « Incluir as aspas » se quiser que a saída seja envolta em aspas duplas.

A especificação JSON String, em uma tabela

RFC 8259 (dezembro de 2017, por Tim Bray) é o padrão JSON atual, substituindo RFC 7159 e o original RFC 4627. A seção 7 da spec lista exatamente quais caracteres DEVEM ser escapados dentro de um literal de string:

Regras equivalentes estão em ECMA-404 (2ª edição, dezembro de 2017), mantido em sincronia com a spec IETF. JSON não tem escapes octais (\012) ou hexadecimais (\x41), esses são apenas JavaScript; JSON só suporta os oito escapes nomeados acima mais \uXXXX.

O escape \uXXXX e a armadilha do par substituto

As sequências \uXXXX de JSON codificam unidades de código UTF-16, não pontos de código Unicode. Isso importa para emoji e caracteres do plano suplementar. Um único emoji como 😀 (U+1F600) escapa não como \u1F600 (isso nem é uma forma legal de quatro dígitos hexadecimais), mas como um par substituto: \uD83D\uDE00, dois escapes consecutivos codificando os substitutos alto e baixo. O intervalo substituto alto é U+D800–U+DBFF; o baixo é U+DC00–U+DFFF; juntos cobrem U+10000 até U+10FFFF (os planos suplementares).

Esta é a fonte mais comum de bugs de escape de emoji. A seção 7 da RFC 8259 diz explicitamente: «Para escapar um caractere estendido que não está no plano multilíngue básico, o caractere é representado como uma sequência de 12 caracteres, codificando o par substituto UTF-16.» Um emoji família de quatro como 👨‍👩‍👧‍👦, que é tecnicamente quatro emoji base mais três junções de largura zero, escapa como 30+ caracteres em uma string JSON. A contagem de bytes incha proporcionalmente: 25 bytes UTF-8 brutos, ~58 bytes após escape JSON.

JSON dentro de HTML, URL, SQL e CSV

O escape JSON por si só não é suficiente quando o JSON está incorporado em outro formato. Cada contexto adiciona sua própria camada.

JSON dentro de HTML. A armadilha clássica é <script>const data = {{ payload | json }};</script> quando o payload contém a substring literal </script>. O parser HTML fecha a tag script no meio da string e o resto do JSON é renderizado como texto visível na página. A correção é o escape opcional \/: <\/script> é JSON válido e HTML seguro. A folha de cross-site scripting da OWASP recomenda sempre escapar <, >, & e ' em JSON destinado a embedding HTML.

JSON dentro de uma string de consulta URL. Duas camadas: primeiro escape JSON, depois percent-encoding. {"name":"Bob"} torna-se %7B%22name%22%3A%22Bob%22%7D. Esquecer o percent-encoding é a causa nº 1 de bugs JSON-em-URL malformados.

JSON dentro de SQL. Armazenado em uma coluna PostgreSQL jsonb o valor é parseado nativamente, sem necessidade de escape adicional. Mas JSON incorporado em um literal de string SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) precisa de escape de string SQL em cima de JSON: aspas simples duplicadas (''), ou melhor, use consultas parametrizadas.

JSON dentro de células CSV. O quoting do CSV difere do JSON (CSV usa aspas duplicadas "", não sequências com barra invertida). Incorporar JSON em uma célula CSV precisa de ambas as camadas: escape JSON na string, depois escape CSV no resultado (envolver em "...", dobrar qualquer " interno).

APIs de runtime em várias linguagens

De onde veio JSON, e o que Crockford deixou de fora

JSON foi formalizado pela primeira vez por Douglas Crockford em 2001 na State Software, originalmente para serializar objetos JavaScript para troca de dados assíncrona. A primeira menção pública foi no site JSON.org em 2003. Crockford o especificou formalmente como RFC 4627 em julho de 2006, em parte para combater uma tentativa de patente concorrente na mesma época. O padrão foi para o status STD 90 com RFC 8259 em dezembro de 2017.

A maior decisão de design do JSON foi torná-lo um subconjunto de JavaScript, para que qualquer documento JSON pudesse ser eval'd em um interpretador JS e produzir o valor correto. Isso tornou a adoção no navegador sem atrito mas travou algumas peculiaridades do JS permanentemente: sem tipo inteiro (todos os números são doubles IEEE 754), sem tipo de data, sem NaN ou Infinity. Inteiros grandes acima de 2⁵³−1 precisam de serialização como string ("id": "9007199254740993") para evitar perda silenciosa de precisão.

Crockford deliberadamente deixou de fora coisas que você pode sentir falta: comentários («Removi comentários do JSON porque vi pessoas usando-os para conter diretivas de parsing, uma prática que teria destruído a interoperabilidade», maio 2012), vírgulas finais, e linguagem de esquema (adicionado depois como JSON Schema, mantido separadamente, rascunho atual 2020-12). A variante comunitária JSON5 restaura comentários e vírgulas finais mas não é RFC-conforme; é usada principalmente em arquivos de config (.babelrc, .swcrc) que humanos editam.

Casos de uso comuns

• Incorporando dados em atributos HTML, colar uma string com ", <, >, obter uma forma segura para atributos data-* ou tags script inline.
• Compondo corpos de requisição API à mão, quando se curlando um endpoint e o payload contém aspas ou quebras de linha.
• Construindo payloads de linhas de log onde a mensagem deve sobreviver ao quoting shell mais o parsing JSON do outro lado.
• Migrando dados legados de CSV / XML / TSV para JSON, passada manual de escape de aspas.
• Depurando respostas do servidor onde o valor contém sequências \u, desescapar para ver o que realmente é.
• Escrevendo testes, colar a saída JSON esperada e escapá-la para inclusão em uma asserção de teste.
• Motores de template (Jinja2, Nunjucks, Liquid, ERB) que incorporam JSON em JavaScript ou HTML.

Erros comuns

1. Usando escapes JavaScript que não são JSON válidos. \x41 para «A» e \012 para quebra de linha são válidos em literais de string JS mas inválidos em JSON. JSON só permite os oito escapes nomeados mais \uXXXX.
2. Usando aspas simples para strings JSON. 'hello' funciona em JavaScript mas é JSON inválido. Strings JSON DEVEM usar aspas duplas.
3. Chaves de objeto sem aspas. {name: "Bob"} funciona em JavaScript mas é JSON inválido. Chaves DEVEM ser literais de string entre aspas duplas.
4. Vírgulas finais. [1,2,3,] funciona em JS mas é JSON inválido. RFC 8259 as proíbe explicitamente.
5. Comentários inline. // foo e /* foo */ são inválidos em JSON padrão. Use JSON5 se precisar de comentários; espere que nem todo parser aceite.
6. Escapando manualmente um emoji como um único \uXXXX. Emoji acima de U+FFFF precisam de um par substituto UTF-16, dois \uXXXX consecutivos.

Mais perguntas frequentes

Devo sempre escapar a barra /?

Não, a barra / é permitida sem escape em JSON; o escape \/ é opcional. A exceção é quando JSON está incorporado dentro de uma tag HTML <script>: escapar / como \/ previne que a substring literal </script> feche a tag prematuramente. Alguns codificadores (JSON_HEX_TAG no PHP, substituições JS personalizadas) fazem isso; a maioria não.

Por que JSON.stringify escapa meus caracteres não-ASCII?

Não escapa, por padrão. JSON.stringify("café") em JavaScript produz "café" com o é literal. O que você pode estar vendo é uma biblioteca diferente: json.dumps do Python por padrão usa ensure_ascii=True e escapa tudo fora de ASCII como \uXXXX; json_encode do PHP se comporta similarmente a menos que você passe JSON_UNESCAPED_UNICODE. Ambos comportamentos são JSON válidos, mas o tamanho do arquivo e a legibilidade diferem.

JSON pode armazenar dados binários?

Não diretamente. Strings JSON são sequências de caracteres Unicode, não bytes. O workaround padrão é codificar Base64 o binário primeiro, depois armazenar a string ASCII resultante como um valor JSON normal. Os dados codificados são ~33% maiores que os bytes brutos. Para binários muito grandes, use um formato binário como BSON, MessagePack ou CBOR, ou armazene os bytes separadamente e referencie-os por URL.

Por que algumas ferramentas mostram \u00e9 em vez de é?

Ambos são JSON válidos para o mesmo caractere. "caf\u00e9" e "café" decodificam para strings idênticas. Alguns codificadores escapam não-ASCII para máxima segurança cross-encoding (a saída é ASCII puro então a codificação do consumidor não importa), outros preservam o UTF-8 original para legibilidade. Escolha baseado no que consome seu JSON.

Meu texto é enviado para algum lugar?

Não. A ferramenta usa as APIs nativas JSON.stringify e JSON.parse do navegador inteiramente no cliente. Não há chamada de rede, nem analytics, nem logging. Seguro para escapar tokens API, dados internos, ou qualquer coisa que você não colaria em uma ferramenta de escape do lado do servidor.