Re: [Q] CFStringGetCStringPtr( ..., kCFStringEncodingUTF8)
Re: [Q] CFStringGetCStringPtr( ..., kCFStringEncodingUTF8)
- Subject: Re: [Q] CFStringGetCStringPtr( ..., kCFStringEncodingUTF8)
- From: Michael Ash <email@hidden>
- Date: Wed, 24 Jun 2009 00:10:53 -0400
On Tue, Jun 23, 2009 at 3:13 PM, JongAm
Park<email@hidden> wrote:
> Oh.. one more thing...
>
> I think you didn't catch what I wanted to say.
> It will be OK to return NULL if it can't convert a given string to a string
> in a given text encoding method.
> ( But, yes.. Apple's document mentioned that its behaviour can be changed,
> so don't rely on it. )
>
> What I wanted to say was "Why does it return a meaningful address when the
> system encoding is Japanese while it doesn't when the system encoding is
> English?".
> (When UTF8 is used for a target. )
> Can't MacRoman be converted to UTF8 while MacJapanese can be?
> I assumed that MacRoman code page is almost identical to UTF8, because UTF8
> is compatible with ASCII and MacRoman is extended form for ASCII.
Why assume? If you're working with encoded string data, it is
foolhardy to *assume* anything about the encodings that you're working
with. Go learn how they work. It's not that hard. MacRoman will
literally take you fifteen seconds to understand, as it is an
extremely simple encoding. UTF-8 is more complicated, but still pretty
easy to understand, and it is *vital* to understand it. Wikipedia has
very good articles on both encodings, as well as many others.
That you say something like "MacRoman code page is almost identical to
UTF8" indicates that your education on character encodings is woefully
lacking. You should remedy this problem ASAP.
Mike
_______________________________________________
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