假设我有一个符号MUSICAL SYMBOL G CLEF：** **，我希望在我的Objective-C源文件中用字符串字面量表示它。
OS X字符查看器说CLEF是UTF8 F0 9D 84 9E和Unicode1D11E（D834+DD1E）。
经过一些尝试和使用ICU UNICODE演示页面，我确实让以下代码能够工作：
NSString *uni=@"\U0001d11e";
NSString *uni2=[[NSString alloc] initWithUTF8String:"\xF0\x9D\x84\x9E"];
NSString *uni3=@"";
NSLog(@"unicode: %@ and %@ and %@",uni, uni2, uni3);
我的问题：
@"\U0001d11e部分是UTF-32吗？uni3中的做法，但遗憾的是那是不推荐的。如果不行，我宁愿选择uni中的方法而不是uni2。另一个选项是[NSString stringWithFormat:@"%C", 0x1d11e]。以下是按照相同顺序回答您的问题：
为什么要选择？Xcode在默认设置中使用C99。请参阅C0X草案规范6.4.3中的通用字符名称。详情见下方。
更具体地说，@"\U0001d11e是ISO 10646字符集中该字符的32位Unicode代码点。
我不会指望这种行为能够正常工作。您应该绝对、肯定、毫无疑问地让源文件中的所有字符都是7位ASCII码。对于字符串字面值，请使用编码或最好使用适合处理二进制数据的外部资源。
通用字符名称（来自WG14/N1256 C0X草案，CLANG遵循得相当好）：
“通用字符名”可以用于标识符、字符常量和字符串字面值中，以指定不属于基本字符集的字符。其中，“\Unnnnnnnn”代表八位短标识符（由ISO/IEC 10646规定）为“nnnnnnnn”的字符；同样，“\unnnn”代表四位短标识符为“nnnn”的字符（其八位短标识符为“0000nnnn”）。因此，您可以以一种自然、混合的方式生成字符或字符串。char *utf8CStr =
"May all your CLEF's \xF0\x9D\x84\x9E be left like this: \U0001d11e";
NSString *uni4=[[NSString alloc] initWithUTF8String:utf8CStr];
\Unnnnnnnn形式允许您选择任何Unicode代码点，这与字符查看器左下角的“Unicode”字段的值相同。在C99源文件中直接输入\Unnnnnnnn将由编译器适当处理。请注意，只有两个选项：\unnnn是默认代码页的256个字符偏移量，\Unnnnnnnn是任何Unicode代码点的完整32位字符。如果您没有使用所有4个或所有8个数字或\u或\U，则需要在左侧填充0。\xF0\x9D\x84\x9E的形式更加有趣。这是插入相同字符的原始UTF-8编码。一旦传递给initWithUTF8String方法，但字面量和编码字面量最终都被编码为UTF-8。
也许，使用原始字节可能是第5.1.1.2节的130条的违规行为。考虑到原始UTF-8字符串将类似地编码，我认为你没问题。
\u和1234粘合在一起以获得\u1234，这与字符串文字中使用的字节表示UTF-8字符无关。 - AnomieYou can write the clef character in your string literal, too:
NSString *uni2=[[NSString alloc] initWithUTF8String:""];
The \U0001d11e matches the unicode code point for the G clef character. The UTF-32 form of a character is the same as its codepoint, so you can think of it as UTF-32 if you want to. Here's a link to the unicode tables for musical symbols.
Your file probably is UTF-8. The G clef is a valid UTF8 character - check out the output from hexdump for your file:
00 4e 53 53 74 72 69 6e 67 20 2a 75 6e 69 33 3d 40 |NSString *uni3=@|
10 22 f0 9d 84 9e 22 3b 0a 20 20 4e 53 4c 6f 67 28 |"....";. NSLog(|
As you can see, the correct UTF-8 representation of that character is in the file right where you'd expect it. It's probably safer to use one of your other methods and try to keep the source file in the ASCII range.