Pregunta:
Soy nuevo en UNIX y estoy usando "La línea de comandos de Mac OS X" de Kirk McElhearn para aprender algunos comandos.
Estoy intentando usar tr y grep para poder buscar cadenas de texto en un documento Word normal de MS-Office.
$ tr '\r' '\n' < target-file | grep search-string
Pero todo lo que devuelve es:
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$
De hecho, ejecuté la misma línea en un script que creé en vi y realiza la búsqueda correctamente.
Respuesta:
grep es una herramienta de procesamiento de texto. Espera que su entrada sean archivos de texto . Parece que lo mismo ocurre con tr en macOS (aunque se supone que tr admite archivos binarios).
Las computadoras almacenan datos como secuencias de bytes . Un texto es una secuencia de caracteres. Hay varias formas de codificar caracteres como bytes, denominadas codificaciones de caracteres . La codificación de caracteres estándar de facto en la mayor parte del mundo, especialmente en OSX, es UTF-8 , que es una codificación para el juego de caracteres Unicode . Solo hay 256 bytes posibles, pero más de un millón de caracteres Unicode posibles, por lo que la mayoría de los caracteres se codifican como varios bytes. UTF-8 es una codificación de longitud variable: según el carácter, puede tomar de uno a cuatro bytes codificar un carácter. Algunas secuencias de bytes no representan ningún carácter en UTF-8. Por lo tanto, hay secuencias de bytes que no son archivos de texto UTF-8 válidos.
tr se queja porque encontró tal secuencia de bytes. Espera ver un archivo de texto codificado en UTF-8, pero ve datos binarios que no son UTF-8 válido.
Un documento de Microsoft Word no es un archivo de texto: es un documento de procesamiento de texto. Los formatos de documentos de procesamiento de texto codifican no solo texto, sino también formato, imágenes incrustadas, etc. El formato de Word, como la mayoría de los formatos de procesamiento de texto, no es un archivo de texto.
Puede indicar a las herramientas de procesamiento de texto que operen en bytes cambiando la configuración regional . Específicamente, seleccione la configuración regional "C", que básicamente significa que significa "nada elegante". En la línea de comando, puede elegir la configuración regional con variables de entorno .
export LC_CTYPE=C
tr '\r' '\n' < target-file | grep search-string
Esto no emitirá ningún error, pero tampoco hará nada útil ya que target-file sigue siendo un archivo binario que es poco probable que contenga la mayoría de las cadenas de búsqueda que especificará.
Por cierto, tr '\r' '\n' no es un comando muy útil a menos que tenga archivos de texto de Mac OS 9 o anterior. \r (retorno de carro) era el separador de nueva línea en Mac OS antes de Mac OS X. Desde OSX, el separador de nueva línea es \n (salto de línea, el estándar Unix) y los archivos de texto no contienen retornos de carro. Windows usa la secuencia de dos caracteres CR-LF para representar saltos de línea; tr -d '\r' convertiría un archivo de texto de Windows en un archivo de texto Unix / Linux / OSX.
Entonces, ¿cómo se puede buscar en un documento de Word desde la línea de comandos? Un documento .docx Word es en realidad un archivo zip que contiene varios archivos, los principales están en XML .
unzip -l Position-Paper-Final-Version.docx
Mac OS X incluye la utilidad zipgrep para buscar dentro de archivos zip.
zipgrep DeCSS Position-Paper-Final-Version.docx
El resultado no será muy legible porque los archivos XML en formato docx consisten principalmente en una línea enorme. Si desea buscar dentro del texto del cuerpo principal del documento, extraiga el archivo word/document.xml del archivo. Tenga en cuenta que, además del texto del documento, este archivo contiene marcado XML que representa la estructura del documento. Puede masajear un poco el marcado XML con sed para dividirlo en líneas manejables.
unzip -p Position-Paper-Final-Version.docx word/document.xml |
sed -e 's/></>\n</g' |
grep DeCSS