Dosya adlarım neden Linux'ta 'normal' görünüyor, ancak Windows'da uzaktan görünmüyor?


11

Bir meslektaşımla çalışırken kodlamayla ilgili görünen garip bir sorun buldum. Biz gibi basit yeterince dosya adlarına sahip bazı görüntülerle çalışıyoruz city.gifya wine.gif, ama bir tahmin edebileceğiniz gibi gibi özel karakterleri kullanırken şeyler daha karmaşık hale geldiğini é, ë, à. Ayrıca bu karakterlere sahip Hollandaca verilerle de çalışıyoruz, örn. café( Pub ). (Dosyaların kökeni üzerinde kontrolümüz yoktur.) Sorunlar burada ortaya çıkmaya başlar. Aşağıdaki dosya adları sadece bir örnektir. Sorun, aksanları olan diğer karakterler için de oluşur.

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

İlk ve son öğenin içinde aksanlı bir e olmalıdır (aksan aigu, é). Linux'ta (CentOS 6 ve 7) bir terminalde çalışırken bu şekilde gösterilir ls. Ama işte Windows geliyor! (Windows 10, 64 bit kullanarak.) Sunucumuzla SSL üzerinden Windows'a bağlandıktan sonra çağrı yaparak lsyukarıdaki liste şöyle görünür:

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

Umarım görebileceğiniz gibi, ilk satır hala aksanlı e'ye sahiptir é , ancak üçüncüsü yoktur. Bunun yerine, unicode (9618 ondalık) olan bu karakteri görüyorum medium shade. Bu kendi içinde garip. Ancak, SFTP üzerinden Filezilla ile bağlandığımda (hala Windows'ta) bunu görüyorum:

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

Şimdi işler tersine döndü: birincisinde é, diziye dönüştü ve üçüncüsünde her şey yolunda. Buldum burada <-> doğru tahmin ediyorum eğer yanlış gitti UTF-8 dönüşüm bunun nedeni bir Latin-1 olasılığı en yüksek olduğu. Ama olan tek şey bu olamaz, değil mi?

Linux her şeyi beklediğimiz gibi gösterir, Windows dosya adını (SSH (macun) veya SFTP (dosyazilla)) görüntüleme şeklimize bağlı olarak görünüşte tutarsız davranış gösterir. Bu dosya adlarını 'normalleştirmek' - yani düzenlemek - ve her işletim sisteminde aynı olduklarından emin olmak için bir yol var mı; ya da en azından tutarlı ve eğer öyleyse, nasıl? UTF-8bizim kodlama seçimimizdir.

Bu sadece estetik bir mesele olsa da, öyle değil. Linux sunucumuzdan Windows'ta SFTP aracılığıyla bir şey indirmeye çalışırken, yukarıda belirtilen sorunu içeren dosyaları indiremiyorum. Filezilla gibi bir hata atar Can't download file café-2.png: café-2.png does not exist on the server. Bana öyle geliyor ki Filezilla dizini ve dosya adını okuyor, bazı kodlamalarda yorumluyor, yorumuyla sunucuya bir GET isteği gönderiyor, ancak bu yorum Linux dosya adından farklı olduğu için dosya bulunamadı.

Sonuç olarak, bunun neden olduğu ile ilgilenmeme rağmen, mevcut bir çözüm varsa iyi olurdu . Görüntü dosyaları muhtemelen farklı İşletim Sistemlerinde oluşturulduğu için mi meydana geliyor? Linux sunucusu bunları yanlış yorumladığı için mi yoksa Windows karışıyor mu? Umarım sadece sysadmin'imizle iletişime geçip sunucu yapılandırmasında bir anahtarı açmasını isteyebileceğimiz bir çözüm var, ancak korkarım ki bu kadar kolay değil.


1
Bu istemci (PuTTY, vb.) Ve yapılandırmalarıyla ilgilidir ve Windows ile ilgili değildir. PuTTY için bu çeviri bölümünde yapılır .
Thomas Dickey

2
"Café-2.png" içindeki é UTF-8 kodlu, ancak "café.png" içindeki é ISO-8859-1 kodlu gibi görünüyor. Eğer çalışabilir python -c "import sys; print(repr(sys.argv[1]))" café-2.pngve python -c "import sys; print(repr(sys.argv[1]))" café.png?
Oskar Skog

@ OskarSkog Bunu sabah deneyeceğim. Ama her zaman dosya adlarının bir kodlamaya sahip olmadığını, yani işletim sisteminin istediği gibi olmadığını düşündüm. Bu, farklı dosyaların farklı işletim sistemlerinde oluşturulduğu anlamına mı gelir? (Dosyaların kökeni üzerinde kontrolümüz yoktur.)
Bram Vanroy

Unix gibi işletim sistemlerinde, dosya adı sadece bir bayt dizisidir. Karakter kavramı daha yüksek bir seviyeye gelir.
Oskar Skog

1
Bir cevaba ya da bir çözüme bile yakın değil, sadece peşinde koşmak için bir düşünce. OP'den, dosyaların kaynak tarafından oluşturulan ad üzerinde hiçbir kontrolü olmayan çeşitli kökenleri olabileceği ve gelen dosya adı snafusunu düzeltmek için filtreleri uygulamak için çok geç olduğu görülüyor. Çözüm, muhtemelen sunucuda dosya adı hatalarını algılayabilen ve düzeltebilen, hatta adlar için kullanılan karakter kümesi / kod sayfasını standartlaştıran bir komut dosyası çalıştırmayı içerir. Daha sonra OP, Filezilla veya diğer istemcilerde aynı kod sayfasını kullanabilir ve işler işe yarayacaktır. Yeteneklerimin ötesinde, ama takip edilmesi gereken bir yol, belki.
user207673

Yanıtlar:


11

Ama işte Windows geliyor!

Windows'un bununla hiçbir ilgisi yoktur. Sen uygun şekilde seçilmiş terminali kodlama ve uygun şekilde yapılandırılmış yerel ile, (diyelim) GNOME Terminal yerel bir örneği ile aynı kesin davranışı yeniden olabilir lsherhangi bir Windows resimde olmadan hiç .

Windows'un yaptığı tek şey, burada neler olduğunu açıkça göstermektir. Windows FTP programınız dosya adlarındaki baytları alıyor ve bunları 1252 kod sayfasındaki ilgili kod noktaları olarak görüntülüyor. Bu, yazdırılabilir bir glifin 0x1F üzerindeki hemen hemen her şeyi içeren tek baytlık bir kodlama, dosya adlarınızdaki baytların tam olarak ne olduğunu bize söylüyor .

İkinci dosya adınız büyük ölçüde bilgi vermez, ancak birinci ve üçüncü dosya adınız söylenir.

  • İlk dosya adı bayt dizisidir 63 61 66 c3 a9 2d 32 2e 70 6e 67- Kod sayfası 1252'de bu café-2.png. Ayrıca UTF-8 kodlamasıdır café-2.png.
  • Üçüncü dosya adı bayt dizisidir 63 61 66 e9 2e 70 6e 67- Kod sayfası 1252'de bu café.png. Ancak, geçerli bir UTF-8 kodlaması değildir. e9tamamlanmamış bir karakter kodlama dizisi başlatır.

Peki oluyor şeyler vardır olmasıdır değil , 1252 kullanarak ancak UTF-8, yani SSH oturum ve yerel terminal emülatörü kullandığınızdan emin, kullanımı vardır geçerli birbirlerine aynı şekilde UTF-8 ama kullanımı vardır geçersiz UTF-8 iki farklı şekilde:

  • Blok grafiğini görüntüleyen, büyük olasılıkla bu blok grafiğini geçersiz UTF-8 dizileri için genel yedek çıkış karakteri olarak kullanmaktadır .
  • Mektubu görüntüleyen ékod geçersiz bir kodlama ile karşılaştığında Kod'a geri döner.

Temeldeki sorununuz, bir şekilde UTF-8 olarak kodlanmış bazı dosya adları ve Kod'da kodlanmış diğer dosya adları üreten bir sistemdir.


Windows'un bununla hiçbir ilgisi olmadığını kabul etmiyorum. Muhtemelen diğer Linux'ta olmazdı. Sorun varsayılan kodlamadır ve afaik Windows, UTF'yi değil CP'lerini kullandı (veya en azından kullanmış), bu da bu sorunun ülkeler arasında aynı işletim sisteminde bile olmasına neden oldu. Bunu Linux'ta çoğaltabilirsiniz, ancak Unicode'u seçmede Linux daha tutarlı
MatthewRock

Merhaba! Ayrıntılı cevap için teşekkürler. Neler olduğuna odaklanıyorsunuz, ki bu güzel: Neler olduğunu anlamaktan hep hoşlanıyorum. Ama belki de bunun neden olduğuna ve bu tutarsızlıktan sonra gelen sorunlara nasıl karşı koyabileceğimize ışık tutabilir misiniz? Ne demek istediğimi açıklığa kavuşturmak için iki paragraf ekledim.
Bram Vanroy

Acaba her iki "kafe" de neden aynı değiller? GNU ls (1) gülünç kodlama hatası işleme var mı?
Oskar Skog

@MatthewRock Bu durumda Windows'un gerçekten onunla hiçbir ilgisi olmadığını düşünüyorum. M $ 'ın yaptığı şeylerin çoğundan memnun değilim ve kötülüklerinin çoğunu isteyerek kabul ediyorum, ancak hiçbir şeyin zamanı gelmediği halde suçlama göremiyorum. Cevap basitleştikçe, sorun isimlerin kendilerinin bayt değerleri ile ilgilidir. Bu durumda, Windows belirtiyi ortaya çıkardı, ancak sorun değil. Ateşinizin 104 ° olduğunu gösterdiğinde, termometreden daha fazla sorun yoktur. Sorun, OP'de erişmeye çalıştığı dosyaları içeren sunucuda adları oluşturan tüm işlemlerden kaynaklanır.
user207673

Daha fazla bilgi ve olası çözümler sağlayabilir misiniz? Aksi takdirde ödülümü hiçbir şey için harcadım.
Bram Vanroy
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.