Analisador de Java .properties

Como usar

1. Cole o conteúdo na caixa ou solte um arquivo .properties na área indicada: ele é lido no navegador e nunca enviado.
2. Leia a tabela por linha: cada entrada com a linha de onde veio, o separador realmente usado e uma etiqueta para o que houver de incomum.
3. Percorra os achados acima. Chaves duplicadas, espaço no fim do valor e uma continuação que engoliu a entrada seguinte são os três que mudam o comportamento em produção sem avisar.
4. Se houver caracteres não ASCII, alterne a leitura entre UTF-8 e ISO-8859-1 para ver exatamente o que o load(InputStream) vai entregar à sua aplicação.
5. Copie a visão JSON para comparar configurações, ou a visão Properties.store para obter o mesmo mapa escrito com todos os separadores e caracteres não ASCII já escapados.

Perguntas frequentes

Por que "c three" vira chave e valor se não há um sinal de =?

Porque neste formato o espaço em branco também é separador. O Properties.load procura o primeiro =, : ou caractere de espaço não escapado, o que vier primeiro, e toma como chave tudo o que vem antes. Por isso "c three" é a chave c com o valor three, e em "key with spaces=x" a chave é "key" e o valor é "with spaces=x": o = nunca chega a agir como separador. Se você precisa de um espaço dentro da chave, tem de escrevê-lo como "\ ", que é exatamente o que o Properties.store faz ao gravar essa chave de volta.

Meus caracteres acentuados saem como é. O que aconteceu?

A especificação do java.util.Properties.load(InputStream) diz que o fluxo é decodificado como ISO-8859-1, um byte por caractere. Um arquivo salvo em UTF-8 guarda é em dois bytes, e esses dois bytes viram dois caracteres latinos — o mojibake clássico. Nada é lançado, então a corrupção viaja até onde o texto for exibido. Há três correções: escrever o não ASCII como \uXXXX (o que native2ascii e Properties.store produzem), chamar load(Reader) com um InputStreamReader em UTF-8, ou usar loadFromXML, que é UTF-8 por padrão.

O espaço no fim de um valor sobrevive mesmo?

Sobrevive, e é a origem de um gênero inteiro de relatos de bug. O espaço no início da linha é descartado, o que cerca o separador é descartado e a indentação de uma linha de continuação também, mas o espaço no fim do valor é mantido literalmente, porque a linha acaba ali e ninguém apara. Uma senha ou URL com um espaço a mais é analisada sem erro, não conecta em nada e parece idêntica à versão boa em qualquer editor e em qualquer revisão de código. A tabela desta página marca esses caracteres para que fiquem visíveis.

Quando uma linha continua na seguinte?

Quando termina em um número ímpar de barras invertidas. A última barra é removida, a linha seguinte é anexada e a indentação dela é retirada, então uma continuação indentada lê-se naturalmente. Um número par não é continuação: são barras literais, pela metade, e a entrada acaba ali. Daí saem duas surpresas. Uma continuação pode engolir o que parece a próxima entrada: se um valor termina em uma barra perdida, o "chave=valor" de baixo passa a fazer parte daquele valor e a chave some. E uma linha de comentário terminada em barra não continua de jeito nenhum, porque comentários são descartados inteiros.

Duas linhas definem a mesma chave. Qual vence?

A última, em silêncio. Properties é uma Hashtable e o load apenas chama put para cada entrada conforme avança, então uma linha posterior sobrescreve a anterior sem aviso, sem erro e sem deixar registro. É fácil criar isso sem querer quando um arquivo é montado a partir de vários fragmentos, ou quando uma chave é definida uma vez com = e outra com : e as duas não se parecem à primeira vista. Esta página lista cada chave duplicada com todos os números de linha que a definem e esmaece as que perderam.

É o mesmo formato de um arquivo .env?

Não, e tratar um como o outro é fonte comum de quebras silenciosas. Um .env não tem separador por espaço, usa aspas para proteger valores e guardar textos de várias linhas, trata um # depois do valor como comentário na mesma linha e muitas vezes suporta expansão ${VAR}. Um .properties não tem nada disso: aspas são caracteres comuns que acabam dentro do valor, o # depois de um valor faz parte do valor, o formato em si não expande variáveis (o Spring acrescenta a dele por cima) e a continuação é feita com barras invertidas, não com aspas.

Ferramentas relacionadas