grep
to narzędzie do przetwarzania tekstu. Oczekuje, że ich dane wejściowe będą plikami tekstowymi . Wygląda na to, że to samo dotyczy tr
systemu macOS (chociaż tr
ma obsługiwać pliki binarne).
Komputery przechowują dane jako sekwencje bajtów . Tekst to ciąg znaków. Istnieje kilka sposobów kodowania znaków jako bajtów, zwanych kodowaniem znaków . De facto standardowym kodowaniem znaków w większości świata, szczególnie w OSX, jest UTF-8 , który jest kodowaniem zestawu znaków Unicode . Istnieje tylko 256 możliwych bajtów, ale ponad milion możliwych znaków Unicode, więc większość znaków jest kodowana jako wiele bajtów. UTF-8 jest kodowaniem o zmiennej długości: w zależności od znaku kodowanie znaku może zająć od jednego do czterech bajtów. Niektóre sekwencje bajtów nie reprezentują żadnego znaku w UTF-8. Dlatego istnieją sekwencje bajtów, które nie są poprawnymi plikami tekstowymi UTF-8.
tr
narzeka, ponieważ napotkał taką sekwencję bajtów. Oczekuje pliku tekstowego zakodowanego w UTF-8, ale widzi dane binarne, które nie są poprawne UTF-8.
Dokument Microsoft Word nie jest plikiem tekstowym: jest to dokument edytora tekstu. Formaty dokumentów przetwarzania tekstu kodują nie tylko tekst, ale także formatowanie, osadzone obrazy itp. Format Word, podobnie jak większość formatów przetwarzania tekstu, nie jest plikiem tekstowym.
Możesz poinstruować narzędzia do przetwarzania tekstu, aby działały na bajtach, zmieniając ustawienia regionalne . W szczególności wybierz lokalizację „C”, co w zasadzie oznacza „nic szczególnego”. W wierszu polecenia możesz wybrać ustawienia regionalne ze zmiennymi środowiskowymi .
export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string
Nie spowoduje to wyemitowania błędu, ale nie przyniesie też nic pożytecznego, ponieważ target-file
nadal jest plikiem binarnym, który prawdopodobnie nie zawiera większości podanych ciągów wyszukiwania.
Nawiasem mówiąc, tr '\r' '\n'
nie jest to bardzo przydatne polecenie, chyba że masz pliki tekstowe z systemu Mac OS 9 lub starszego. \r
(powrót karetki) był separatorem nowej linii w Mac OS przed Mac OS X. Od OSX separatorem nowej linii jest \n
(przesunięcie wiersza, standard unix), a pliki tekstowe nie zawierają znaków powrotu karetki. Windows używa dwuznakowej sekwencji CR-LF do reprezentowania podziałów linii; tr -d '\r'
przekonwertowałby plik tekstowy Windows na plik tekstowy Unix / Linux / OSX.
Jak więc szukać w dokumencie Word z wiersza poleceń? Dokument .docx
Word jest w rzeczywistości archiwum zip zawierającym kilka plików, z których główne są w formacie XML .
unzip -l Position-Paper-Final-Version.docx
Mac OS X zawiera narzędzie zipgrep do przeszukiwania plików zip.
zipgrep DeCSS Position-Paper-Final-Version.docx
Wynik nie będzie bardzo czytelny, ponieważ pliki XML w formacie docx składają się głównie z jednej ogromnej linii. Jeśli chcesz przeszukać główny tekst dokumentu, wypakuj plik word/document.xml
z archiwum. Zauważ, że oprócz tekstu dokumentu, plik ten zawiera znaczniki XML, które reprezentują strukturę dokumentu. Możesz nieco masować znaczniki XML, sed
aby podzielić je na łatwe do zarządzania linie.
unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS