Por que meus nomes de arquivos parecem 'normais' no Linux, mas não remotamente no Windows?

Question

Ao trabalhar com um colega, encontrei um problema estranho que parece relacionado à codificação. Estamos trabalhando com algumas imagens que têm nomes de arquivos simples o suficiente, como city.gif ou wine.gif , mas como é de se esperar que as coisas fiquem mais complicadas ao usar caracteres especiais como é , ë , à . Também estamos trabalhando com dados holandeses que possuem esses caracteres, por exemplo, café ( pub ). (Nós não temos controle sobre a origem dos arquivos.) Aqui é onde os problemas começam a surgir. Os seguintes nomes de arquivos são apenas um exemplo. O problema também ocorre para outros caracteres com diacríticos.

café-2.png
cafetaria.png
café.png

O primeiro e último item deve ter um e acentuado lá (sotaque aigu, é ). É assim que é mostrado no Linux (CentOS 6 e 7) em um terminal ao executar ls . Mas aqui vem o Windows! (Usando o Windows 10, 64 bits.) Quando conectado no Windows através de SSL com o nosso servidor e, em seguida, chamando ls , a lista acima se parece com isso:

café-2.png
cafetaria.png
caf▒.png

Como você pode ver, a primeira linha ainda tem o e é acentuado, mas o terceiro não. Em vez disso, vejo ▒ este caractere - que é medium shade em unicode (9618 decimal). Isso é estranho em si mesmo. No entanto, quando eu me conecto através de SFTP com o Filezilla (ainda no Windows) eu vejo isso:

café-2.png
cafetaria.png
café.png

Então agora as coisas mudaram: na primeira, é mudou para a sequência e na terceira está tudo bem. Eu encontrei aqui que isso é provavelmente devido a um Latin-1 < - > Conversão UTF-8 que deu errado, se eu entendi direito. Mas isso não pode ser tudo o que está acontecendo, certo?

O Linux mostra tudo como esperávamos, o Windows mostra um comportamento aparentemente inconsistente, dependendo da forma como vemos o nome do arquivo (SSH (putty) ou SFTP (filezilla)). Existe uma maneira de "normalizar" esses nomes de arquivos - ou seja, editá-los - e certifique-se de que eles sejam todos iguais em todos os SOs; ou pelo menos consistente, e se sim, como? UTF-8 é nossa codificação de escolha.

Embora isso possa ser apenas uma questão estética, não é. Ao tentar baixar coisas através do SFTP no Windows a partir do nosso servidor Linux, não consigo baixar os arquivos que possuem o problema mencionado acima. O Filezilla lançará um erro como Can't download file café-2.png: café-2.png does not exist on the server . O que me parece que o Filezilla lê o diretório e o nome do arquivo, interpreta-o em alguma codificação, envia um pedido GET ao servidor com sua interpretação, mas essa interpretação difere do nome do arquivo Linux e, consequentemente, o arquivo não é encontrado.

Em última análise, seria bom se houvesse uma solução disponível, embora eu também esteja interessado em por que isso acontece. Isso ocorre porque os arquivos de imagem possivelmente foram criados em sistemas operacionais diferentes? Isso ocorre porque o servidor Linux os interpreta errado ou o Windows está bagunçando? Espero que haja uma solução em que possamos apenas entrar em contato com nosso administrador de sistema e pedir que ele ligue um switch na configuração do servidor, mas infelizmente não é tão fácil assim.

    

Answer 1

But here comes Windows!

O Windows não tem nada a ver com isso. Você poderia reproduzir este mesmo comportamento exato com uma instância local do (digamos) Terminal GNOME, com codificação de terminal apropriadamente selecionada e localidade apropriadamente configurada para ls , sem que nenhum Windows esteja na imagem de todo . / p>

A única coisa que o Windows faz é mostrar claramente o que está acontecendo aqui. Seu programa FTP do Windows está tomando os bytes nos nomes dos arquivos e exibindo-os como os pontos de código relevantes na página de código 1252. Isso, uma codificação de byte único com quase tudo acima de 0x1F um glifo imprimível, nos diz exatamente quais bytes em seus nomes de arquivos .

Seu segundo nome de arquivo é em grande parte não informativo, mas o primeiro e o terceiro são reveladores.

• O primeiro nome do arquivo é a sequência de bytes 63 61 66 c3 a9 2d 32 2e 70 6e 67 - na página de códigos 1252, esta é %código%. É também a codificação UTF-8 de café-2.png .
• O terceiro nome do arquivo é a seqüência de bytes café-2.png 63 61 66 e9 2e 70 6e - Na página de códigos 1252, isso é 67 . Não é, no entanto, uma codificação UTF-8 válida. café.png inicia uma sequência de codificação de caracteres incompleta.

Então o que está acontecendo é que as coisas são não usando a página de código 1252 mas que estão usando UTF-8, ou seja, sua sessão SSH e seu emulador de terminal local, estão manipulando o válido UTF-8 da mesma forma que os outros, mas estão lidando com o inválido UTF-8 de duas maneiras diferentes:

• Aquele que está exibindo o gráfico de bloco provavelmente está usando o gráfico de bloco como o caractere de saída de substituição para seqüências UTF-8 inválidas.
• Aquele que está exibindo a letra e9 está retornando à Página de código 1252 quando encontra uma codificação inválida.

Seu problema subjacente é um sistema que de alguma forma gera alguns nomes de arquivos codificados como UTF-8 e outros nomes de arquivos codificados na Página de código 1252.