Question

Im my iOS 5.1 application, I use a 3rd party library which uses wchar_t for strings. This works fine internally, but I sometimes need to create an NSString for such string. I can use the following API:

- (id)initWithBytes:(const void *)bytes length:(NSUInteger)length encoding:(NSStringEncoding)encoding

But what encoding am I supposed to use? Since wchar_t in iOS is 32 bits, the candidate encodings are:

NSUTF32StringEncoding
NSUTF32BigEndianStringEncoding
NSUTF32LittleEndianStringEncoding

Which byte order am I supposed to use? Should I use the encoding byte order corresponding to the result of long NSHostByteOrder()?

And by the way, which byte order is NSUTF32StringEncoding representing? Is it going to examine the bytes and deduce the byte order? And what will it yield when converting from NSString with getBytes:maxLength:usedLength:encoding:options:range:remainingRange:?

Note that I am not concerned with data exchange between platforms here (though I may have to face that issue too someday).

Googling around didn’t help much.

My hunch is that this is compiler-defined, e.g. what encoding is used by my compiler (CLang) when I write:

wchar_t *s = L"string with non ascii unicode characters such as éèüçß";

Of course it’s easy enough to write a small sample program and find out, but I’d like a solution that doesn’t rely on the specific implementation of my compiler.

If you believe I am confused, that’s because I am a bit.

Answer 1

This is why wchar_t is impossible to recommend, except when you need to work directly with the Windows API.

On iOS, wchar_t is UTF-32 with the native byte order. This is technically not the same thing as NSUTF32StringEncoding, which indicates either byte order with a BOM.

Here’s some copy pasta from the last time I answered this question (link):

#include <machine/endian.h>
#if BYTE_ORDER == BIG_ENDIAN
#define WCHAR_ENCODING NSUTF32BigEndianStringEncoding
#elif BYTE_ORDER == LITTLE_ENDIAN
#define WCHAR_ENCODING NSUTF32LittleEndianStringEncoding
#endif

The problem with using NSUTF32StringEncoding is that it will only work for converting wchar_t to NSString, but not necessarily the other way around. It will stick a BOM on the front (undesirable) and it may even give you data in the wrong endian.

It is also possible that using NSUTF32StringEncoding will cause errors even going from wchar_t to NSString, but that is extremely unlikely.