Conversor JSON / CSV / YAML / SQL / XML

Não. Os dados são analisados e convertidos no seu navegador com JavaScript, e a ferramenta não os envia à LeedyBox nem os salva. Quando a página abre, ela carrega duas bibliotecas de código aberto do próprio leedybox.com, js-yaml para YAML e PapaParse para CSV; elas são executadas dentro da página, e seus dados não são enviados para lugar nenhum.

Uma entrada que começa com { ou [ é lida como JSON, uma que começa com < como XML, e uma que começa com uma palavra-chave SQL, como INSERT, CREATE, SET, START, UPDATE ou WITH, seguida de um espaço, ou com um comentário -- ou /*, como SQL. Qualquer outra entrada é testada como CSV quando a primeira linha contém vírgula, tabulação ou ponto e vírgula, e depois como YAML. Escolha você mesmo o formato no menu "Entrada" quando um CSV ou YAML começar com uma palavra que também é palavra-chave SQL, por exemplo uma linha de cabeçalho CSV que começa com Start date ou Update time, porque nesse caso ele é lido como SQL e falha; quando todas as linhas de uma entrada YAML tiverem o mesmo número de vírgulas, como title: Hello, world seguido de tags: news, tech, porque ela pode então ser lida como CSV; para CSV delimitado por barra vertical ou de coluna única, que a detecção automática não reconhece; e quando uma entrada YAML ou CSV falhar, porque a detecção automática só informa que o formato não foi reconhecido, enquanto um formato escolhido mostra o erro do próprio analisador e, na maioria dos casos, onde ele ocorreu.

Com o menu "Entrada" em JSON, só JSON válido é aceito, então use essa configuração com "Validar sintaxe" para verificar se o texto é JSON válido. Com "Detecção automática", uma entrada que começa com { ou [, mas não é JSON válido, é lida como sintaxe de fluxo YAML quando possível, e uma observação avisa isso: vírgulas finais, aspas simples e chaves sem aspas passam a funcionar, mas uma chave sem aspas precisa de um espaço depois dos dois-pontos, porque {a:1} é lido como uma chave chamada a:1 com valor nulo. Comentários // e /* */ não são comentários em YAML; eles podem acabar dentro de chaves ou valores, ou impedir a leitura da entrada, então remova-os antes. JSON Lines (NDJSON) é oferecido como formato de saída, mas não é lido como entrada quando tem mais de uma linha; coloque as linhas entre [ e ], com uma vírgula depois de cada linha, exceto a última.

Valores YAML sem aspas que parecem números são lidos como números, então uma versão como 1.10 vira 1.1, um código postal como 01234 vira 1234, e 0x1F vira 31; coloque esses valores entre aspas no YAML para mantê-los como texto. O conversor lê YAML com o esquema core do js-yaml, que segue o YAML 1.2 para booleanos e datas, então yes, no, on, off e datas como 2026-10-02 continuam como texto, e só formas de true e false, como True ou FALSE, viram booleanos. Quando JSON é convertido para YAML, strings que poderiam ser mal interpretadas, como "01234", "1.10" ou "yes", são escritas entre aspas.

Elementos filhos que se repetem sob o mesmo pai viram um array, mas um único elemento vira um valor simples ou um objeto, então <items> com um <item> gera uma estrutura diferente de <items> com dois. Todo valor XML é lido como texto, então <id>1</id> vira "1" e 007 mantém os zeros, enquanto comentários e instruções de processamento são descartados. Na saída CSV e SQL, as linhas são obtidas de um array dentro de invólucros de chave única, como <items>, então, com apenas um <item>, o elemento inteiro acaba como texto JSON em uma única coluna; no CSV, "Achatar (colunas a.b.c)" o divide em colunas.

Sim, desde que as linhas estejam em instruções INSERT INTO ... VALUES. CREATE TABLE, SET, LOCK e instruções de configuração semelhantes são puladas, outras instruções, como DROP TABLE, são ignoradas com uma observação, e as linhas de várias tabelas são reunidas em uma única lista, então cole uma tabela por vez se as colunas forem diferentes. O mysqldump omite os nomes das colunas por padrão, então as colunas recebem os nomes column1, column2 e assim por diante, a menos que você gere o dump com --complete-insert. O pg_dump grava as linhas como blocos COPY por padrão, que a ferramenta não lê, então gere o dump com --column-inserts. Se o dump também tiver funções ou procedimentos armazenados, cole só as instruções INSERT: a ferramenta divide a entrada nos pontos e vírgulas, então um INSERT dentro do corpo de uma função pode ser lido como dado ou interromper a conversão.

Todo valor CSV é tratado como texto, o que mantém zeros à esquerda como em 01234, mas transforma 42 em "42" no JSON e em '42' no SQL, e uma célula vazia vira uma string vazia, e não null ou NULL. O tipo de cada coluna é escolhido a partir dos valores dessa coluna, então uma tabela criada a partir de CSV recebe colunas de texto: VARCHAR(255), ou TEXT quando um valor tem mais de 255 caracteres (NVARCHAR(255) ou NVARCHAR(MAX) no SQL Server, TEXT no SQLite). Quando a entrada é JSON ou YAML e todos os valores de uma coluna são números sem aspas, ou todos são true ou false, a coluna recebe um tipo numérico ou booleano: um tipo inteiro (INT, INTEGER ou BIGINT, conforme o banco de dados e o tamanho dos números), um tipo de ponto flutuante para decimais, ou BOOLEAN (BIT no SQL Server, INTEGER no SQLite). A instrução não tem chave primária, índices nem restrições NOT NULL, então acrescente-os antes de executá-la se a sua tabela precisar deles.