동료로부터 tar 아카이브를 받았고 압축을 푼 후 일부 텍스트 파일이 손상되었음을 발견했습니다. 보다 정확하게는 0으로 채워집니다. 크기는 정확하지만 모든 바이트는 0x00과 같습니다.
이러한 상황은 tar 버전의 일부 비호환성 때문입니까? 파일에 중국어 문자가 포함되어 있거나 압축 중에 파일이 손상되었습니까? 컨트롤 체크섬이 양호하므로 전송 중에 어떤 문제도 예상되지 않습니다.
답변1
확실합니까모두바이트는 0x00? 이 경우 파일에는 크기를 제외한 정보가 전혀 포함되어 있지 않습니다. 어떤 프로그램도 정보를 모두 0으로 저장하거나 전송할 수 없습니다(텔레파시가 아닌 이상).
무엇할 수 있는파일에 텍스트와 0바이트가 교대로 들어 있는 경우가 발생합니다. 의미: UTF-16(또는 이와 유사한 값)으로 인코딩된 유니코드 텍스트가 포함된 파일을 받았습니다. 각 문자는 16비트(2바이트)를 차지합니다. 유니코드는 ASCII 문자 코드에 영어 문자와 기호를 할당합니다. 즉, 예를 들어 문자는 AASCII에서는 16진수 41이고 유니코드에서는 00 41입니다. 결과적으로 "Hello"를 UTF-16으로 작성하고 이를 8비트 텍스트로 읽으면 다음이 표시됩니다.
\0 H \0 e \0 l \0 l \0 o
그렇다면 그것은 당신의 잘못이 아닙니다 tar. 그러나 체크섬 검사를 통해 모두 0인 파일을 받았다면 작성자에게 문제가 있는 것이 분명합니다. 버전 문제는 아니지만 누가 알겠습니까? 생성기가 모두 0을 읽게 만드는 하드웨어 문제가 있을 수 있습니다.
(물론 파일이 제대로 보관되어 프로그램에 버그가 존재하는 경우도 있을 수 있습니다.만들어진아카이브 파일).
답변2
가장 가능성이 높은 문제는 tar가 생성될 때 손상되었다는 것입니다. tar 형식이 정의된 방식으로 인해(스트리밍 아카이버로 사용되기 때문에) 파일 길이를 미리 결정해야 합니다. 이 길이를 tar 헤더에 기록한 다음 파일 내용을 tar 파일에 쓰기 시작합니다. 어떤 이유로 파일을 읽는 동안 오류가 발생하거나 보관할 때 파일이 축소되면 NULL이 채워집니다. 이는 추출 시 헤더에 지정된 길이가 여전히 유효하도록 하기 위해 필요합니다. (스트리밍 특성으로 인해 헤더를 다시 수정할 수 없으며 파일을 NULL로 채우지 않으면 에서 오류가 발생합니다.) 아카이브의 다음 파일).
또한 tar는 이진 데이터를 처리하므로("텍스트" 모드가 없음) 다른 언어 인코딩에 문제가 없어야 합니다(tar에 관한 한).