Pourquoi NSString et NSLog semblent-ils gérer% C et% lc (et% S et% ls) différemment?

Question

String Format Specifiers demandes de documents d'Apple,

Le format pris en charge par les spécificateurs méthodes de mise en forme NSString et CFString fonctions de formatage suivre les IEEE printf specification; ... Vous pouvez également utiliser ces spécificateurs de format avec la fonction NSLog.

Mais, alors que la spécification printf définit %C comme équivalent %lc et %S comme équivalent %ls, seulement %C et %S semblent fonctionner correctement avec NSLog et +[NSString stringWithFormat:].

Par exemple, considérons le code suivant:

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

Compte tenu de la spécification printf, je me attends à chacune des paires ci-dessus pour imprimer la même chose. Mais, quand je lance le code, je reçois la sortie suivante:

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: 

que je fais quelque chose de mal, ou est-ce un bug dans le code d'Apple?

Answer 1

Sous Mac OS X, <machine/_types.h> définit wchar_t comme int. Il s'agit donc de quatre octets (32 bits) sur toutes les architectures actuellement prises en charge.

Comme vous le soulignez, le printf (3) définit manpage %S comme équivalent à %ls, qui prend un pointeur sur certains caractères (wchar_twchar_t *).

La documentation Cocoa vous lié (et son équivalent CF), cependant, ne définit %S séparément:

• %S: array zéro terminal de 16 bits caractères Unicode

Emphase ajoutée. En outre, la même chose vaut pour %C.

Donc, ce n'est pas un bug. CF et Cocoa interprètent %S et %C différemment de comment printf et ses cousins ​​les interprètent. CF et Cocoa traitent le ou les caractères comme UTF-16, alors que printf (vraisemblablement) les traite comme UTF-32. L'interprétation CF/Cocoa est plus utile lorsque vous travaillez avec les services principaux, car certaines API (telles que le gestionnaire de fichiers) vous donneront du texte sous la forme d'un tableau de UniChar s, pas une CFString; Tant que vous mettez fin à ce tableau, vous pouvez l'utiliser avec %S pour imprimer la chaîne.