일부 파일이 잘못된 모드에서 명령줄을 통해 FTP에 업로드되었습니다. TEXT 모드로 업로드된 일부 바이너리 파일이 있는데 지금은 열 수 없습니다.
원본 파일에 액세스할 수 없습니다. 어떻게든 복구할 수 있나요? 파일을 올바른 형식으로 가져올 수 있는 도구가 있습니까?
답변1
나는 최근에 같은 문제에 직면해야했습니다. 리눅스 -> 윈도우, ASCII 모드. 나는 ASCII 전송 바이너리를 복구할 수 있는 Python 프로그램 작성을 마쳤습니다. 이는 바이트 무차별 공격이며 작동 방식은 다음과 같습니다.
- 손상된 아카이브를 바이트 스트림으로 엽니다.
- 0d 뒤에 0a가 오는 모든 항목을 찾습니다(ASCII 13, ASCII 10).
- 0d 다음에 0a가 오는 모든 항목을 제거하고 바이트 주소를 저장합니다.
- 각 주소를 순환하여 바이너리에 있어야 하는 경우 여러 0d를 복원하고 복원하고 열려고 시도합니다(제 경우에는 bz2 아카이브를 다루고 CRC 체크섬 알고리즘을 사용하여 무결성을 확인했습니다). 압축되지 않은 데이터를 찾아 아카이브에 하드코딩된 데이터와 일치시킵니다.)
바이너리에서 가능한 유효한 0d 0a 바이트 쌍의 수는 그리 높지 않습니다. 유효한 0d 0a 쌍을 갖는 바이너리의 확률은 매우 낮습니다. bz2 아카이브가 이 무차별 대입 방법으로 문제를 해결하는 데 걸리는 시간은 100kb 미만 파일의 경우 10초 미만입니다. 다른 형식의 파일로는 확인해보지 않았지만 가능합니다.
이 질문은 프로그래밍과 관련이 없고 일종의 경쟁 작업이므로 여기에 코드를 붙여넣지 않을 것입니다. 소스를 공개하는 것이 불편할 것 같지만 필요하다면 요청해 주세요. 알려줘요.
모두들 즐거운 크리스마스 보내세요! :)
답변2
파괴를 취소할 수 있는지 여부를 알려면 관련 운영 체제를 알아야 합니다. 결과는 서버와 클라이언트에서 사용하는 운영 체제 조합에 따라 달라집니다.
최악의 문제는 줄 끝 문자입니다. Windows에서는 캐리지 리턴(ASCII 값 13)과 줄 바꿈(ASCII 값 10)을 사용하는 반면 Linux는 줄 바꿈만 사용합니다.
텍스트 모드 FTP 전송은 이를 번역합니다. 바이너리 모드는 그렇지 않습니다. 파괴가 일어나는 곳입니다.
Windows에서 Linux로 전송이 진행된 경우 LF가 원래 LF인지 아니면 CR-LF의 조합인지 확인하는 것이 불가능합니다. 데이터가 손실되면 파괴를 취소하는 것은 거의 불가능합니다.
답변3
다른 사람들이 지적한 것처럼 데이터가 손상되어 잠재적으로 복구할 수 없습니다.
그러나 0x0D 0x0A는 대부분의 바이너리 파일 형식에서 특히 일반적인 바이트 시퀀스가 아니므로 [인용 필요!] 이를 교체하여 파일이 수정되는지 확인하는 것이 좋습니다.
그만큼fixgz 유틸리티바로 그런 일을 합니다. 이름에도 불구하고 .gzip 파일과 관련된 내용이 없으며 모든 파일에서 사용할 수 있습니다.
행운을 빌어요!