MacOS – How to convert Apple’s .textClipping files to plain text

findermacosui

If you select some text in an app (e.g. Chrome or any other app which allows dragging text), and drag the selection to a Finder panel, then a file will be created in the panel with an invisible .textClipping extension. The extension might or might not be visible in Finder depending on your settings.

Originally I assumed that the file is plain text, and tried renaming it to add a .txt extension, yet double-clicking still opens it with Finder.

Then I checked the file type:

file 'some text.textClipping'
>> some text.textClipping: Apple binary property list

cat-ing it shows a header of bplist00?XUTI-Data? followed by readable text.

I tried:

mv 'some text.textClipping' 'some text.txt'

but even after this it still opens with Finder and not the associated app for the .txt files.

Another 'oddity' is that dragging a .textClipping file into the terminal — which I sometimes use as a way of inserting the full path — has the unexpected effect of inserting the contents of the file rather than its path.

I wish I could use .textClipping files to quickly create snippets from web pages and other apps, but for obvious reasons, I want to avoid the snippets being stored in some Apple proprietary binary format.

Is there a way to convert the snippets to a portable format, such as plain text? How come that this type of files behave differently from others? Is there is some extended file property? Then how to remove it so that the files stop being 'special'?

Best Answer

Futher googling about Apple's binary property lists lead me to try plutil -convert xml1 note.textClipping which produces an XML file with the readable text of the snippet as UTF-8 text, then base64-encoded versions of the same text in UTF-16, mac-plain, and HTML.

Even after converting the binary to XML format, Finder still opens the file in its own viewer no matter what extension is set (e.g. .plist or .xml).

Running /bin/ls -al in the folder shows a @ next to the file name which indicates the file has extended attributes so it looks that they are causing the 'special' behavour in Finder.

This answer lead me to try 

xattr -l note.plist

which reveals that some of the note's content is stored as an extended attribute key.

And finally, clearing all extended attributes turned the file into a 'normal' file, so now it opens with the associated app:

xattr -c note.plist

The command above is for a single file, to strip extended attributes for all files in the current folder run:

xattr -rc .

Extended attributes might be useful in some cases — for example, if you downloaded a file with safari or chrome the original URL will be stored as an extended attribute which you can see with xattr -l myfile.zip or right-clicking a file in Finder and selecting Get Info > The URL will be displayed under More Info > Where from. (Another reason not to use wget when you want to keep track of the file's origin.)

Related Question