Pular para o conteúdo principal
ToolsByUs

JSON para tabela Markdown

Este conversor renderiza um array de objetos JSON como uma tabela Markdown no estilo GitHub no seu navegador. As colunas são a união ordenada das primeiras ocorrências de cada chave dos objetos, os pipes são escapados como \|, as quebras de linha se tornam <br>, e a linha separadora corresponde ao seu cabeçalho — assim, a saída cola diretamente em qualquer renderizador Markdown.

Só local

JSON para tabela Markdown: explicação

A documentação roda em tabelas Markdown — listas de recursos de README, entradas de changelog, seções de comparação em um pull request — e os dados por trás delas geralmente começam como JSON: uma resposta de API, um relatório de testes, uma exportação. Digitar a tabela à mão é onde os erros aparecem, porque as tabelas Markdown têm regras fáceis de conhecer de forma imperfeita: uma linha por linha, células divididas por pipes, e uma linha separadora que decide se as colunas existem ou não.

Este conversor faz a digitação para você, seguindo as regras do Markdown no estilo GitHub. A linha de cabeçalho é a união ordenada de cada chave dos objetos, na ordem da primeira ocorrência, então uma chave que aparece a partir do segundo registro ainda ganha sua coluna. Um pipe dentro de um valor é escapado como \| para não dividir uma célula, uma quebra de linha dentro de um valor se torna <br> para não dividir uma linha, e objetos ou arrays aninhados dentro de um registro são renderizados como texto JSON compacto para que nada se perca.

Como em todo este site, a conversão acontece inteiramente no seu navegador. O JSON é parseado com o JSON.parse do navegador próprio, o Markdown é construído na aba, e nada é enviado para lugar nenhum — o painel Network das DevTools fica silencioso em todas as conversões, e a Content-Security-Policy da página bloqueia requisições de saída, independentemente.

A travessia é útil em ambas as direções — uma tabela mantida em uma wiki pode voltar a ser dados — e o Conversor de Markdown para JSON page parseia a sintaxe de tabela do GitHub de volta em registros.

Se o destino for uma planilha em vez de documentação, o Conversor de JSON para CSV produz linhas RFC 4180 a partir dos mesmos registros.

Como a conversão realmente funciona

O motor parseia seu JSON com JSON.parse e requer que o nível superior seja um array de objetos — o único formato que significa linhas. Ele então percorre os registros uma vez, coletando chaves em uma união ordenada: as chaves do primeiro registro abrem a tabela, e uma chave vista pela primeira vez em um registro posterior é anexada à direita em vez de deslocar a ordem de colunas que você já tem. Registros que não possuem uma chave simplesmente deixam aquela célula vazia. Nada no resultado depende de ferramentas que você não tem: a tabela é texto puro, então ela sobrevive a copiar-colar, revisão de código e builds de site estático. Depois, a tabela é escrita, uma regra por perigo:

  • Cabeçalho: uma linha com as chaves da união, depois uma linha separadora com três traços por coluna — a linha que torna o bloco uma tabela em todo renderizador no estilo GitHub.
  • Pipes: um | dentro de um valor é emitido como \|, o escape que o GFM define, então um valor como a|b permanece como uma única célula.
  • Quebras de linha: um \n dentro de um valor se torna <br>, porque uma quebra de linha real terminaria a linha e corromperia tudo abaixo dela.
  • Valores aninhados: um objeto ou array dentro de um registro é renderizado como texto JSON compacto em sua célula, então dados aninhados são visíveis em vez de serem descartados silenciosamente.

Como a saída se parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” do conversor produz: duas pessoas, onde o valor notes do primeiro registro contém um pipe e o do segundo contém uma quebra de linha. O pipe escapado renderiza como um literal | dentro de sua célula, a quebra de linha renderiza como uma quebra de linha sob <br>, e ambas as linhas mantêm suas três colunas. As linhas são envolvidas em pipes no início e no fim, que é o formato que todo renderizador e ferramenta de diff lê com mais confiabilidade.

Cole a saída em qualquer renderizador no estilo GitHub e a visualização que você vê lá é o que os leitores recebem. A tabela também é estável sob diff por um motivo silencioso: a ordem das colunas depende da ordem do documento em vez de uma ordenação, então um registro que ganha uma chave anexa uma coluna em vez de reorganizar as que seus leitores já conhecem.

As regras de célula de relance

Cada perigo que uma célula de tabela pode conter, e sua forma emitida:

Conteúdo da célulaEmitido comoPorquê
a|ba\|bUm pipe bruto dividiria a célula
linha um\nlinha doislinha um<br>linha doisUma quebra de linha bruta terminaria a linha
{"x": 1}Texto JSON compactoValores aninhados mostrados, não descartados
truetrueBooleanos são renderizados como estão
(chave ausente)(célula vazia)Registros irregulares permanecem alinhados

Entradas que este conversor recusa

Dois formatos não têm uma tabela fiel e são recusados com uma mensagem específica em vez de forçados:

  • Um nível superior que não é um array — um único objeto é uma linha sem tabela para unir, e envolvê-lo em um array sintético inventaria estrutura que você não escreveu.
  • Um cujos elementos não são todos objetos — uma lista de escalares não tem chaves, então não há nada para se tornar cabeçalhos de coluna; o conversor nomeia o índice ofensor.

Perguntas frequentes

É algum enviado para um servidor quando eu converto JSON para Markdown?

Não. O parseamento e a renderização são executados nesta aba do navegador com JavaScript local à página. Não há endpoint de upload, e a Content-Security-Policy proíbe conexões de saída. Você pode confirmar ambos nas DevTools: abra o painel Network, converta um documento e observe que nenhuma requisição é feita em nenhum momento.

Para qual dialeto Markdown a saída é escrita?

Markdown no estilo GitHub, a sintaxe de tabela usada pelo GitHub, GitLab e a maioria das ferramentas de documentação. A assinatura é a linha separadora de traços sob o cabeçalho — este conversor emite três traços por coluna sem dois-pontos de alinhamento, então as células alinham-se à esquerda por padrão — e as linhas levam pipes no início e no fim para máxima compatibilidade com renderizadores.

Por que um pipe dentro do meu valor precisa ser escapado?

Porque o pipe é o delimitador de célula: um | bruto seria lido como o fim de uma célula e o início de outra, deslocando silenciosamente cada célula após ele. O escape do GFM é o par barra invertida-pipe \|, que renderiza como um pipe literal dentro da célula. O conversor aplica a cada valor, então um exemplo de código como a|b chega na tabela do jeito que começou.

Por que quebras de linha em valores se tornam <br> e não quebras de linha reais?

Uma linha de tabela Markdown é uma linha única por definição — uma quebra de linha bruta dentro de uma célula termina a linha, e o renderizador trata o resto como um novo parágrafo, corrompendo a tabela. A tag HTML <br> renderiza como uma quebra de linha dentro da célula, que é a convenção que o próprio GitHub documenta para conteúdo de célula multi-linha.

Como a ordem das colunas é decidida?

Pela união de cada chave dos registros na ordem da primeira ocorrência: as chaves do primeiro registro definem as colunas iniciais, e qualquer chave que apareça depois é anexada à direita. Registros sem uma chave deixam aquela célula vazia. A ordem é estável — ordem do documento, não alfabética — porque um conversor que reordenasse suas colunas faria todo diff posterior da saída barulhento.

O que acontece com objetos e arrays aninhados em um registro?

Eles são renderizados como texto JSON compacto dentro de sua célula, então a informação permanece visível em vez de ser descartada ou achatada além do reconhecimento. Se a estrutura aninhada importar downstream — filtragem, ordenação, criação de gráficos — achate-a primeiro com o conversor de JSON para CSV, que transforma caminhos aninhados em colunas; para leitura e revisão, a célula de texto JSON geralmente é exatamente o suficiente.

Equipe ToolsByUs · Como verificamos nossas ferramentas