¿Por qué NSString y NSLog parecen manejar% C y% lc (y% S y% ls) de manera diferente?

Question

String Format Specifiers reclamaciones documento de Apple,

Los especificadores de formato compatible con los métodos de formato NSString y funciones de formato CFString seguir el IEEE printf specification; ... También puede usar estos especificadores de formato con la función NSLog.

Pero, mientras que la especificación define printf%C como equivalente de %lc y %S como equivalente de %ls, solamente %C y %S parecen funcionar correctamente con NSLog y +[NSString stringWithFormat:].

Por ejemplo, considere el siguiente código:

#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; 
} 

Dada la especificación printf, esperaría que cada uno de los pares anteriores para imprimir la misma cosa. Sin embargo, cuando ejecuto el código, me sale el siguiente resultado:

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: 

estoy haciendo algo mal, o se trata de un error en el código de Apple?

Answer 1

En Mac OS X, <machine/_types.h> define wchar_t como int, por lo que tiene cuatro bytes (32 bits) en todas las arquitecturas soportadas actualmente.

Como nota, el printf (3) página de manual define %S como equivalente a %ls, que toma un puntero a algunos wchar_t caracteres (wchar_t *).

La documentación Cocoa se conectó a (y su equivalente CF), sin embargo, no definir %S separado:

• %S: array terminada en nulo de 16 bits caracteres Unicode

Énfasis agregado. Además, lo mismo vale para %C.

Por lo tanto, esto no es un error. CF y Cocoa interpretan %S y %C de manera diferente a cómo printf y sus primos los interpretan. CF y Cocoa tratan al personaje (s) como UTF-16, mientras que printf (presumiblemente) los trata como UTF-32.

La interpretación CF/Cocoa es más útil cuando se trabaja con servicios principales, ya que algunas API (como el Administrador de archivos) le entregarán el texto como una matriz de UniChar s, no una cadena CFS; siempre y cuando finalice nulo esa matriz, puede usarla con %S para imprimir la cadena.