Podczas pracy z kolegą znalazłem dziwny problem, który wydaje się związany z kodowaniem. Pracujemy z niektórych obrazów, które mają dość proste nazwy plików, takich jak city.gif
czy wine.gif
, ale jak można się spodziewać rzeczy uzyskać bardziej skomplikowane przy użyciu znaków specjalnych, takich jak é
, ë
, à
. Pracujemy również z danymi holenderskimi, które mają te znaki, np. café
( Pub ). (Nie mamy kontroli nad pochodzeniem plików.) Tutaj zaczynają się pojawiać problemy. Następujące nazwy plików są tylko przykładem. Problem występuje również w przypadku innych znaków z znakami diakrytycznymi.
café-2.png
cafetaria.png
café.png
Pierwszy i ostatni element powinien mieć akcentowane e (accent aigu, é
). Tak to pokazano w Linuksie (CentOS 6 i 7) w terminalu podczas działania ls
. Ale nadchodzi Windows! (W systemie Windows 10, wersja 64-bitowa). Po połączeniu w systemie Windows za pomocą protokołu SSL z naszym serwerem, a następnie wywołaniu ls
, powyższa lista wygląda następująco:
café-2.png
cafetaria.png
caf▒.png
Jak widać, pierwsza linia nadal ma akcentowane e é
, ale trzecia nie. Zamiast tego widzę ▒
ten znak - który jest medium shade
w standardzie Unicode (dziesiętnie 9618). To samo w sobie dziwne. Kiedy jednak łączę się przez SFTP z Filezillą (wciąż w systemie Windows), widzę to:
café-2.png
cafetaria.png
café.png
Więc teraz wszystko się zmieniło: w pierwszym é
zmieniło się w sekwencję, w trzecim wszystko jest w porządku. Odkryłem tutaj, że najprawdopodobniej jest to spowodowane konwersją Latin-1 <-> UTF-8, która poszła nie tak, jeśli dobrze to zrobię. Ale to nie wszystko, co się dzieje, prawda?
Linux pokazuje wszystko tak, jak się spodziewaliśmy, Windows wydaje się pozornie niespójnym zachowaniem w zależności od sposobu, w jaki patrzymy na nazwę pliku (SSH (kit) lub SFTP (filezilla)). Czy istnieje sposób na „znormalizowanie” tych nazw plików - tj. Ich edycję - i upewnienie się, że wszystkie są takie same w każdym systemie operacyjnym; a przynajmniej spójne, a jeśli tak, to w jaki sposób? UTF-8
jest naszym kodowaniem z wyboru.
Chociaż może to być tylko kwestia estetyczna, tak nie jest. Podczas próby pobrania rzeczy za pośrednictwem SFTP w systemie Windows z naszego serwera Linux nie mogę pobrać plików, których dotyczy problem wspomniany powyżej. Filezilla zgłosi błąd, taki jak Can't download file café-2.png: café-2.png does not exist on the server
. Co wydaje mi się, że Filezilla odczytuje katalog i nazwę pliku, interpretuje je w pewnym kodowaniu, wysyła żądanie GET do serwera z jego interpretacją, ale ta interpretacja różni się od nazwy pliku Linux, więc plik nie został znaleziony.
Ostatecznie byłoby miło, gdyby było dostępne rozwiązanie, chociaż jestem również zainteresowany tym, dlaczego tak się dzieje. Czy to się dzieje, ponieważ pliki obrazów zostały prawdopodobnie utworzone w różnych systemach operacyjnych? Czy to się dzieje, ponieważ serwer Linux źle je interpretuje, czy system Windows się psuje? Mamy nadzieję, że istnieje rozwiązanie, w którym możemy po prostu skontaktować się z naszym sysadminem i poprosić go o włączenie przełącznika w konfiguracji serwera, ale obawiam się, że nie jest to takie proste.
źródło
python -c "import sys; print(repr(sys.argv[1]))" café-2.png
ipython -c "import sys; print(repr(sys.argv[1]))" café.png
?Odpowiedzi:
Windows nie ma z tym nic wspólnego. Można odtworzyć ten sam dokładnie zachowanie z lokalnej instancji (powiedzmy) gnome-terminal, z odpowiednio dobranym kodowania terminala i odpowiednio skonfigurowanym dla lokalizacji
ls
, bez systemu Windows jest na zdjęciu w ogóle .Jedyną rzeczą, którą robi Windows, jest jasne pokazanie, co się tutaj dzieje. Twój program FTP dla systemu Windows pobiera bajty z nazw plików i wyświetla je jako odpowiednie punkty kodowe na stronie kodowej 1252. To jednobajtowe kodowanie z prawie wszystkim powyżej 0x1F glifu do wydrukowania mówi nam dokładnie, jakie bajty w nazwach plików są .
Druga nazwa pliku jest w dużej mierze pozbawiona informacji, ale pierwsza i trzecia mówią.
63
61
66
c3
a9
2d
32
2e
70
6e
67
- na stronie kodowej 1252 jest tocafé-2.png
. Jest to również kodowanie UTF-8café-2.png
.63
61
66
e9
2e
70
6e
67
- na stronie kodowej 1252 jest tocafé.png
. Nie jest to jednak prawidłowe kodowanie UTF-8.e9
rozpoczyna niekompletną sekwencję kodowania znaków.Tak więc dzieje się tak, że rzeczy nie używają strony kodowej 1252, ale używają UTF-8, a mianowicie sesji SSH i lokalnego emulatora terminala, obsługują poprawny UTF-8 w taki sam sposób, ale obsługują nieprawidłowy UTF-8 na dwa różne sposoby:
é
wraca do kodu Page 1252, gdy napotka nieprawidłowe kodowanie.Twoim podstawowym problemem jest system, który w jakiś sposób generuje niektóre nazwy plików zakodowane jako UTF-8 i inne nazwy plików zakodowane w Kodzie Strona 1252.
źródło