Converter INI para XML

O mapeamento é direto o bastante para prever de antemão. Um cabeçalho de seção vira um elemento, cada chave dentro dela vira um elemento filho, e o valor vira o texto desse elemento. Um arquivo INI com uma seção `[db]` contendo host e porta sai como um elemento db contendo um elemento host e um elemento port.

Essa previsibilidade é o motivo de este par valer uma ferramenta em vez de um script improvisado. Não há ambiguidade para resolver, porque um INI oferece pouquíssima coisa para interpretar: um nível de agrupamento, uma chave, um valor por linha. O que é interessante acontece nas bordas, e o resto desta página é sobre essas bordas.

XML exige exatamente um elemento mais externo, e um INI não tem esse conceito. O conversor resolve isso olhando o que leu: se o arquivo tinha uma seção só, essa seção vira a raiz — um arquivo com `[configuracoes]` sozinho produz um documento cuja tag raiz é configuracoes. Qualquer outra coisa, duas seções ou mais, ou chaves escritas antes do primeiro cabeçalho, é embrulhada numa raiz genérica.

Vale saber isso antes de escrever um esquema XSD ou uma expressão XPath contra o resultado. Adicionar uma segunda seção ao INI de origem muda silenciosamente o elemento raiz do resultado, e qualquer expressão de caminho escrita contra a primeira versão para de bater. Se a forma do documento importa adiante, decida o embrulho por conta própria e mantenha estável, em vez de deixar a contagem de seções decidir.

O INI não tem sistema de tipos nenhum: tudo à direita do sinal de igual é caractere. O leitor tenta adivinhar mesmo assim, transformando true e false em booleano e o que parece número em número, e o gravador de XML então imprime de volta como texto o que recebeu. Para a maioria das chaves a ida e volta é invisível.

Para algumas não é. Um valor escrito como 007 é lido como o número 7 e gravado de volta como 7. Uma chave de versão escrita 1.0 vira 1. Uma máscara hexadecimal escrita 0x1F sai como 31. Qualquer coisa com unidade junto sobrevive intacta, então 128M continua 128M, e o mesmo vale para endereço com ponto como 127.0.0.1 e horário como 08:00, porque nenhum dos dois é interpretado como um número único.

O XML é bem mais rígido com nomes do que o INI. Uma chave de INI pode ter espaço, barra, dois-pontos e colchete; um nome de elemento pode ter letra, número, sublinhado, hífen, ponto e pouco mais, e não pode começar com número. O gravador substitui por sublinhado cada caractere que não pode usar, e adiciona um sublinhado na frente de qualquer nome que comece com algo que não seja letra.

A substituição não é reversível, então duas chaves que diferem só na pontuação podem colidir no mesmo nome de elemento — "nível de log" e "nível-de-log" não colidem, porque o hífen é permitido, mas "nível de log" e "nível/log" viram os dois nivel_de_log. Se o seu INI tem chaves assim, renomeie na origem antes de converter, em vez de tentar descobrir depois qual elemento veio de qual linha.

Um cabeçalho de seção escrito `[banco.conexoes]` parece que deveria virar aninhamento, e em TOML viraria. Aqui não vira: o leitor trata tudo entre os colchetes como um nome de seção único, então o resultado tem um elemento chamado banco.conexoes com as chaves dentro dele. Ponto é permitido em nome de elemento XML, então o documento é válido — só está plano onde talvez você esperasse profundidade.

Se o esquema de destino precisa de aninhamento de verdade, essa estrutura tem que ser criada, não convertida automaticamente. A sequência honesta é converter primeiro e depois reformar o XML resultante à mão ou com XSLT, porque um conversor que tentasse adivinhar aninhamento a partir de pontuação erraria em todo INI onde o ponto faz parte do nome, não de um separador.

O INI não tem um padrão único, só convenções, e um dos pontos em que implementações discordam é o que um cabeçalho de seção repetido significa. Este leitor não mescla os dois blocos: cria uma seção nova e vazia toda vez que vê um cabeçalho, então um arquivo com `[log]` aparecendo duas vezes mantém só as chaves da segunda ocorrência e perde o primeiro bloco inteiro, sem erro nenhum.

Cabeçalhos repetidos são raros em arquivo escrito à mão e comuns em arquivo montado por concatenação — uma configuração base com uma camada de ambiente anexada por cima, um padrão de implantação real. Procure por cabeçalhos duplicados na origem antes de converter, porque a falha é silenciosa e o resultado é um XML perfeitamente bem formado, só que faltando configurações.

Os dois formatos suportam comentário. O INI marca com ponto e vírgula ou cerquilha, o XML com um bloco entre colchetes angulares, e esta conversão não carrega nenhum dos dois: linhas de comentário são puladas na leitura e não reaparecem depois. Nenhum dos dois formatos tem culpa aqui — a perda é do processo, não uma limitação do destino.

Num arquivo de configuração isso importa mais do que parece. A linha acima de um tempo limite explicando que foi aumentado para 90 segundos por causa de um relatório lento costuma ser o único registro dessa decisão em algum lugar. Copie o original comentado para o controle de versão antes de converter, e reanexe as explicações no XML depois — nada numa conversão automática deste tipo faz isso por você.

O motivo de fazer essa mudança quase nunca é a sintaxe. Ao redor do XML existe todo o ferramental que o INI nunca teve: esquemas XSD que rejeitam uma configuração com uma chave escrita errado antes mesmo da aplicação iniciar, XPath para puxar um valor de dentro de um documento grande, XSLT para reformar, assinatura digital para atestar que um arquivo de configuração não foi alterado.

Nada disso chega junto com a conversão. O resultado é um documento bem formado, sem esquema anexado e sem namespace declarado, e escrever o esquema é o trabalho de verdade — a conversão só entrega um documento de partida para escrever aquilo contra ele. Se você não pretende validar, assinar nem transformar o resultado, a migração está comprando verbosidade e nada mais.

Se a aplicação que lê o arquivo é a mesma que o escreveu, e nada adiante precisa de esquema, converter é um custo sem retorno. Um INI é editável por qualquer pessoa que consegue abrir um bloco de notas, e essa é uma propriedade operacional real quando quem muda uma configuração às duas da manhã não é desenvolvedor.

A conversão também é a ferramenta errada se o que você precisa é de dois ou três valores do arquivo, não do arquivo inteiro. Leia esses valores direto da origem. Este conversor serve para o caso em que o INI é a configuração e a configuração inteira está mudando de formato, não para extrair um fragmento.