Ferramentas para desenvolvedores · Formatador e validador JSON
Caracteres invisíveis que quebram JSON: BOM, aspas inteligentes e NBSP
· Como funciona
JSON fluxo de trabalho do desenvolvedor validação
Quando o validador relata um erro no primeiro caractere e o arquivo parece perfeito, geralmente a culpa é de um caracter invisível. Esta postagem explica marcas de ordem de bytes, citações tipográficas e espaços inseparáveis, e como cada um é relatado.
Linha 1, coluna 1, nada de errado para ver
Linha 1, coluna 1, nada de errado para ver — um documento JSON pode começar com um caractere que ocupa uma posição real, mas é renderizado sem nenhum glifo visível. A chave de abertura parece ser a primeira, mesmo que uma marca de ordem de byte ou um caractere de largura zero a preceda. Um analisador estrito encontra esse ponto de código oculto antes de atingir `{`, portanto, o relatório da primeira coluna é preciso e não vago. A exibição e a sequência de personagens simplesmente contam histórias diferentes.
Não exclua uma chave que pareça correta apenas porque o sinal de intercalação aparece ao lado dela. Inspecione o ponto de código no deslocamento relatado, habilite espaços em branco visíveis ou mude para uma visualização hexadecimal. ToolAcre não remove silenciosamente um BOM inicial antes da análise e seu scanner relata o primeiro caractere inesperado.
A marca de ordem de bytes UTF-8
A marca de ordem de bytes UTF-8 — a sequência de bytes EF BB BF decodifica para U+FEFF no início de um arquivo. A ordem dos bytes não é ambígua em UTF-8, portanto a marca é desnecessária, mas alguns editores e ferramentas de exportação ainda a adicionam como uma assinatura de codificação. RFC 8259 diz que os geradores JSON não devem adicionar um BOM ao JSON em rede, embora os analisadores possam optar por ignorar um para interoperabilidade. Essa tolerância não pode ser assumida entre ferramentas.
Em uma string JavaScript, BOM é um caractere, embora sua representação UTF-8 use três bytes. ToolAcre relata posições em caracteres de string, portanto, uma marca inicial aparece na linha 1, coluna 1. Configure o editor para salvar UTF-8 sem BOM ou remover U+FEFF antes de distribuir o arquivo.
Citações inteligentes de processadores de texto
Citações inteligentes de processadores de texto - as marcas tipográficas de abertura e fechamento parecem polidas em prosa, mas JSON reconhece apenas as aspas ASCII U+0022 como um delimitador de string. U+201C e U+201D são caracteres Unicode comuns. Fora de uma string, eles não podem iniciar um nome ou valor de propriedade, então o validador reporta a própria aspa inteligente. A correção automática no chat, e-mail ou editor de documentos geralmente introduz a alteração depois que JSON era originalmente válido.
Substitua os delimitadores por aspas duplas retas e examine os apóstrofos e aspas que pertencem ao valor. Aspas curvas são perfeitamente legais como conteúdo dentro de uma string JSON delimitada corretamente, como `"She said “go”"`; eles falham apenas quando solicitados a realizar o trabalho gramatical do delimitador.
Espaços inseparáveis e caracteres de largura zero
Espaços inseparáveis e caracteres de largura zero — JSON espaço em branco é uma lista deliberadamente curta: espaço comum U+0020, tabulação U+0009, alimentação de linha U+000A e retorno de carro U+000D. Um espaço ininterrupto U+00A0 pode parecer idêntico a um espaço normal entre dois pontos e um valor, mas não está nessa lista. Um espaço de largura zero U+200B não mostra absolutamente nada, mas permanece um caractere inesperado fora de uma string entre aspas.
As páginas da Web usam espaços inseparáveis para manter as palavras unidas, e os sistemas de mensagens podem inserir caracteres de largura zero para quebra automática ou manipulação de scripts. Copiar trechos formatados pode levá-los à configuração. Substitua caracteres estruturais NBSP por espaços comuns e remova caracteres de largura zero não intencionais, guiados pelo deslocamento relatado.
Exemplo resolvido: uma configuração copiada de uma mensagem de chat
Exemplo resolvido: uma configuração copiada de uma mensagem de chat — suponha que o texto visível seja semelhante a `{"mode": "safe"}`, mas a validação falha no início. Uma visualização hexadecimal revela EF BB BF antes da chave. A remoção de BOM avança o próximo relatório para a cotação anterior a `mode`, que na verdade é U+201C. Substituir ambos os delimitadores inteligentes por U+0022 expõe então um U+00A0 entre os dois pontos e o valor.
Mude esse espaço estrutural ininterrupto para U+0020 e valide mais uma vez. O resultado aceito agora pode ser formatado normalmente. Esta sequência mostra por que não é confiável reparar apenas o que a tela parece mostrar: vários caracteres invisíveis ou semelhantes podem ocupar diferentes posições gramaticais. Siga cada linha e coluna, identifique o ponto de código real, faça uma substituição intencional e execute novamente a validação.
Como ver o invisível
Como ver o invisível — ative a opção de renderização de espaço em branco do editor para distinguir tabulações de espaços e revelar lacunas incomuns e, em seguida, use um inspetor Unicode ou visualização hexadecimal para caracteres que ainda parecem idênticos. Um UTF-8 BOM aparece como EF BB BF, um espaço ininterrupto como C2 A0 e um espaço de largura zero como E2 80 8B. As cotações inteligentes de abertura e fechamento aparecem como E2 80 9C e E2 80 9D.
Combine o sistema de coordenadas do diagnóstico antes de contar. ToolAcre verifica uma string JavaScript, portanto, suas colunas contam UTF-16 unidades de código em vez de UTF-8 bytes. Um editor hexadecimal orientado a bytes pode, portanto, mostrar um deslocamento numérico maior após caracteres não ASCII. Use a linha relatada para restringir a pesquisa, inspecionar os pontos de código vizinhos e traduzir apenas quando necessário.
O que isso não cobre
O que isso não cobre – mojibake como `café` pode ser JSON completamente válido. O analisador vê uma sequência comum de caracteres de string e não tem nenhuma evidência de que UTF-8 bytes foram decodificados anteriormente como outra codificação. Da mesma forma, um espaço ininterrupto ou um caractere de largura zero dentro de um valor entre aspas é sintaticamente válido. A validação captura caracteres que violam a gramática JSON; ele não pode decidir se o conteúdo Unicode válido corresponde à intenção do autor.
Repare a corrupção da codificação no limite onde os bytes se transformam em texto, usando o conhecimento das codificações originais e incorretas. Não codifique e decodifique repetidamente uma string JSON até que pareça melhor, pois isso pode danificar caracteres já corretos. A normalização no nível do aplicativo também é uma decisão separada: sequências Unicode visualmente idênticas podem ser comparadas de maneira diferente, embora permaneçam válidas.
Conclusão: confie na coluna relatada mesmo quando a linha parece limpa
Conclusão: confie na coluna relatada mesmo quando a linha parece limpa – caracteres invisíveis e pontuação semelhante ainda ocupam posições precisas na fonte. Um BOM inicial, delimitador encaracolado, espaço inseparável ou marca de largura zero pode impedir que um analisador alcance a chave ou aspa que parece correta. Revele espaços em branco, inspecione pontos de código ou bytes e substitua o caractere cuja identidade entra em conflito com sua função gramatical, em vez de editar aleatoriamente JSON visível próximo.
Lembre-se de que as posições podem contar caracteres enquanto uma ferramenta hexadecimal conta bytes codificados, portanto compare o texto ao redor em vez de esperar que cada número de deslocamento corresponda. Remova um BOM apenas no limite do documento, converta delimitadores inteligentes em U+0022 e substitua o espaçamento estrutural inválido sem apagar o Unicode legítimo dentro das strings.