为什么NSString和NSLog似乎处理不同的％C和％lc（和％S和％ls）？

本文介绍了为什么NSString和NSLog似乎处理不同的％C和％lc（和％S和％ls）？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 Apple的字符串格式说明符文档声明， 但是， printf 规范定义％lc 和％S 作为％ls 的等价物，只有％C 和 S 和 + [NSString stringWithFormat：] 看起来可以正常使用 p> 例如，考虑以下代码： #import int main（int argc，const char * argv []）{ NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; unichar str [3]; str [0] = 63743; str [1] = 33; str [2] =（unichar）NULL; NSLog（@NSLog）; NSLog（@%% S：％S，str）; NSLog（@%% ls：％ls，str）; NSLog（@%% C：％C，str [0]）; NSLog（@%% lc：％lc，str [0]）; NSLog（@\\\）; NSLog（@+ [NSString stringWithFormat：]）; NSLog（@%% S：％@，[NSString stringWithFormat：@％S，str]） NSLog（@%% ls：％@，[NSString stringWithFormat：@％ls，str]）; NSLog（@%% C：％@，[NSString stringWithFormat：@％C，str [0]]）; NSLog（@%% lc：％@，[NSString stringWithFormat：@％lc，str [0]]）; [pool drain]; return 0; } 给出 printf 规范，我希望上面的每一对打印相同的东西。但是，当我运行代码，我得到以下输出： 2009-03-20 17：00：13.363 UnicharFormatSpecifierTest [ 48127：10b] NSLog 2009-03-20 17：00：13.365 UnicharFormatSpecifierTest [48127：10b]％S：！ 2009-03-20 17：00：13.366 UnicharFormatSpecifierTest [48127：10b]％ls：¯！ 2009-03-20 17：00：13.366 UnicharFormatSpecifierTest [48127：10b]％C： 2009-03-20 17：00：13.367 UnicharFormatSpecifierTest [48127：10b]％lc： 2009-03-20 17：00：13.367 UnicharFormatSpecifierTest [48127：10b] 2009-03-20 17：00：13.368 UnicharFormatSpecifierTest [48127：10b] + [NSString stringWithFormat：] 2009-03 -20 17：00：13.368 UnicharFormatSpecifierTest [48127：10b]％S：！ 2009-03-20 17：00：13.369 UnicharFormatSpecifierTest [48127：10b]％ls：¯！ 2009-03-20 17：00：13.369 UnicharFormatSpecifierTest [48127：10b]％C： 2009-03-20 17：00：13.370 UnicharFormatSpecifierTest [48127：10b]％lc： 我做错了什么，或者这是Apple的代码中的错误？解决方案在Mac OS X上，< machine / _types.h> 定义 wchar_t as int ，因此在当前支持的所有架构上都为四个字节（32位）。 如您所知， printf （3）联机帮助页定义％S 等效于％ls ，它接受一些 wchar_t 字符（ wchar_t * ）的指针。 但是，链接到的Cocoa文档（及其等效的CF）却分别定义了％S ：此外，％C 也是如此。 因此，这不是一个错误。 CF和Cocoa解释％S 和％C 与 printf 和它的表兄弟解释它们。 CF和Cocoa将字符视为UTF-16，而 printf （可能）将它们视为UTF-32。 当使用Core Services时，CF / Cocoa解释更有用，因为一些API（例如文件管理器）会将文本作为 UniChar s，而不是CFString;只要你使用null终止数组，你可以使用％S 打印该字符串。 Apple's String Format Specifiers document claims,But, while the printf specification defines %C as an equivalent for %lc and %S as an equivalent for %ls, only %C and %S appear to work correctly with NSLog and +[NSString stringWithFormat:].For example, consider the following code:#import <Foundation/Foundation.h>int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; unichar str[3]; str[0] = 63743; str[1] = 33; str[2] = (unichar)NULL; NSLog(@"NSLog"); NSLog(@"%%S: %S", str); NSLog(@"%%ls: %ls", str); NSLog(@"%%C: %C", str[0]); NSLog(@"%%lc: %lc", str[0]); NSLog(@"\n"); NSLog(@"+[NSString stringWithFormat:]"); NSLog(@"%%S: %@", [NSString stringWithFormat:@"%S", str]); NSLog(@"%%ls: %@", [NSString stringWithFormat:@"%ls", str]); NSLog(@"%%C: %@", [NSString stringWithFormat:@"%C", str[0]]); NSLog(@"%%lc: %@", [NSString stringWithFormat:@"%lc", str[0]]); [pool drain]; return 0;}Given the printf specification, I would expect each of the above pairs to print the same thing. But, when I run the code, I get the following output:2009-03-20 17:00:13.363 UnicharFormatSpecifierTest[48127:10b] NSLog2009-03-20 17:00:13.365 UnicharFormatSpecifierTest[48127:10b] %S: !2009-03-20 17:00:13.366 UnicharFormatSpecifierTest[48127:10b] %ls: ˇ¯!2009-03-20 17:00:13.366 UnicharFormatSpecifierTest[48127:10b] %C: 2009-03-20 17:00:13.367 UnicharFormatSpecifierTest[48127:10b] %lc: 2009-03-20 17:00:13.367 UnicharFormatSpecifierTest[48127:10b] 2009-03-20 17:00:13.368 UnicharFormatSpecifierTest[48127:10b] +[NSString stringWithFormat:]2009-03-20 17:00:13.368 UnicharFormatSpecifierTest[48127:10b] %S: !2009-03-20 17:00:13.369 UnicharFormatSpecifierTest[48127:10b] %ls: ˇ¯!2009-03-20 17:00:13.369 UnicharFormatSpecifierTest[48127:10b] %C: 2009-03-20 17:00:13.370 UnicharFormatSpecifierTest[48127:10b] %lc: Am I doing something wrong, or is this a bug in Apple's code? 解决方案 On Mac OS X, <machine/_types.h> defines wchar_t as int, so it's four bytes (32 bits) on all currently-supported architectures.As you note, the printf(3) manpage defines %S as equivalent to %ls, which takes a pointer to some wchar_t characters (wchar_t *).The Cocoa documentation you linked to (and its CF equivalent), however, does define %S separately:Emphasis added. Also, the same goes for %C.So, this is not a bug. CF and Cocoa interpret %S and %C differently from how printf and its cousins interpret them. CF and Cocoa treat the character(s) as UTF-16, whereas printf (presumably) treats them as UTF-32.The CF/Cocoa interpretation is more useful when working with Core Services, as some APIs (such as the File Manager) will hand you text as an array of UniChars, not a CFString; as long as you null-terminate that array, you can use it with %S to print the string. 这篇关于为什么NSString和NSLog似乎处理不同的％C和％lc（和％S和％ls）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！