Sinon autre façon: [tt]NSLog([NSString stringWithFormat:@Moli%Cre,0x00E8]);[/tt]
Ceci dit, la solution préconisée par schlum est meilleure à mon sens, dans le sens où le code ne doit jamais contenir d'éléments localisés. Par contre si c'est pour des symboles unicode, là la mienne est plus adaptée.
En règle général, le code ne doit jamais contenir de chaà®nes qui vont être directement affichées dans l'interface graphique... (sauf évidemment cas rare) Le système de localisation est assez bien foutu, profitons-enÂ
Et il y a pas plus simple ? La localisation ne répond pas à des caractères comme les symboles flèches, celle de commande, celle de controle, les dingbats, etc ... Avez-vous une idée de la doc liée aux caractères acceptés par @ ... ?
La localisation permet d'insérer des symboles et autres dingbats. Les fichiers .strings devant être codés en UTF8, tu peux mettre dedans n'importe quel caractère reconnu par UTF8.
Une fois que l'éditeur de texte du fichier .strings est réglé sur UTF8, il te suffit d'utiliser la palette des caractères (Edit->Special Caracters... dans Xcode). Et là tu trouves ton caractère et tu double-cliques dessus pour l'insérer dans ton texte (ou drag & drop).
Je comprends bien ce que vous dites, mais je poursuis ma recherche :
dans un programme C, je mets puts("Moli\u00E8re"); gcc me pose le warning : warning: universal character names are only valid in C++ and C99
même pas peur, puisque gcc 4.0 suit la norme C99, ça marche Le warning disparaà®t avec l'option de compilation -std=c99 La lecture de la norme c99 (§ 6.4.3) confirme qu'il y a pas de problème.
dans un programme objective C, je mets NSString * s=[NSString stringWithUTF8String:"Moli\u00E8re"]; Même comportement, logique puisque l'argument est une C-String
Sinon autre façon: [tt]NSLog([NSString stringWithFormat:@Moli%Cre,0x00E8]);[/tt]
Ceci dit, la solution préconisée par schlum est meilleure à mon sens, dans le sens où le code ne doit jamais contenir d'éléments localisés. Par contre si c'est pour des symboles unicode, là la mienne est plus adaptée.
Sans nier que les NSLocalizedString et les fichiers associés sont tout à fait performants, faciles à utiliser, il n'est pas forcément évident que l'on veuille internationaliser l'appli que l'on fabrique. Ne serait-ce que lorsqu'on fait des petites appli de tests ou de débutants.
Dès lors, il me semble que ce serait intéressant de savoir les limites d'utilisation de NSString * s=[NSString stringWithUTF8String:"Moli\u00E8re"]; et la solution de Renaud [NSString stringWithFormat:@Moli%Cre,0x00E8]; A savoir que le premier provoque un Warning sans erreur à l'exécution, alors que le second est accepté tout de go.
Tiens, anecdote amusante sous XCode 3.1, un caractère accentué dans un NSLog ne génère plus de warning et s'affiche correctement dans la console. Pourtant les fichiers sources sont toujours en UTF-8 par défaut.
Pourtant les fichiers sources sont toujours en UTF-8 par défaut.
Tu veux dire en MacRoman par défaut, non ?
peut-être justement une modification de NSLog depuis les dernières builds ? Genre la NSString passée en argument est convertie en UTF8 (inchangée si elle ne l'est pas déjà ) ? (après tout il y a tout ce qu'il faut dans la classe NSString pour ça, non ?)
Réponses
[tt]NSLog([NSString stringWithFormat:@Moli%Cre,0x00E8]);[/tt]
Ceci dit, la solution préconisée par schlum est meilleure à mon sens, dans le sens où le code ne doit jamais contenir d'éléments localisés. Par contre si c'est pour des symboles unicode, là la mienne est plus adaptée.
Le système de localisation est assez bien foutu, profitons-enÂ
La localisation ne répond pas à des caractères comme les symboles flèches, celle de commande, celle de controle, les dingbats, etc ...
Avez-vous une idée de la doc liée aux caractères acceptés par @ ... ?
La solution de Renaud est simple, non ?
Sinon, la localisation, une fois qu'on a créé son fichier, c'est très simple aussi ???
Ce qui veut dire ??
Les caractères ASCII
Une fois que l'éditeur de texte du fichier .strings est réglé sur UTF8, il te suffit d'utiliser la palette des caractères (Edit->Special Caracters... dans Xcode). Et là tu trouves ton caractère et tu double-cliques dessus pour l'insérer dans ton texte (ou drag & drop).
☺
dans un programme C, je mets puts("Moli\u00E8re");
gcc me pose le warning :
warning: universal character names are only valid in C++ and C99
même pas peur, puisque gcc 4.0 suit la norme C99, ça marche
Le warning disparaà®t avec l'option de compilation -std=c99
La lecture de la norme c99 (§ 6.4.3) confirme qu'il y a pas de problème.
dans un programme objective C, je mets
NSString * s=[NSString stringWithUTF8String:"Moli\u00E8re"];
Même comportement, logique puisque l'argument est une C-String
L'article de CocoaDev conclut aussi ainsi.
Sans nier que les NSLocalizedString et les fichiers associés sont tout à fait performants, faciles à utiliser, il n'est pas forcément évident que l'on veuille internationaliser l'appli que l'on fabrique. Ne serait-ce que lorsqu'on fait des petites appli de tests ou de débutants.
Dès lors, il me semble que ce serait intéressant de savoir les limites d'utilisation de
NSString * s=[NSString stringWithUTF8String:"Moli\u00E8re"];
et la solution de Renaud
[NSString stringWithFormat:@Moli%Cre,0x00E8];
A savoir que le premier provoque un Warning sans erreur à l'exécution, alors que le second est accepté tout de go.
Qu'en pensez-vous ?
Signé : Le comité contre les délocalisations ;D
NSString * s=[NSString stringWithFormat:@Moli%Cre,'è'];
Moli쎨re
peut-être justement une modification de NSLog depuis les dernières builds ? Genre la NSString passée en argument est convertie en UTF8 (inchangée si elle ne l'est pas déjà ) ? (après tout il y a tout ce qu'il faut dans la classe NSString pour ça, non ?)