caractères spéciaux dans @" ..."

Philippe49Philippe49 Membre
17:56 modifié dans API AppKit #1
Comment introduire un caractère accentué dans une chaà®ne @... ?
Par exemple, je veux mettre @Molière et le code UTF-8 de 'è' est \U+00E8

Réponses

  • schlumschlum Membre
    17:56 modifié #2
    Il faut le mettre dans un Localized.strings (encodé en UTF-8 par exemple), et le récupérer avec NSLocalizedString
  • 17:56 modifié #3
    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.
  • schlumschlum Membre
    17:56 modifié #4
    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  ;)
  • Philippe49Philippe49 Membre
    17:56 modifié #5
    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 @ ... ?
  • schlumschlum Membre
    17:56 modifié #6
    dans 1187444305:

    Et il y a pas plus simple ?



    La solution de Renaud est simple, non ?

    Sinon, la localisation, une fois qu'on a créé son fichier, c'est très simple aussi  ???

    La localisation ne répond pas à  des caractères comme les symboles flèches, celle de commande, celle de controle, les dingbats, etc ...


    Ce qui veut dire ??

    Avez-vous une idée de la doc liée aux caractères acceptés par @ ... ?


    Les caractères ASCII

  • août 2007 modifié #7
    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).

    ☺
  • Philippe49Philippe49 Membre
    août 2007 modifié #8
    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



     
  • Philippe49Philippe49 Membre
    17:56 modifié #9
    dans 1187442623:

    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.


    L'article de CocoaDev conclut aussi ainsi.
  • Philippe49Philippe49 Membre
    avril 2008 modifié #10
    La question de chaps31 m'a fait revenir sur ce post.

    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
  • Philippe49Philippe49 Membre
    17:56 modifié #11
    Il est par ailleurs assez rigolo de voir le résultat de
    NSString * s=[NSString stringWithFormat:@Moli%Cre,'è'];

    Moli쎨re
  • MalaMala Membre, Modérateur
    17:56 modifié #12
    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.
  • AliGatorAliGator Membre, Modérateur
    17:56 modifié #13
    dans 1207239651:
    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 ?)
Connectez-vous ou Inscrivez-vous pour répondre.