[TxMt] Re: unicode issue with QuickLook on Leopard

Adam R. Maxwell amaxwell at mac.com
Mon Jun 30 14:09:38 UTC 2008


On Jun 29, 2008, at 10:39 PM, Allan Odgaard wrote:

> On 30 Jun 2008, at 00:57, Adam R. Maxwell wrote:
>
>> [...] According to the Foundation release notes, 10.5 now tries
>> UTF-8 as a fallback if -[NSString
>> initWithContentsOfURL:usedEncoding:error] is used (presumably if
>> xattrs and BOM are absent).  Does that answer your suggestion?
>
> Answer my suggestion? Not sure what you mean by that.

UTF-8 is now tried as a fallback before giving up completely.   
Unfortunately, it's limited to two methods on NSString AFAIK.

>> Personally, I like the idea of using xattrs for this, but we were
>> using them for that purpose before Leopard.
>
> Using it to make UTF-8 work is bad! As said, UTF-8 can be safely
> detected without such attribute, so the attribute is 100% redundant.

Yes, it's redundant for files with a BOM and for UTF-8.  I'm curious  
as to you think it's entire purpose is to make UTF-8 work?  I would  
suggest that it's purpose is to make Latin-1, Shift-JIS, and all the  
other weird encodings work.  Using UTF-8 is certainly preferable, but  
not everyone can do that!

> Also, UTF-8 is the only sane encoding to use for new stuff, so text
> files should be UTF-8 today, having to do special tricks to make the
> system detect them as that, sucks, especially since majority of text
> files are not generated in CoreFoundation-using applications -- even
> on a Mac they might come from shell redirects, be generated by
> scripts, or similar. So majority of files will not have this
> attribute, and will never get such attribute.

I agree; UTF-8 /should/ be used.  If files are loaded into a Cocoa app  
using the method I noted, it'll try UTF-8 before giving up, regardless  
of whether the attribute is present.  I have to deal with other  
encodings fairly regularly, unfortunately.

-- 
Adam



More information about the textmate mailing list