Re: Why is NSString->FSRef so hard?
Re: Why is NSString->FSRef so hard?
- Subject: Re: Why is NSString->FSRef so hard?
- From: Ken Thomases <email@hidden>
- Date: Mon, 27 Apr 2009 23:41:01 -0500
On Apr 27, 2009, at 11:26 PM, Erg Consultant wrote:
One other thing I should mention - the mangled char in question is
the tm symbol (option-2). In its string form, the debugger shows it
as the tm char.
But when I convert the string to an NSURL using fileURLWithPath, and
then do a CFShow, the tm is converted to *three* hex chars:
™
Right. This is to be expected. Not all characters are legal within
URLs. So, URLs have to be escaped. The trademark character in UTF-8
encoding is the byte sequence 0xE2, 0x84, 0xA2. Yes, three bytes.
Those bytes are then escaped using percent-sign-hex-value to make them
safe for a URL.
I strongly suspect your problems and your confusion about the results
you're seeing are because you aren't understanding the subject of
string encoding. You appear to be blindly stabbing in the dark,
trying to guess why things work or don't. As somebody earlier in the
thread pointed out, STL strings are not encoding aware. If you don't
know the encoding of the bytes that you used to initialize those STL
strings, then you're not going to have any luck interpreting them,
writing them sanely to a file in a consistent way, nor reading them
back in.
Are NSURL and CFURL not toll-free bridged?
They are toll-free bridged. What about the above made you think
otherwise?
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden