☰

내 파일 이름이 Linux에서는 "정상"으로 보이지만 Windows에서는 원격으로 보이지 않는 이유는 무엇입니까?

tag-icon • tag-icon windows filenames character-encoding
내 파일 이름이 Linux에서는 "정상"으로 보이지만 Windows에서는 원격으로 보이지 않는 이유는 무엇입니까?

동료와 함께 작업하던 중 인코딩과 관련된 것으로 보이는 이상한 문제를 발견했습니다. 우리는 충분히 간단한 파일 이름(예: 또는 )을 가진 일부 city.gif이미지를 다루고 있지만 wine.gif예상대로 특수 문자(예: é, , )를 사용하면 ë상황이 더 복잡해집니다 à. 또한 이러한 문자가 포함된 네덜란드어 데이터도 처리하고 있습니다. 예를 들면 café(술집). (우리는 파일의 출처를 통제할 수 없습니다.) 여기서 문제가 발생하기 시작합니다. 다음 파일 이름은 단지 예일 뿐입니다. 이 문제는 분음 부호가 있는 다른 문자에서도 발생합니다.

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

첫 번째 항목과 마지막 항목에는 악센트가 있어야 합니다.이자형거기 (악센트 aigu, é). Linux(CentOS 6 및 7) 런타임이 터미널에 나타나는 방식입니다 ls. 하지만 윈도우가 온다! (Windows 10, 64비트 사용) Windows에서 SSL을 통해 서버에 연결한 후 호출하면 ls위 목록은 다음과 같습니다.

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

예상한 대로 첫 번째 줄에는 여전히 악센트가 있습니다.이자형 é, 그러나 세 번째는 아닙니다. 대신 이 문자가 보입니다 ▒. 유니코드(10진수 9618)입니다 medium shade. 이것은 그 자체로 이상합니다. 그러나 Filezilla(여전히 Windows에서)를 사용하여 SFTP를 통해 연결하면 다음이 표시됩니다.

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

이제 상황이 반전되었습니다. 첫 번째에서는 é순서가 변경되었고 세 번째에서는 모든 것이 정상입니다. 내가 찾은여기내 말이 맞다면 이는 Latin-1 <-> UTF-8 변환이 잘못되었기 때문일 가능성이 높습니다. 하지만 그게 전부일 수는 없잖아요?

Linux는 우리가 기대했던 모든 것을 보여줬고, Windows는 파일 이름(SSH(putty) 또는 SFTP(filezilla))을 보는 방식에 따라 일관되지 않은 것처럼 보이는 동작을 보여주었습니다. 이러한 파일 이름을 "표준화"(즉, 편집)하고 모든 운영 체제에서 동일하거나 최소한 일관성을 유지하는 방법이 있습니까? 그렇다면 어떻게 해야 합니까? 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가 문제를 일으키고 있습니까? 시스템 관리자에게 연락하여 서버 구성의 스위치를 켜도록 요청할 수 있는 솔루션이 있기를 바라지만, 그렇게 쉽지는 않습니다.

답변1

하지만 윈도우가 온다!

Windows는 이와 관련이 없습니다. 예를 들어 ls그림에 Windows가 없어도 적절하게 선택된 터미널 인코딩과 적절하게 구성된 로케일을 사용하여 GNOME 터미널의 로컬 인스턴스를 사용하여 동일한 동작을 재현할 수 있습니다.별말씀을요.

Windows가 수행하는 유일한 작업은 여기서 무슨 일이 일어나고 있는지 명확하게 보여주는 것입니다. Windows FTP 프로그램은 파일 이름의 바이트를 가져와 코드 페이지 1252의 관련 코드 포인트로 표시합니다. 이는 0x1F(인쇄 가능한 문자) 위의 거의 모든 것을 포함하는 단일 바이트 인코딩으로, 파일 이름에 정확히 어떤 바이트가 있는지 알려줍니다.

두 번째 파일 이름은 기본적으로 정보를 제공하지 않지만 첫 번째와 세 번째 파일 이름은 매우 의미가 있습니다.

  • 첫 번째 파일 이름은 일련의 바이트입니다 63 61 66 c3 a9 2d 32 2e 70 6e 67. 이는 코드 페이지 1252입니다. café-2.png또한 UTF-8로 인코딩됩니다 café-2.png.
  • 세 번째 파일 이름은 일련의 바이트입니다 63 61 66 e9 2e 70 6e 67(코드 페이지 1252) café.png. 그러나 이는 유효한 UTF-8 인코딩이 아닙니다. e9불완전한 문자 인코딩 시퀀스를 시작합니다.

그래서 지금 무슨 일이 일어나고 있는지아니요코드 페이지 1252를 사용하지만 UTF-8을 사용하면 SSH 세션과 로컬 터미널 에뮬레이터가 처리하는 것입니다.효과적인UTF-8은 서로 동일한 방식으로 처리되지만유효하지 않은UTF-8은 두 가지 방식으로 제공됩니다.

  • 블록 그래픽을 표시하는 사람은 단순히 블록 그래픽을 일반 그래픽으로 사용하고 있을 가능성이 높습니다.출력 문자 바꾸기잘못된 UTF-8 시퀀스의 경우.
  • 이 문자를 표시하는 코드에서 é잘못된 인코딩이 발견되면 코드 페이지 1252로 대체됩니다.

근본적인 문제는 시스템이 UTF-8로 인코딩된 일부 파일 이름과 코드 페이지 1252로 인코딩된 파일 이름을 생성한다는 것입니다.

관련 정보