StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This is one of those things where Cocoa does all the messy stuff behind the scenes, and you never really appreciate just how complicated things can be until you have to roll up your sleeves and do it yourself.</p> <p>The simple answer for why it's not 'simple' is because <code>NSString</code> (and <code>CFString</code>) deal with all the complicated details of dealing with multiple character sets, Unicode, etc, etc, while presenting a simple, uniform API for manipulating strings. It's object oriented at its best- the details of 'how' <code>(NS|CF)String</code> deals with strings that have different string encodings (UTF8, MacRoman, UTF16, ISO 2022 Japanese, etc) is a private implementation detail. It all 'just works'.</p> <p>It helps to understand how <code>[@"..." UTF8String]</code> works. This is a private implementation detail, so this isn't gospel, but based on observed behavior. When you send a string a <code>UTF8String</code> message, the string does something approximating (not actually tested, so consider it pseudo-code, and there's actually simpler ways to do the exact same thing, so this is overly verbose):</p> <pre><code>- (const char *)UTF8String { NSUInteger utf8Length = [self lengthOfBytesUsingEncoding:NSUTF8StringEncoding]; NSMutableData *utf8Data = [NSMutableData dataWithLength:utf8Length + 1UL]; char *utf8Bytes = [utf8Data mutableBytes]; [self getBytes:utf8Bytes maxLength:utf8Length usedLength:NULL encoding:NSUTF8StringEncoding options:0UL range:NSMakeRange(0UL, [self length]) remainingRange:NULL]; return(utf8Bytes); } </code></pre> <p>You don't have to worry about the memory management issues of dealing with the buffer that <code>-UTF8String</code> returns because the <code>NSMutableData</code> is autoreleased.</p> <p>A string object is free to keep the contents of the string in whatever form it wants, so there's no guarantee that its internal representation is the one that would be most convenient for your needs (in this case, UTF8). If you're using just plain C, you're going to have to deal with managing some memory to hold any string conversions that might be required. What was once a simple <code>-UTF8String</code> method call is now much, much more complicated.</p> <p>Most of <code>NSString</code> is actually implemented in/with CoreFoundation / <code>CFString</code>, so there's obviously a path from a <code>CFStringRef</code> -> <code>-UTF8String</code>. It's just not as neat and simple as <code>NSString</code>'s <code>-UTF8String</code>. Most of the complication is with memory management. Here's how I've tackled it in the past:</p> <pre><code>void someFunction(void) { CFStringRef cfString; // Assumes 'cfString' points to a (NS|CF)String. const char *useUTF8StringPtr = NULL; UInt8 *freeUTF8StringPtr = NULL; CFIndex stringLength = CFStringGetLength(cfString), usedBytes = 0L; if((useUTF8StringPtr = CFStringGetCStringPtr(cfString, kCFStringEncodingUTF8)) == NULL) { if((freeUTF8StringPtr = malloc(stringLength + 1L)) != NULL) { CFStringGetBytes(cfString, CFRangeMake(0L, stringLength), kCFStringEncodingUTF8, '?', false, freeUTF8StringPtr, stringLength, &usedBytes); freeUTF8StringPtr[usedBytes] = 0; useUTF8StringPtr = (const char *)freeUTF8StringPtr; } } long utf8Length = (long)((freeUTF8StringPtr != NULL) ? usedBytes : stringLength); if(useUTF8StringPtr != NULL) { // useUTF8StringPtr points to a NULL terminated UTF8 encoded string. // utf8Length contains the length of the UTF8 string. // ... do something with useUTF8StringPtr ... } if(freeUTF8StringPtr != NULL) { free(freeUTF8StringPtr); freeUTF8StringPtr = NULL; } } </code></pre> <p><strong>NOTE</strong>: I haven't tested this code, but it is modified from working code. So, aside from obvious errors, I believe it should work.</p> <p>The above tries to get the pointer to the buffer that <code>CFString</code> uses to store the contents of the string. If <code>CFString</code> happens to have the string contents encoded in UTF8 (or a suitably compatible encoding, such as ASCII), then it's likely <code>CFStringGetCStringPtr()</code> will return non-<code>NULL</code>. This is obviously the best, and fastest, case. If it can't get that pointer for some reason, say if <code>CFString</code> has its contents encoded in UTF16, then it allocates a buffer with <code>malloc()</code> that is large enough to contain the entire string when its is transcoded to UTF8. Then, at the end of the function, it checks to see if memory was allocated and <code>free()</code>'s it if necessary.</p> <p>And now for a few tips and tricks... <code>CFString</code> 'tends to' (and this is a private implementation detail, so it can and does change between releases) keep 'simple' strings encoded as MacRoman, which is an 8-bit wide encoding. MacRoman, like UTF8, is a superset of ASCII, such that all characters < 128 are equivalent to their ASCII counterparts (or, in other words, any character < 128 is ASCII). In MacRoman, characters >= 128 are 'special' characters. They all have Unicode equivalents, and tend to be things like extra currency symbols and 'extended western' characters. See <a href="http://en.wikipedia.org/wiki/Mac_OS_Roman" rel="nofollow noreferrer">Wikipedia - MacRoman</a> for more info. But just because a <code>CFString</code> says it's MacRoman (<code>CFString</code> encoding value of <code>kCFStringEncodingMacRoman</code>, <code>NSString</code> encoding value of <code>NSMacOSRomanStringEncoding</code>) doesn't mean that it has characters >= 128 in it. If a <code>kCFStringEncodingMacRoman</code> encoded string returned by <code>CFStringGetCStringPtr()</code> is composed entirely of characters < 128, then it is exactly equivalent to its ASCII (<code>kCFStringEncodingASCII</code>) encoded representation, which is also exactly equivalent to the strings UTF8 (<code>kCFStringEncodingUTF8</code>) encoded representation.</p> <p>Depending on your requirements, you may be able to 'get by' using <code>kCFStringEncodingMacRoman</code> instead of <code>kCFStringEncodingUTF8</code> when calling <code>CFStringGetCStringPtr()</code>. Things 'may' (probably) be faster if you require strict UTF8 encoding for your strings but use <code>kCFStringEncodingMacRoman</code>, then check to make sure the string returned by <code>CFStringGetCStringPtr(string, kCFStringEncodingMacRoman)</code> only contains characters that are < 128. If there are characters >= 128 in the string, then go the slow route by <code>malloc()</code>ing a buffer to hold the converted results. Example:</p> <pre><code>CFIndex stringLength = CFStringGetLength(cfString), usedBytes = 0L; useUTF8StringPtr = CFStringGetCStringPtr(cfString, kCFStringEncodingUTF8); for(CFIndex idx = 0L; (useUTF8String != NULL) && (useUTF8String[idx] != 0); idx++) { if(useUTF8String[idx] >= 128) { useUTF8String = NULL; } } if((useUTF8String == NULL) && ((freeUTF8StringPtr = malloc(stringLength + 1L)) != NULL)) { CFStringGetBytes(cfString, CFRangeMake(0L, stringLength), kCFStringEncodingUTF8, '?', false, freeUTF8StringPtr, stringLength, &usedBytes); freeUTF8StringPtr[usedBytes] = 0; useUTF8StringPtr = (const char *)freeUTF8StringPtr; } </code></pre> <p>Like I said, you don't really appreciate just how much work Cocoa does for you automatically until you have to do it all yourself. :)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload