동료와 일하면서 인코딩과 관련된 이상한 문제가 발견되었습니다. 우리는 다음과 같은 간단한 충분한 파일 이름이 일부 이미지로 작업 city.gif또는 wine.gif하지만, 하나는 예상대로 같은 특수 문자를 사용할 때 일을 더 복잡하게 é, ë, à. 또한 café( pub ) 와 같은 문자가 포함 된 네덜란드 데이터를 사용하고 있습니다. (파일의 출처를 제어 할 수는 없습니다.) 여기서 문제가 발생하기 시작합니다. 다음 파일 이름은 예일뿐입니다. 분음 부호가있는 다른 문자에도이 문제가 발생합니다.
café-2.png
cafetaria.png
café.png
첫 번째 항목과 마지막 항목에는 악센트가있는 e 가 있어야합니다 (액센트 aigu, é). 이것이 실행 중 터미널의 Linux (CentOS 6 & 7)에 표시되는 방식 ls입니다. 그러나 여기에 Windows가 온다! (Windows 10, 64 비트 사용) 서버에서 SSL을 통해 Windows에 연결 한 다음을 호출 ls하면 위의 목록은 다음과 같습니다.
café-2.png
cafetaria.png
caf▒.png
잘 아시다시피, 첫 번째 줄에는 여전히 악센트가있는 e é 가 있지만 세 번째 줄에는 그렇지 않습니다. 대신 유니 코드 (십진수 9618) 인 ▒이 문자를 봅니다 medium shade. 이것은 그 자체로 이상합니다. 그러나 Filezilla로 SFTP를 통해 연결할 때 (여전히 Windows에서는)이를 볼 수 있습니다.
café-2.png
cafetaria.png
café.png
이제 상황이 바뀌 었습니다. 첫 번째 é는 시퀀스로 바뀌었고 세 번째는 모든 것이 정상입니다. 나는 이것이 올바르게된다면 잘못 된 라틴 -1 <-> UTF-8 변환으로 인한 것임을 여기 에서 발견 했다 . 하지만 그게 전부가 아닐 수도 있습니다.
리눅스는 예상대로 모든 것을 보여주고, 윈도우는 파일 이름을 보는 방식 (SSH (putty) 또는 SFTP (filezilla))에 따라 일관성이없는 것처럼 보입니다. 이러한 파일 이름을 '정상화'(즉, 편집)하는 방법이 있습니까? 모든 OS에서 파일 이름이 모두 같은지 확인하십시오. 또는 최소한 일관성이 있다면 어떻게해야합니까? UTF-8우리가 선택한 인코딩입니다.
이것은 단지 미학적 문제와 동일 할 수 있지만 그렇지 않습니다. Linux 서버에서 Windows의 SFTP를 통해 다운로드하려고 할 때 위에서 언급 한 문제가있는 파일을 다운로드 할 수 없습니다. Filezilla는와 같은 오류를 발생시킵니다 Can't download file café-2.png: café-2.png does not exist on the server. Filezilla는 디렉토리와 파일 이름을 읽고 일부 인코딩으로 해석하고 해석을 통해 서버에 GET 요청을 보내지 만 해석은 Linux 파일 이름과 다르므로 결과적으로 파일을 찾을 수 없습니다.
궁극적으로 이것이 가능한 이유에 관심이 있지만 사용 가능한 솔루션이 있다면 좋을 것 입니다. 이미지 파일이 다른 운영 체제에서 생성 되었기 때문에 발생합니까? Linux 서버가이를 잘못 해석하거나 Windows가 엉망이기 때문에 발생합니까? 바라건대 sysadmin에 연락하여 서버 설정에서 스위치를 켜도록 요청할 수있는 솔루션이 있지만 그렇게 쉽지는 않습니다.
python -c "import sys; print(repr(sys.argv[1]))" café-2.png와 python -c "import sys; print(repr(sys.argv[1]))" café.png?