A while ago, I noticed a weird bug affecting the way QuickLook on Leopard showed characters with french accents, while being careful to save in UTF-8 from TextMate:

TM’s on left, QL on the right. Unix deities seemed to confirm that TM was not to blame:

$ file test.txt
test.txt: UTF-8 Unicode text
$ cat test.txt
é ç ë

On the other hand, opening test.txt with TextEdit gave the same result as QuickLook — messed up characters. If I fixed the characters in TextEdit and saved, the display of this particular file was always correct from then on (even if I modified it with TM afterwards). Weird.

Apart from a grand total of one (1) related and unanswered thread at Apple Discussions, a Google search for “Quicklook utf8″ or “Quicklook unicode” turned out nothing – so at first it seemed like there were only two people on the entire planet affected by this bug (well, three). By being a little more creative with my keywords, however, this post by Nico Weber on a vi-related thread turned up:

Indeed, if you check the two files with `ls -l`, you’ll see that the
file written by TextEdit has an “@” (that means it has an extended
attribute). Now, if you do `ls -l@` or `xattr -l filename`, you’ll see
that the TextEdit file has the com.apple.TextEncoding attribute set:

The file written by MacVim does not have this attribute. If you add it
(`xattr -w com.apple.TextEncoding ‘UTF-8;134217984′ macvimfile.txt`),
the file shows up correctly in Quicklook (and in TextEdit too; it
didn’t do that before)

Applying the `xattr` command on test.txt did the trick: non-ASCII UTF-8 characters now show up fine in QL.
So what gives? It seems pretty harsh to me to demand extended attributes just to have the encoding right, especially when all 3-rd party programs are handling the matter perfectly fine without them, thank you very much. I don’t feel like applying xattr on all my text files either. I also don’t understand why the issue is not more widespread, i.e. why nobody talks about it. I feel like maybe this bug only appears with a specific combination of tools and locales? Should TextMate set the relevant attributes? I’m puzzled.

well, this utf8 issue is huge! ever try to sort via terminal? i’m Turkish and my env is UTF8 by default. when i cat a file and pipe to sort shit happens… also, after installing snow leopard, nano screwed up when i press Turkish letter… thanx to macports ( for nano )…

I have the same problem. And the solution to edit each file individually afterwards isn’t really viable. This is pretty annoying as I always use TM to edit text files, and I very often use quick look to view them

Same here with OS X 10.6.2. Pretty annoying as I quicklook text files quite often. I’m jut asking to myself how could they introduce such a bug.
Hope somebody will post a solution on this blog or Apple makes a patch for it.

I am having the same problem. I am also wondering why TextEdit does not detect text file encoding properly. Auto detection of the encoding fails with TextEdit on 10.6.3 too.
TextWrangler does here a perfect job without issues.

For me, I wanted to use TextEdit because it is faster and I just don’t need all the features, that TextWrangers brings.

In my experience (10.6.3) TextMate is lying about saving in UTF8 (you can set default in settings).
When you open resulting file in TextEdit – it’s garbled trash. Then when you Cmnd+A and Delete, and paste clean (e.g. Cyrillic) text you copied from same file from TextMate – it’ll tell you:
“This document can no longer be saved using its original Western (Mac OS Roman) encoding.”

I could only make it work with UTF16 (if saving directly from TextMate).
Though it works w/UTF8 if you force : “Save As” with UTF8 and then “Replace” while you edit in TextEdit.

Hi,
I have the same problem. One possible fix is to change the content of the file ~/.CFUserTextEncoding to
0x08000100:0
This sets the default encoding to UTF8 (first number 0x08000100) and the language to English (second number 0). The default content is 0:0 (MacRoman and English).
Then you should restart the session and hopefully Quicklook will correctly read the utf8 files.

In fact, for .txt files it is easier since QuickLook uses the preferences of TextEdit: thus it’s enough to tell TextEdit that the default encoding is UTF8 for opening and saving files (instead of “automatic”).

As to the previous solution, it seems that it causes troubles with other applications such as Firefox and Thunderbird (they won’t start…). Too bad.

Apple just doesn’t fix these kind of things, they don’t care. Two other bugs are images showing up as blank when navigating images backwards [1] and text files with an apostrophe in the filename showing up blank as well (I can’t find any reports about this online but I noticed it since Lion) still persist in Mavericks (and maybe Yosemite).