¿Por qué los nombres de mis archivos se ven 'normales' en Linux pero no de forma remota en Windows?

Mientras trabajaba con un colega encontré un problema extraño que parece estar relacionado con la codificación. Estamos trabajando con algunas imágenes que tienen nombres de archivo bastantes simples, tales como city.gifo wine.gif, pero como era de esperar cosas se complican más cuando se utilizan caracteres especiales como é, ë, à. También estamos trabajando con datos holandeses que tienen estos caracteres, por ejemplo café( pub ). (No tenemos control sobre el origen de los archivos). Aquí es donde comienzan a surgir los problemas. Los siguientes nombres de archivo son solo un ejemplo. El problema también ocurre para otros personajes con signos diacríticos.

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

El primer y último elemento debe tener una e acentuada allí (acento aigu, é). Así se muestra en Linux (CentOS 6 y 7) en un terminal cuando se ejecuta ls. ¡Pero aquí viene Windows! (Usando Windows 10, 64 bit.) Cuando se conecta en Windows a través de SSL con nuestro servidor y luego llama ls, la lista anterior se ve así:

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

Como puede ver, la primera línea todavía tiene la e acentuada é, pero la tercera no. En cambio, veo ▒este carácter, que está medium shadeen Unicode (9618 decimal). Esto es extraño en sí mismo. Sin embargo, cuando me conecto a través de SFTP con Filezilla (todavía en Windows) puedo ver esto:

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

Así que ahora las cosas han cambiado: en el primero, éha cambiado a la secuencia y en el tercero todo está bien. Encontré aquí que esto probablemente se deba a una conversión Latin-1 <-> UTF-8 que salió mal, si lo hice bien. Pero eso no puede ser todo lo que está pasando, ¿verdad?

Linux muestra todo como esperamos, Windows muestra un comportamiento aparentemente inconsistente dependiendo de la forma en que vemos el nombre del archivo (SSH (masilla) o SFTP (filezilla)). ¿Hay alguna manera de 'normalizar' estos nombres de archivo, es decir, editarlos, y asegurarse de que sean todos iguales en cada sistema operativo? o al menos consistente, y si es así, ¿cómo? UTF-8es nuestra codificación de elección.

Aunque esto puede ser simplemente un problema estético, no lo es. Al intentar descargar cosas a través de SFTP en Windows desde nuestro servidor Linux, no puedo descargar los archivos que tienen el problema mencionado anteriormente. Filezilla arrojará un error como Can't download file café-2.png: café-2.png does not exist on the server. Lo que me parece que Filezilla lee el directorio y el nombre del archivo, lo interpreta con alguna codificación, envía una solicitud GET al servidor con su interpretación, pero esa interpretación difiere del nombre del archivo de Linux, por lo que no se encuentra el archivo.

En última instancia, sería bueno si hay una solución disponible, aunque también estoy interesado en por qué sucede esto. ¿Ocurre porque los archivos de imagen posiblemente se crearon en diferentes sistemas operativos? ¿Ocurre porque el servidor Linux los interpreta mal o Windows está estropeando? Esperemos que haya una solución en la que podamos contactar a nuestro administrador de sistemas y pedirles que activen un interruptor en la configuración del servidor, pero me temo que no es tan fácil como eso.

¡Pero aquí viene Windows!

Windows no tiene nada que ver con esto. Se podría reproducir este mismo comportamiento exacto con una instancia local de (digamos) Terminal de GNOME, con la codificación del terminal seleccionado apropiadamente y la configuración regional debidamente configurado para ls, sin ningún tipo de Windows estar en la imagen en absoluto .

Lo único que hace Windows es mostrar claramente lo que está sucediendo aquí. Su programa FTP de Windows toma los bytes en los nombres de archivo y los muestra como los puntos de código relevantes en la página de códigos 1252. Esto, una codificación de un solo byte con casi todo por encima de 0x1F un glifo imprimible, nos dice exactamente cuáles son los bytes en sus nombres de archivo .

Su segundo nombre de archivo es poco informativo, pero el primero y el tercero son reveladores.

• El primer nombre de archivo es la secuencia de bytes 63 61 66 c3 a9 2d 32 2e 70 6e 67. En la página de códigos 1252 es esta café-2.png. También es la codificación UTF-8 de café-2.png.
• El tercer nombre de archivo es la secuencia de bytes 63 61 66 e9 2e 70 6e 67. En la página de códigos 1252 es esta café.png. Sin embargo, no es una codificación UTF-8 válida. e9comienza una secuencia de codificación de caracteres incompleta.

Entonces, lo que está sucediendo es que las cosas no están usando la página de códigos 1252 sino que están usando UTF-8, es decir, su sesión SSH y su emulador de terminal local, están manejando el UTF-8 válido de la misma manera que el otro, pero están manejando el UTF-8 no válido de dos maneras diferentes:

• El que muestra el gráfico de bloque probablemente esté usando ese gráfico de bloque como el carácter de salida de reemplazo general para secuencias UTF-8 no válidas.
• El que muestra la letra évuelve a la página de códigos 1252 cuando encuentra una codificación no válida.

Su problema subyacente es un sistema que de alguna manera genera algunos nombres de archivos codificados como UTF-8 y otros nombres de archivos codificados en la página de códigos 1252.