testdiskLinux의 패키지를 사용하여 exFAT 썸 드라이브에서 손실된 파일을 복구하려고 합니다 . 삭제된 파일을 찾는데 아주 좋습니다. 그런데 항목을 살펴보던 중 이상한 점을 발견했습니다. 이 프로그램은 파일 이름을 읽을 수 없고, 파일 크기가 크며, 타임스탬프가 이상한 수십 개의 기존 파일과 삭제된 파일을 요구합니다.
예를 들어, 한 항목은 79862082558814991bytes 2-Apr-1911및 filenames 을 읽습니다 ,~WM-*'? M-kxfM-'D^^Q謁懫䞭鵣ㄆ冚୩鳼묁쐚쵡૪댷腁濬. 잘못된 항목 이름은 왜곡된 문자, 외국어, 이모티콘입니다. 흥미롭게도 타임스탬프 중 일부는 유닉스 시대 이전입니다.
이러한 이상한 항목은 드라이브 루트에 없습니다. 특정 폴더에만 존재합니다. 영숫자 문자만 포함된 파일도 정상적으로 표시됩니다.
내 질문은 다음과 같습니다
- 이 현상의 이유는 무엇입니까? testdisk가 임의의 남은 바이트를 "삭제된 파일"로 잘못 선택하고 있습니까? 아니면 Windows에서 생성된 일부 파일이 Linux에 적합하지 않습니까?
- Linux와 Windows는 실제로 파일 이름에 대해 서로 다른 인코딩/규칙 세트를 사용합니까? 그렇다면 한 운영 체제에서는 유효하지만 다른 운영 체제에서는 유효하지 않은 이름을 가진 파일이 적대적인 운영 체제로 전송되면 어떻게 될까요? 모든 것이 그렇게 말도 안되는 일로 변했습니까?
ps 모든 파일의 내용은 UTF-8로 인코딩됩니다.
답변1
(1) 파일 클리너/조각가는 한때 파일이었던 것처럼 보이는 패턴을 찾습니다. 이는 정의에 따라 이러한 파일을 더 이상 일반적으로 사용할 수 없기 때문에 필요합니다. 때로는 파일이 아닌 것들이 특정 경험적 방법과 일치하여 이와 같은 오탐지가 발생하는 경우가 있습니다.
(2) 내 경험에 따르면 대부분의 파일 시스템은 사양의 일부로 또는 암시적으로 모든 곳에서 특정 인코딩을 사용합니다.
예를 들어, 많은 초기 파일 시스템에서는 ASCII가 전부였기 때문에 ASCII를 암시했습니다.
NTFS는 유니코드 및 UCS-2 인코딩(16비트 고정 너비 문자)을 지정합니다.
다양한 Linux 확장 파일 시스템이 "암시적"인지 "명시적"인지는 확실하지 않지만 실제로는 유니코드와 UTF-8이거나 아주 오래된 커널에서는 ASCII일 수도 있습니다. 실제 파일 이름은 NUL(0)을 초과하는 해석되지 않은 바이트 시퀀스입니다. 이러한 바이트는 디스플레이 루틴에 의해 문자로 해석됩니다. 이러한 디스플레이 루틴의 대부분은 사용자 공간(예: ls(1)사용 중인 유틸리티 및 터미널 에뮬레이터) 에 있습니다 .
시스템에서 잘못된 문자가 발견되면 시스템은 다른 조치를 취합니다. 매우 일반적인 규칙으로, 역사적으로 Unix 파생 시스템은 이를 작동시키려고 시도했지만/또는 처음에는 이를 알아차리지 못했습니다(잠재적으로 사용자에게 매우 혼란스러운 결과를 초래할 수 있음). 반면 Microsoft 파생 시스템은 알아차렸을 때 이를 수행했습니다. 오류를 반환하거나 그렇지 않으면 이상하게 행동합니다.