grepè uno strumento di elaborazione del testo. Si aspetta che il loro input sia un file di testo . Sembra che lo stesso valga per trmacOS (anche se trsi suppone che supporti i file binari).
I computer memorizzano i dati come sequenze di byte . Un testo è una sequenza di caratteri. Esistono diversi modi per codificare i caratteri come byte, chiamati codifiche dei caratteri . La codifica dei caratteri standard di fatto nella maggior parte del mondo, specialmente su OSX, è UTF-8 , che è una codifica per il set di caratteri Unicode . Esistono solo 256 byte possibili, ma oltre un milione di possibili caratteri Unicode, quindi la maggior parte dei caratteri sono codificati come più byte. UTF-8 è una codifica di lunghezza variabile: a seconda del carattere, possono essere necessari da uno a quattro byte per codificare un carattere. Alcune sequenze di byte non rappresentano alcun carattere in UTF-8. Pertanto, esistono sequenze di byte che non sono file di testo UTF-8 validi.
trsi lamenta perché ha riscontrato una tale sequenza di byte. Si aspetta di vedere un file di testo codificato in UTF-8, ma vede dati binari che non sono UTF-8 validi.
Un documento di Microsoft Word non è un file di testo: è un documento di elaborazione testi. I formati di documenti di elaborazione testi codificano non solo il testo, ma anche la formattazione, le immagini incorporate, ecc. Il formato di Word, come la maggior parte dei formati di elaborazione di testi, non è un file di testo.
È possibile indicare agli strumenti di elaborazione del testo di operare sui byte modificando le impostazioni internazionali . In particolare, selezionare la locale "C", che in pratica significa "niente di speciale". Sulla riga di comando, è possibile scegliere le impostazioni locali con le variabili di ambiente .
export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string
Ciò non genererà alcun errore, ma non farà nulla di utile poiché target-fileè ancora un file binario che probabilmente non contiene la maggior parte delle stringhe di ricerca specificate.
Per inciso, tr '\r' '\n'non è un comando molto utile a meno che non siano rimasti file di testo da Mac OS 9 o precedenti. \r(ritorno a capo) era il separatore di nuova riga in Mac OS prima di Mac OS X. Dal momento che OSX, il separatore di nuova riga è \n(avanzamento riga, lo standard unix) e i file di testo non contengono ritorni a capo. Windows utilizza la sequenza di due caratteri CR-LF per rappresentare le interruzioni di riga; tr -d '\r'converte un file di testo di Windows in un file di testo Unix / Linux / OSX.
Quindi, come puoi cercare in un documento Word dalla riga di comando? Un .docxdocumento Word è in realtà un archivio zip contenente diversi file, i principali sono in XML .
unzip -l Position-Paper-Final-Version.docx
Mac OS X include l' utilità zipgrep per cercare all'interno dei file zip.
zipgrep DeCSS Position-Paper-Final-Version.docx
Il risultato non sarà molto leggibile perché i file XML in formato docx sono costituiti principalmente da una riga enorme. Se si desidera cercare all'interno del testo principale del documento, estrarre il file word/document.xmldall'archivio. Si noti che oltre al testo del documento, questo file contiene markup XML che rappresenta la struttura del documento. Puoi massaggiare un po 'il markup XML sedper dividerlo in righe gestibili.
unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS