Usando o comando FTP, transferi um arquivo xml de uma caixa do Red Hat Enterprise Linux que está na Europa para outra caixa do RHEL nos Estados Unidos. Eu não especifiquei um modo de transferência, então ele foi padronizado para ASCII, o que, até onde eu entendo, não deveria traduzir caracteres entre duas caixas Linux, mas sim. O tamanho do arquivo cresceu no destino e o vim relatou isso como um arquivo do DOS. Eu verifiquei e LANG = en_US.UTF-8 em ambas as máquinas.
Alguém sabe por que essa tradução de personagem aconteceu?
Isso é exatamente o que o modo ASCII faz. Ele traduz fins de linha.
Se você não quiser isso, simplesmente mude para o modo BINÁRIO, que transfere os dados como estão, sem qualquer transformação.
Hoje você quase nunca quer o modo ASCII. Especialmente não para arquivos XML.
RFC 959 diz que ao enviar o modo ASCII, o lado de envio deve enviar o arquivo em um formato padrão. forma "com fins-de-linha CRLF, e o" receptor converterá os dados do formulário padrão para sua própria forma interna. " (Veja seção 3.1.1.1, Tipo ASCII.)
Portanto, parece que, no seu caso, o lado de envio enviou o arquivo com fins-de-linha CRLF, porque o protocolo FTP o exige e o lado de recebimento os mantém por algum motivo.
Eu encontrei a seguinte página que diz por padrão, o servidor FTP no Red Hat Enterprise Linux 3 e 4 finge permitir o modo ASCII, mas pré-forma uma transferência binária de qualquer maneira: Por que o servidor FTP vsftp falha ao transferir um arquivo no modo ASCII quando o modo ASCII foi configurado pelo cliente FTP no Red Hat Enterprise Linux 3 e 4?
Isso pode explicar por que está mantendo os fins de linha da CRLF.