Mengapa nama file saya terlihat 'normal' di Linux tetapi tidak jauh dari Windows?

Saat bekerja dengan seorang kolega saya menemukan masalah aneh yang tampaknya terkait dengan penyandian. Kami bekerja dengan beberapa gambar yang memiliki nama file yang cukup sederhana seperti city.gifatau wine.gif, tetapi seperti yang diharapkan hal mendapatkan lebih rumit ketika menggunakan karakter khusus seperti é, ë, à. Kami juga bekerja dengan data Belanda yang memiliki karakter ini, misalnya café( pub ). (Kami tidak memiliki kontrol atas asal file.) Di sinilah masalah mulai muncul. Nama file berikut hanyalah sebuah contoh. Masalah ini juga terjadi untuk karakter lain dengan diakritik.

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

Item pertama dan terakhir harus memiliki aksen e di sana (aksen aigu, é). Begitulah yang ditunjukkan di Linux (CentOS 6 & 7) di terminal saat berjalan ls. Tapi inilah Windows! (Menggunakan Windows 10, 64 bit.) Ketika terhubung pada Windows melalui SSL dengan server kami dan kemudian memanggil ls, daftar di atas terlihat seperti ini:

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

Seperti yang mudah-mudahan Anda lihat, baris pertama masih memiliki aksen e é , tetapi yang ketiga tidak. Sebagai gantinya, saya melihat ▒karakter ini - yang berada medium shadedalam unicode (9618 desimal). Ini aneh dalam dirinya sendiri. Namun, ketika saya terhubung melalui SFTP dengan Filezilla (masih di Windows) saya bisa melihat ini:

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

Jadi sekarang segalanya telah berbalik: yang pertama ételah berubah menjadi urutan dan yang ketiga semuanya baik-baik saja. Saya menemukan di sini bahwa ini kemungkinan besar karena konversi Latin-1 <-> UTF-8 yang salah, jika saya melakukannya dengan benar. Tapi itu tidak semua yang terjadi, bukan?

Linux menunjukkan segalanya seperti yang kita harapkan, Windows menunjukkan perilaku yang tampaknya tidak konsisten tergantung pada cara kita melihat nama file (SSH (dempul), atau SFTP (filezilla)). Apakah ada cara untuk 'menormalkan' nama-nama file ini - yaitu mengeditnya -, dan memastikan semuanya sama pada setiap OS; atau paling tidak konsisten, dan jika demikian, bagaimana? UTF-8adalah pengkodean pilihan kami.

Meskipun ini mungkin sama hanya masalah estetika, itu tidak sama. Ketika mencoba mengunduh berbagai hal melalui SFTP di Windows dari server Linux kami, saya tidak dapat mengunduh file yang memiliki masalah yang disebutkan di atas. Filezilla akan melempar kesalahan seperti Can't download file café-2.png: café-2.png does not exist on the server. Yang menurut saya Filezilla membaca direktori dan nama file, menafsirkannya dalam beberapa pengkodean, mengirimkan permintaan GET ke server dengan interpretasinya, tetapi interpretasi itu berbeda dari nama file Linux sehingga akibatnya file tidak ditemukan.

Pada akhirnya akan lebih baik jika ada solusi yang tersedia, meskipun saya juga tertarik mengapa ini terjadi. Apakah ini terjadi karena file gambar mungkin dibuat pada Sistem Operasi yang berbeda? Apakah ini terjadi karena server Linux mengartikan mereka salah, atau apakah Windows mengacaukannya? Mudah-mudahan ada solusi di mana kita bisa langsung menghubungi sysadmin kita dan meminta mereka untuk menghidupkan sakelar di server konfigurasi, tapi aku khawatir itu tidak semudah itu.

Tapi inilah Windows!

Windows tidak ada hubungannya dengan ini. Anda bisa mereproduksi perilaku yang tepat ini sama dengan contoh lokal (katakanlah) GNOME Terminal, dengan pengkodean terminal yang dipilih secara tepat dan tepat dikonfigurasi lokal untuk ls, tanpa setiap Windows berada di gambar sama sekali .

Satu-satunya hal yang dilakukan Windows jelas menunjukkan apa yang terjadi di sini. Program Windows FTP Anda mengambil byte dalam nama file dan menampilkannya sebagai titik kode yang relevan dalam kode halaman 1252. Ini, pengkodean satu-byte dengan hampir semua yang di atas 0x1F mesin terbang yang dapat dicetak, memberi tahu kami persis apa byte dalam nama file Anda .

Nama file Anda yang kedua sebagian besar tidak informatif, tetapi yang pertama dan ketiga memberi tahu.

• Nama file pertama adalah urutan byte 63 61 66 c3 a9 2d 32 2e 70 6e 67- Dalam kode halaman 1252 ini café-2.png. Ini juga merupakan pengkodean UTF-8 dari café-2.png.
• Nama file ketiga adalah urutan byte 63 61 66 e9 2e 70 6e 67- Dalam kode halaman 1252 ini café.png. Namun, ini bukan pengkodean UTF-8 yang valid. e9memulai urutan penyandian karakter yang tidak lengkap.

Jadi yang terjadi adalah bahwa hal-hal tersebut tidak menggunakan kode halaman 1252 tetapi yang menggunakan UTF-8, yaitu sesi SSH Anda dan emulator terminal lokal Anda, menangani UTF-8 yang valid dengan cara yang sama satu sama lain tetapi sedang menangani yang tidak valid UTF-8 dalam dua cara yang berbeda:

• Yang menampilkan grafik blok sangat mungkin hanya menggunakan grafik blok itu sebagai karakter output pengganti umum untuk urutan UTF-8 yang tidak valid.
• Yang menampilkan surat éjatuh kembali ke Kode 1252 ketika menemukan penyandian yang tidak valid.

Masalah mendasar Anda adalah sistem yang entah bagaimana menghasilkan beberapa nama file yang dikodekan sebagai UTF-8 dan nama file lain yang dikodekan dalam Kode Page 1252.