Re: [IRPF Livre] Melhora aplicação, conversor, scripts, e mapeamentoTxt

[Adonay Felipe Nogueira]

Depois de ter sido informado de que a codificação de caracteres da minha 
contribuição estava diferente do UTF-8, confirmei que não houve impacto 
na codificação de caracteres dos arquivos no resultado após aplicação da 
contribuição.

Em adendo, decidi investigar a minha cópia de trabalho. Por isso, fiz o 
seguinte comando, obtendo o seguinte resultado:

svn status | awk 'BEGIN { FS = "       "; ORS = "\0" } { print($2) }' | 
xargs -0 file -iN
contrib/LEIAME: text/plain; charset=utf-8
contrib/tirar_ano_anterior_do_mapeamentoTxt.xslt: text/plain; charset=
utf-8
contrib/ver_TipoArquivo_e_Nomes_do_mapeamentoTxt.xslt: text/plain; cha
rset=utf-8
res/aplicacao.properties: text/plain; charset=iso-8859-1
res/bancos.xml: text/xml; charset=utf-8
res/mapeamentoTxt.xml: text/xml; charset=utf-8
src/serpro/ppgd/irpf/txt/gravacaorestauracao/ConversorObjetosIRPF2Regi
stros.java: text/x-java; charset=utf-8

Isto me leva a crer que arquivos como o `res/aplicacao.properties` podem 
causar problemas no futuro. Inspecionei o trecho da contribuição que 
atua sobre o arquivo e percebi que ele de fato cita partes do original 
que possuem os caracteres problemáticos, mas sem modificar estas partes, 
ou seja, apenas usando elas como linhas de contexto.

Não sei como dizer ao Subversion para fazer a conversão de codificação 
de caracteres mas, caso isto não seja possível, temos então algumas opções:

a) converter o nosso para UTF-8, tendo o efeito adverso de que ao 
comparar com o da Receita Federal, teríamos que ignorar de algum modo a 
diferença de codificação ou lembrar de converter antes;

b) não converter o nosso aplicacao.properties para UTF-8, tendo que 
lidar com ele de forma especial em todas as contribuições em que ele 
aparece, mas tendo a vantagem de que as comparações com o da Receita 
Federal não precisarão de tratamento especial, ou;

c) similar à alínea (a), mas restruturar a árvore de arquivos de modo 
que os não utilizados e com codificação problemática sejam removidos.

Se nenhum outro arquivo usar uma codificação de caracteres diferente de 
UTF-8 nos arquivos fonte do IRPF Livre, então sou a favor de (a). Para 
ter uma ideia disto, fiz uma contagem dos arquivos que têm codificação 
diversa. Para referência, usei algo como:

$ find . \( -type d -name '.svn' -prune \) -o \( ! -type d \( -name 
'*.jpg' -o -name '*.jpeg' -o -name '*.png'  -o -name '*.gif' -o -name 
'*.ico' -o -name '*.bmp' \) -prune \) -o \( ! -type d -print0 \) | xargs 
-0 -I '{}' -- sh -c 'file --mime-encoding -F "|" -N "{}"' | awk 'BEGIN { 
FS = "| " } { ++freq[$2] } END { for(cada in freq) print(cada, 
freq[cada]) }' | sort -k 2n
unknown-8bit 6
binary 96
utf-8 153
iso-8859-1 434
us-ascii 6370

Pude perceber então que existem vários arquivos que podem não ser UTF-8.

Em 06/05/2023 21:20, Adonay Felipe Nogueira escreveu:
> Segue em anexo mais uma contribuição, com descrição no início.
> 
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/softwares-impostos/attachments/20230507/f4fef3f1/attachment.sig>