[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