Perché i miei nomi di file sembrano "normali" in Linux ma non in remoto su Windows?

Mentre lavoravo con un collega ho trovato uno strano problema che sembra legato alla codifica. Stiamo lavorando con alcune immagini che hanno i nomi di file abbastanza semplici come city.gifo wine.gif, ma come ci si potrebbe aspettare le cose si complicano quando si usano caratteri speciali quali é, ë, à. Stiamo anche lavorando con dati olandesi che hanno questi caratteri, ad esempio café( pub ). (Non abbiamo il controllo sull'origine dei file.) Ecco dove iniziano a sorgere i problemi. I seguenti nomi di file sono solo un esempio. Il problema si verifica anche per altri personaggi con segni diacritici.

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

Il primo e l'ultimo oggetto dovrebbero avere una e accentata (accent aigu, é). Ecco come viene mostrato in Linux (CentOS 6 e 7) in un terminale durante l'esecuzione ls. Ma ecco che arriva Windows! (Usando Windows 10, 64 bit.) Quando ci si connette su Windows tramite SSL con il nostro server e quindi si chiama ls, l'elenco sopra appare così:

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

Come si spera, la prima riga ha ancora l'accento e é , ma la terza no. Invece, vedo ▒questo personaggio - che è medium shadein Unicode (9618 decimale). Questo è strano in sé. Tuttavia, quando mi connetto tramite SFTP con Filezilla (sempre su Windows), vedo questo:

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

Quindi ora le cose si sono capovolte: nella prima éè cambiato nella sequenza e nella terza va tutto bene. Ho trovato qui che questo è probabilmente dovuto ad un Latin-1 <-> UTF-8 di conversione che è andato storto, se ho capito bene. Ma non può essere tutto quello che succede, giusto?

Linux mostra tutto come ci aspetteremmo, Windows mostra un comportamento apparentemente incoerente a seconda del modo in cui vediamo il nome file (SSH (putty) o SFTP (filezilla)). C'è un modo per "normalizzare" questi nomi di file - cioè modificarli - e assicurarsi che siano tutti uguali su tutti i sistemi operativi; o almeno coerente, e se sì, come? UTF-8è la nostra codifica preferita.

Anche se questo può essere solo un problema estetico, non lo è. Quando provo a scaricare cose tramite SFTP in Windows dal nostro server Linux, non riesco a scaricare i file che hanno il problema sopra menzionato. Filezilla genererà un errore come Can't download file café-2.png: café-2.png does not exist on the server. Il che mi sembra che Filezilla legga la directory e il nome del file, lo interpreti in una certa codifica, invii una richiesta GET al server con la sua interpretazione, ma tale interpretazione differisce dal nome del file Linux, di conseguenza il file non viene trovato.

In definitiva sarebbe bello se ci fosse una soluzione disponibile, anche se sono anche interessato al perché questo accada. Succede perché i file di immagine sono stati probabilmente creati su diversi sistemi operativi? Si verifica perché il server Linux li interpreta in modo errato o Windows è in disordine? Speriamo che ci sia una soluzione in cui possiamo semplicemente contattare il nostro amministratore di sistema e chiedere loro di attivare un interruttore nella configurazione del server, ma temo che non sia così semplice.

Ma ecco che arriva Windows!

Windows non ha nulla a che fare con questo. Si potrebbe riprodurre questo stesso comportamento Campione con un'istanza locale di (diciamo) Terminale GNOME, con codifica terminale opportunamente selezionati e locale opportunamente configurato per ls, senza Finestre essere nell'immagine affatto .

L'unica cosa che fa Windows è mostrare chiaramente cosa sta succedendo qui. Il tuo programma FTP di Windows sta prendendo i byte nei nomi dei file e li visualizza come punti di codice rilevanti nella tabella codici 1252. Questa, una codifica a byte singolo con quasi tutto sopra 0x1F un glifo stampabile, ci dice esattamente quali sono i byte nei tuoi nomi di file .

Il tuo secondo nome è in gran parte non informativo, ma il primo e il terzo lo dicono.

• Il primo nome file è la sequenza di byte 63 61 66 c3 a9 2d 32 2e 70 6e 67. Nella tabella codici 1252 è café-2.png. È anche la codifica UTF-8 di café-2.png.
• Il terzo nome file è la sequenza di byte 63 61 66 e9 2e 70 6e 67. Nella tabella codici 1252 questo è café.png. Tuttavia, non è una codifica UTF-8 valida. e9inizia una sequenza di codifica dei caratteri incompleta.

Quindi quello che sta succedendo è che le cose non stanno usando la code page 1252 ma che stanno usando UTF-8, vale a dire la tua sessione SSH e il tuo emulatore di terminale locale, stanno gestendo l' UTF-8 valido allo stesso modo l'uno dell'altro ma stanno gestendo l' invalido UTF-8 in due modi diversi:

• Quello che sta visualizzando il grafico a blocchi molto probabilmente sta semplicemente usando quel grafico a blocchi come carattere di output di sostituzione generale per sequenze UTF-8 non valide.
• Quello che sta visualizzando la lettera ésta tornando alla pagina di codice 1252 quando incontra una codifica non valida.

Il tuo problema di fondo è un sistema che in qualche modo sta generando alcuni nomi di file codificati come UTF-8 e altri nomi di file codificati nel codice pagina 1252.