tr은 "잘못된 바이트 시퀀스"에 대해 불평합니다


24

저는 유닉스를 처음 접했고 Kirk McElhearn의 "Mac OS X Command Line"을 사용하여 몇 가지 명령을 가르쳐 왔습니다.

내가 사용하려고 시도하고 tr하고 grep그래서 나는 정기적으로 MS 오피스 워드 문서에서 텍스트 문자열을 검색 할 수 있습니다.

$ tr '\r' '\n' < target-file | grep search-string

그러나 반환되는 것은 다음과 같습니다.

Illegal byte sequence.

robomechanoid:Position-Paper-Final-Draft robertjralph$ tr '\r' '\n' < Position-Paper-Final-Version.docx | grep DeCSS
tr: Illegal byte sequence
robomechanoid:Position-Paper-Final-Draft robertjralph$ 

실제로 만든 스크립트에서 동일한 줄을 실행했으며 vi올바르게 검색합니다.


tr이 왜 불평하는지 알 수 없습니다. 질문에 입력 한 것과 똑같이 입력 했습니까? grep은 원하는 것을 찾지 못합니다. xdoc은 잘못 정의 된 표준입니다. 아무도 그 파일에 무엇이 있는지 알지 못합니다. 사람들은 파일을 리버스 엔지니어링했습니다.
ctrl-alt-delor

답변:


29

grep텍스트 처리 도구입니다. 입력은 텍스트 파일 일 것으로 예상 합니다 . 동일한가는 것 같다 tr맥 OS에 (비록 tr바이너리 파일을 지원하도록되어).

컴퓨터는 바이트 시퀀스로 데이터를 저장 합니다 . 텍스트는 일련의 문자입니다. 문자 인코딩 이라는 문자 를 바이트로 인코딩하는 방법에는 여러 가지가 있습니다 . 대부분의 세계에서, 특히 OSX에서 사실상 표준 문자 인코딩은 UTF-8 이며 이는 유니 코드 문자 세트에 대한 인코딩입니다 . 256 바이트 만 가능하지만 100 만 개 이상의 가능한 유니 코드 문자가 있으므로 대부분의 문자는 여러 바이트로 인코딩됩니다. UTF-8은 가변 길이 인코딩입니다. 문자에 따라 문자를 인코딩하는 데 1-4 바이트가 걸릴 수 있습니다. 일부 바이트 시퀀스는 UTF-8의 문자를 나타내지 않습니다. 따라서 유효한 UTF-8 텍스트 파일이 아닌 일련의 바이트가 있습니다.

tr그런 바이트 시퀀스가 ​​발생했기 때문에 불평하고 있습니다. UTF-8로 인코딩 된 텍스트 파일이 표시되지만 UTF-8이 아닌 2 진 데이터가 표시됩니다.

Microsoft Word 문서는 텍스트 파일이 아니라 워드 프로세싱 문서입니다. 워드 프로세싱 문서 형식은 텍스트뿐만 아니라 서식, 포함 된 이미지 등도 인코딩합니다. 대부분의 워드 프로세싱 형식과 마찬가지로 Word 형식은 텍스트 파일이 아닙니다.

로케일 을 변경하여 텍스트 처리 도구가 바이트에서 작동하도록 지시 할 수 있습니다 . 특히 "C"로케일을 선택하십시오. 기본적으로 "아무것도없는 것"을 의미합니다. 명령 행에서 환경 변수가있는 로케일 설정을 선택할 수 있습니다 .

export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string

이것은 오류를 발생시키지 않지만 target-file여전히 지정할 대부분의 검색 문자열을 포함하지 않는 이진 파일 이기 때문에 유용한 작업을 수행하지 않습니다 .

덧붙여서, tr '\r' '\n'Mac OS 9 또는 그 이전 버전에서 텍스트 파일을 남겨 두지 않으면 매우 유용한 명령이 아닙니다. \r(캐리지 리턴)은 Mac OS X 이전의 Mac OS에서 줄 바꿈 구분 기호였습니다. OSX 이후 줄 바꿈 구분 기호는 \n(줄 바꿈, 유닉스 표준)이며 텍스트 파일에는 캐리지 리턴이 없습니다. Windows는 두 문자 시퀀스 CR-LF를 사용하여 줄 바꿈을 나타냅니다. tr -d '\r'Windows 텍스트 파일을 Unix / Linux / OSX 텍스트 파일로 변환합니다.

명령 줄에서 Word 문서를 어떻게 검색 할 수 있습니까? .docxWord 문서는 사실입니다 압축 아카이브 여러 파일에있는 주요 것들을 포함 된 XML을 .

unzip -l Position-Paper-Final-Version.docx

Mac OS X에는 zip 파일 내부를 검색 하는 zipgrep 유틸리티가 포함되어 있습니다.

zipgrep DeCSS Position-Paper-Final-Version.docx

docx 형식의 XML 파일은 대부분 하나의 거대한 행으로 구성되어 있으므로 결과를 읽을 수 없습니다. 문서의 본문에서 검색 word/document.xml하려면 아카이브 에서 파일 을 추출하십시오 . 이 파일에는 문서 텍스트 외에도 문서 구조를 나타내는 XML 마크 업이 포함되어 있습니다. XML 마크 업을 약간 마사지하여 sed관리 가능한 행으로 분할 할 수 있습니다.

unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS

1
좋은 요약과 추가 비트는 +1입니다. 그래도 할 말이 하나 있습니다. xml을 포맷하려면 데비안 Gnu + Linux의 xml_pp패키지 xml-twig-tools에 들어 있습니다 (Mac을 모르는 경우).
ctrl-alt-delor

2
Mac 용 Excel 2011은 \ r 줄 끝으로 CSV 파일을 저장하므로이 tr 호출은 실제로 관련성이 높고 유용합니다.
노아 Yetter

1
탭으로 구분 된 연락처 목록을 내보낼 때 Mac 용 Outlook 2011과 마찬가지로
Ivan X

1
글쎄, 나는 이것을 억압 할만 큼 평판이 좋지 않지만이 대답은 완전히 틀렸다. " tr[...]로 시작 하면 입력 내용이 텍스트 파일이됩니다."; 반면 , POSIX 규정이 명확하게 진술 "표준 입력 파일의 모든 유형이 될 수 있습니다." . 답을 수정하십시오.
7heo.tk

@ 7heo.tk는 "이 대답은 완전히 잘못된 것입니다"심한 exageration이지만, 맞아요이 tr되는 가정 (공정 널 (null)이 제대로 바이트에 특히,이 해야하는) 바이너리 입력을 처리 할 수 있습니다. POSIX는 일련의 문자가 아닌 입력을 처리하는 방법을 명확하게 지정하지 않습니다. (I는 구현이 있었다면, 내가 수정되지 않은 통해 잘못된 바이트 시퀀스를 전달할 것 (또는 그들을 제거 -s) 표준위원회에 결함 인상은.) 분명히, 맥 OS의 TR 그들에 대해 불평한다.
Gilles 'SO- 악마 그만'

13

로케일의 charmap이 UTF-8이므로 바이너리 파일에 문제가 있다고 가정합니다. C 로케일로 전환하십시오.

LC_ALL=C tr '\r' '\n' < target-file | LC_ALL=C grep search-string

대괄호를 사용하여 언어를 두 번 지정하지 않아도됩니다. LC_ALL=C ( tr '\r' '\n' < target-file | grep search-string ). 그러나 docx는 C 로컬이 아닙니다. utf16이며 압축 및 복잡하고 누구나 추측합니다. html 또는 odt를 처리 할 수있는 다른 형식으로 변환 할 수있는 도구를 사용하는 것처럼 보입니다 (odt도 압축되어 있지만 잘 정의되어 있고 해석하기 쉽습니다).
ctrl-alt-delor

1
대괄호 (괄호)가있는 구문은 모든 셸 (bash가 아닌 zsh가 아닌 대시)에는 작동하지 않습니다. 그런 다음 MS Word 파일에 따라 다릅니다. strings명령이 명확한 텍스트를 제공 하는 파일이 있습니다.
vinc17

또는 ( export LC_ALL=C; tr '\r' '\n' < target-file | grep search-string; )작동해야합니다.
vinc17

1
strings초강력 : utf-8 또는 ASCII 텍스트가 아닌 파일을 읽을 수 있습니다.
ctrl-alt-delor

()@ vinc17 덕분에 문제가 해결 될 것이라고 생각했던 점 에 대해 죄송합니다 .
ctrl-alt-delor
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.