Excel Mac: algunos archivos txt no se pueden abrir/importar ("atenuados")

Un poco raro. Estoy usando Excel para analizar algunos datos que tengo en varios archivos .txt.

Cuando estoy tratando de importarlos a través de Data> Get External Data> Import Text File:

Archivo de texto de importación de Excel

Como lo he hecho muchas veces en el pasado, aparece el cuadro de diálogo "Elegir un archivo", pero cuando busco la carpeta, solo un par de archivos son "seleccionables"; los otros están "en gris":

**ALGUNOS** Archivos de origen atenuados

No hay diferencias entre los archivos que puedo ver que justifiquen la diferencia. La única "lógica" es que el archivo "fuente" (llamémoslo 20150728 - SOURCE.TXT) viene por correo electrónico desde una máquina con Windows, y los otros dos archivos bloqueados ( 20150728 - Source Fragment 3.TXTy 20150728 - Source Fragment 3 copy.TXT) son una copia de la Fuente donde eliminé algunas líneas, y un segunda copia del archivo resultante, mientras que los no bloqueados comenzaron como la Fuente donde eliminé líneas, y luego hice "Guardar como" en TextWrangler...

Puedo solucionar el problema simplemente copiando el contenido de los archivos " en gris" en un nuevo documento en TextWrangler y guardándolo, pero me gustaría entender el motivo de este comportamiento.

Hacer un fileen los archivos en cuestión muestra que son similares, si no iguales:

Mac:samples jjarava$ file 201507*txt
20150728 - Source Fragment 3.TXT:      ASCII text
20150728 - Source Framgent 1.TXT:      ASCII text
20150728 - Source Fragment 1.TXT:      ASCII text
20150728 - Source.TXT:                 ASCII text, with CRLF line terminators
20150728 - Source Fragment 3 copy.TXT: ASCII text

Estoy un poco "atascado" en cuál podría ser el problema. Tengo la sensación de que es uno de esos "obscuros caprichos de Mac" que son muy difíciles de explicar.

EDITAR : según los comentarios a continuación de @ user3439894 y otros, he examinado los atributos extendidos de los archivos para ver si eso da alguna pista.

La salida de ls -l@para los archivos nos da:

-rw-r--r--@ 1 jjarava  staff   7652 Aug  3 13:58 20150728 - Source Fragment 3 (BAD).TXT
    com.apple.FinderInfo       32 
    com.apple.TextEncoding     15 
    com.dropbox.attributes     83 
-rw-r--r--@ 1 jjarava  staff   6570 Aug  3 13:58 20150728 - Source Fragment 1 (Good).TXT
    com.apple.FinderInfo       32 
    com.apple.TextEncoding     15 
    com.dropbox.attributes     83 
-rw-r--r--@ 1 jjarava  staff   6616 Aug  3 13:58 20150728 - Source Fragment 2 (Good).TXT
    com.apple.FinderInfo       32 
    com.apple.TextEncoding     15 
    com.dropbox.attributes     83 
-rw-r--r--@ 1 jjarava  staff  21138 Aug  3 13:58 20150728 - Source (BAD).TXT
    com.apple.FinderInfo       32 
    com.dropbox.attributes     83 

De nuevo, veo que a uno de los archivos malos (Fuente) aparentemente le falta el com.apple.TextEncodingatributo, pero el otro archivo "no funciona" sí tiene el atributo... En caso de que los valores sean diferentes para los archivos buenos y malos, vamos a controlar:

Mac:samples jjarava$ xattr -p com.apple.TextEncoding 201507*txt
20150728 - Source Fragment 3 (BAD).TXT: UTF-8;134217984
Source Fragment 1 (Good).TXT: UTF-8;134217984
Source Fragment 2 (Good).TXT: UTF-8;134217984
xattr: 20150728 - Source (BAD).TXT: No such xattr: com.apple.TextEncoding

Así que ese tampoco parece ser el truco...

Este puede ser el problema... 20150728 - Source.TXT: ASCII text, with CRLF line terminators. Intente reemplazar los terminadores de línea CRLF con solo LF. En una Terminal, intente:tr -d '\r' < input.file > output.file
Hola, @user3439894... Si ese fuera el único que "no funciona", estaría de acuerdo contigo. Pero en realidad, al cortar los datos para Sourceasegurarme Source 3de que los finales de línea fueran "Unix" en TextWrangler. Como puede ver, los otros archivos que no funcionan sonLF
¿Cuál es el contenido de los archivos que están atenuados?
Todos los archivos son iguales: líneas de texto ASCII con datos que quiero analizar con Excel. En realidad, he dividido el archivo "Fuente" en 3 ya que los contenidos están relacionados pero son solo líneas de texto separadas por espacios
Con una extensión .txt, asumí que era texto ASCII, además, el resultado fileya mostró que, sin embargo, el diseño es lo que me interesa, ¿cómo se delimita? ¿Y cuál es el ls -l@resultado de los archivos atenuados?
¿Qué usó para copiar/editar/guardar los archivos bloqueados?
Hola, las líneas de @user3439894 son del tipo [28/07/15 13:32:02.538][ WARN]Tiempo SDPTRU02: 361 || Resultado: 0: nada especial y, en cualquier caso, no creo que Excel esté analizando previamente los archivos; este es un cuadro de diálogo Abrir en el sistema operativo. Si el archivo tuvo problemas con el contenido, espero que Excel se queje después de que se haya seleccionado para abrir
user3439894 tiene un buen punto. Abra Terminal, navegue hasta el directorio y haga ls -lEso le indicará las banderas establecidas en los archivos. Puede ser que los archivos de texto atenuados se configuraron como de solo lectura.
@ARM, lo pedí ls -l@porque quiero saber si com.apple.quarantineestá configurado y, de ser así, eliminarlo xattr -d com.apple.quarantine filenamey luego ver si se abre el archivo.
@AMR Utilicé TextWrangler y el proceso fue el mismo: abra el Sourcearchivo, elimine algunas líneas adicionales y luego Guardar como... para el Fragmento 1 y 2. En el caso del Fragmento 3, fue ligeramente diferente... Lo hice una copia de Fuente, cambie el nombre a Fragmento 3, Abra en TextWrangler, elimine el contenido adicional y Guarde.

Respuestas (2)

Creo que tengo una respuesta.

Buscando en Google, encontré referencias a problemas "en gris" y menciones del creatoratributo del archivo.

Entonces, un rápido Google para " marca de creador de archivos osx " me señaló a mí SetFiley a su hermano GetFileInfo.

Ejecutando un rápido GetFileInfoen los archivos que obtengo:

Mac:samples jjarava$ for i in 201507*.TXT; do getfileinfo "$i"; echo .; done
file: "/path/to/samples/20150728 - Source Fragment 3 (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Framgent 1 (Good).TXT"
type: "TEXT"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Framgent 2 (Good).TXT"
type: "TEXT"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.
file: "/path/to/samples/20150728 - Source Fragment 3 copy (BAD).TXT"
type: "????"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18
.

Todos los archivos "en funcionamiento" son de type: "TEXT", y todos los que "no funcionan" parecen no tener un "tipo" definido...

En realidad, ejecutando lo siguiente para cambiar el archivo type:

Mac:samples jjarava$ setfile -t TEXT "20150728 - Source Fragment 3 copy (BAD).TXT"
Mac:samples jjarava$ getfileinfo "20150728 - Source Fragment 3 copy (BAD).TXT"
file: "/path/to/samples/20150728 - Source Fragment 3 copy (BAD).TXT"
type: "TEXT"
creator: "????"
attributes: avbstclinmedz
created: 08/03/2015 13:58:18
modified: 08/03/2015 13:58:18

¡Y ese archivo ahora se puede seleccionar en el cuadro de diálogo "Abrir" en Excel!

La pregunta es de dónde viene el campo "tipo" y por qué está configurado en algunos archivos y no en otros, ¡pero al menos hay algo de "lógica" en el problema!

tipo: "TEXT" (TextWrangler asignado) tampoco es absolutamente necesario, ya que tengo un archivo de texto con tipo: "\0\0\0\0" (TextEditor o táctil) que Excel es capaz de manejar en la importación . Es probable que el indicador desconocido "????" eso lo tira. Esos son parte del envoltorio del archivo que nunca vemos. Supongo que tiene que ver con el hecho de que en los que funcionaron hiciste File>SaveAs en TW mientras que con los que no copiaste el original y luego probablemente hiciste File>Save. TW no creó esos archivos, por lo que no tocó el tipo: atributo.
El "cómo llegamos aquí" tiene sentido... Tengo muy claro que el problema comenzó con el archivo "fuente". Tienes razón en que usé SaveAs en los casos de trabajo, y Save en los demás (está en la pregunta inicial)... Dado que guardé el Sourcearchivo desde mi programa de correo electrónico; claramente esa es la raíz del problema...
Sucedió de nuevo con otro conjunto de archivos. También son archivos de registro que obtuve comprimidos de otro cliente, y nuevamente no pude abrirlos en Excel, y procesarlos con las utilidades de Unix ( , , etc. cut) grepy canalizarlos a nuevos archivos todavía tengo el problema para importarlos para su procesamiento. Establecer el tipo en TEXTO SetFileresolvió el problema.

Bueno, como muestra su captura de pantalla, son "casi", pero no completamente iguales; el archivo original es ASCII text, with CRLF line terminatorsmientras que las copias y los fragmentos que creó son ASCII text.

Algunos antecedentes: si piensa en una máquina de escribir antigua, suceden cosas, cuando el escritor comienza una nueva línea: el papel se "hace avanzar" una línea ("avance de línea", LF) y el carro se mueve a la posición más a la izquierda (="retorno de carro", CF). UNIX y OS X usan un solo carácter LF para hacer ambas cosas en archivos de texto; Windows, por otro lado, usa dos caracteres, un CR y un LF, al final de cada línea.

Aparentemente, la función de importación de Excel no puede manejar el archivo de texto "formateado en Windows"; TextWrangler, por otro lado, puede y, cuando manipula el archivo y guarda una copia, lo guarda automáticamente en "formato UNIX", convirtiendo los CRLF en LF. Su solución es decirle a lo que crea esos archivos en la máquina de Windows, guardarlos en formato UNIX o convertirlos a formato UNIX en OS X, antes de poder importarlos a Excel.

Hola, FLIR31207: vea mi comentario a @user3439894 arriba. Si el único archivo que "no funciona" es el que tiene terminadores CRLF, estaría de acuerdo con usted. Pero los otros dos archivos "en gris" son LF como los que funcionan también ...
No creo que ese sea el problema, el problema está en algunos de los archivos derivados guardados en formato "UNIX", y no en el archivo original de Windows.
Hola, @AMR, pero ¿por qué tampoco puedo importar el Sourcearchivo? Eso es lo que me desconcierta...
Estaba comentando la respuesta, no tu comentario... Creo que estaba de acuerdo contigo...