NSString vers html
tablier
Membre
Je souhaite faire des strings html représentatifs de NSString divers et variés
Existe-t-il une méthode conseillée pour cela.
J'ai essayé avec une table de codage. En partant d'un string C (codé Mac OS Roman), j'utilise la valeur ascii des caractères comme index de la table. Cela marche très bien.
Malheureusement, je n'arrive pas à obtenir le string C codé Mac OS Roman en partant d'un NSString.
j'utilise:
Si le NSString phr contient: @ /users/aà¯oli/noël_Pâques \n
je veux obtenir dans buffer: " /users/aà¯oli/noël_Pâques " suivi du caractère de retour à la ligne, suivi d'un nul.
Or j'obtiens : " /users/a\x95oli/no\91l_P\x89ques \n" suivi d'un nul.
Les valeurs \x95, \x91 et \x89 sont bien les les valeurs héxa de ௠ë et â. \n n'est pas traduit en 0D ou 0A non plus!
Quel est le bon moyen pour obtenir ce que je veux?
Mais peut-être faut-il procéder autrement?
Existe-t-il une méthode conseillée pour cela.
J'ai essayé avec une table de codage. En partant d'un string C (codé Mac OS Roman), j'utilise la valeur ascii des caractères comme index de la table. Cela marche très bien.
Malheureusement, je n'arrive pas à obtenir le string C codé Mac OS Roman en partant d'un NSString.
j'utilise:
[phr getCString:buffer maxLength:(unsigned)1022 encoding:NSMacOSRomanStringEncoding ] ;
Si le NSString phr contient: @ /users/aà¯oli/noël_Pâques \n
je veux obtenir dans buffer: " /users/aà¯oli/noël_Pâques " suivi du caractère de retour à la ligne, suivi d'un nul.
Or j'obtiens : " /users/a\x95oli/no\91l_P\x89ques \n" suivi d'un nul.
Les valeurs \x95, \x91 et \x89 sont bien les les valeurs héxa de ௠ë et â. \n n'est pas traduit en 0D ou 0A non plus!
Quel est le bon moyen pour obtenir ce que je veux?
Mais peut-être faut-il procéder autrement?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je ne vois pas pourquoi "produire" des encodages à 8bit (et en particulier MacOSRoman, qui n'est que difficilement lisible sur autre chose qu'un mac), alors que l'unicode peut être lu pratiquement partout, et qu'obtenir de l'unicode à partir d'une NSString est tellement facile.[/mode]
Sinon, la string que tu as dans le buffer est normale, car il ne fait que convertir les "caractères" unicode non ascii en leur "équivalent" macosroman, \n existant en ascii, il n'a pas besoin d'être converti, ce n'est qu'au moment de l'affichage que la conversion en retour chariot est faite.
Maintenant la question est surtout de voir ce que tu dois faire de ta string en roman?
Que me conseillerais-tu pour réaliser ce codage?
Je veux dire que je pense que si tu parcourres réellement ta CString retournée par getCString caractère par caractère (unsigned char par unsigned char) tu auras la bonne valeur.
A mon avis c'est juste au moment de l'affichage dans la console, sans plus.
Voilà là je parcourre buffer caractère par caractère et j'affiche le code ascii à chaque place. Comme tu affiches chaque caractère un par un et en plus sous forme d'entier et non caractère, tu ne devrais plus avoir quoi que ce soit qui s'affiche en \xNN.
Tu peux donc de la même manière parcourir ton buffer caractère par caractère pour appeler les caractères de ton tableau.
De même si tu dois produire du code HTML, tu peux parfaitement le laisser en Unicode, et indiquer dans l'entête de ton fichier html que l'encodage utilisé est unicode. La conversion des caractères non ascii en représentation xml n'est plus nécessaire maintenant. ça l'était il y a un certain temps, mais si tu as bien indiqué dans ton entête que le document produit est en unicode (si rien n'est mis, l'encodage par défaut est le plus souvent ISO-8859-1), aucun navigateur digne de ce nom (encore utilisé) ne sera gêné par le fait que tu mettes é au lieu de é.
avec "charset = UTF-8" dans Camino, FireFox et Safari. ça marche! merci les gars!
avec les versions récentes de Camino, Firefox et Safari j'obtiens pour la phrase "créé à Noël ou à Pâques"
Camino: "créé à Noe¨l ou à Pa^ques"
Firefox: "créé à Noe¨l ou à Pa^ques"
safari: "créé à Noël ou à Pâques"
Donc deux des browsers ont des charset incomplets (ou il y a quelque chose que je n'ai pas compris!)
En effet ta remarque m'a étonné et du coup je viens de faire une page de test très rapido pour vérifier...
Je l'ai testé dans Safari et Firefox (je n'ai pas Camino) et ça marche impec, aucun problème d'affichage de la chaà®ne, qui s'affiche pareil et comme il faut sur les 2 navigateurs.
Le code de la page HTML que j'ai utilisé pour le test :
J'ai vérifié les tags, (entrant/sortant) tout parait correct!
Je mets mon source en pièce jointe car si je le copie-colle dans ce message, les ë deviennent e¨ et les â de viennent a^ !!!!
Nota: il me semble que Firefox et Camino ont le même moteur donc -> même résultat!
[Fichier joint supprimé par l'administrateur]
*il pourrait y avoir un problème si par exemple tu utilises un fichier pour le pied de page qui n'est pas codé en unicode, mais que tu ajoutes en considérant que c'est de l'unicode.
Si j'ouvre le fichier avec BBEdit et que je demande "Show Invisibles" il me met tes "ë" et "â" comme des caractères spéciaux non standards. Si je tape ë et â en plus derrière et que je sauve, les tiens sont toujours affichés bizarement dans Firefox, mais ceux que je viens de taper sont affichés correctement.
Je ne sais pas avec quel soft tu as créé ton code source, mais tu ne dois pas taper les bons codes ASCII pour ces caractères spéciaux j'ai l'impression Â
J'aii ouvert ton fichier avec un éditeur hexa et j'ai vu que pour le ë de Noël le caractère que tu utilisais était codé comme un e (0x65) suivi de 0xCC88 alors que moi quand je tape ë c'est codé comme 0xC3AB (donc toi c'est codé comme un "e" puis un tréma, moi c'est directement le caractère "ë")
De même ton â est codé comme un a (0x61) suivi de 0xCC82 alors que mon "â" est codé 0xC3A2 ???
Je ne sais pas ce qui fait que tes "ë" et tes "â" sont mal encodés (du moins de façon non standard), peut-être que c'est l'encodage UTF16 et non UTF8 pour ces 2 caractères, ou peut-être le soft avec lequel tu as créé ton fichier HTML encode mal, ou s'emmêle entre les encodages, ou encore tu auras codé la page toi même en mettant le caractère dans ton code Objective-C (qui est en MacOS Roman il me semble) en lui faisant croire que c'était de l'UTF-8...
Bref je sais pas avec quel moyen tu as crée ton fichier mais c'est pas normal la façon dont il encode tes accents, en tout cas pas la plus standard ou la plus courante. ::)
Oui ou alors en effet Safari qui supporte un jeu plus large (plus complet) de l'encodage UTF-8 (définition d'un caractère accentué par le caractère + l'accent, en 2 temps) que Firefox ne gère pas...
Mais dans tous les cas ça m'a l'air d'être un encodage bizarre de tes caractères accentués... ou un range peu usité/supporté de l'encodage UTF-8 (que Safari sait gérer, pas Firefox)
Il semble que de tout les logiciels que j'utilise, seuls Firefox et Camino ne comprennent pas le codage de Popchar!!!
Xcode, Word, Excel, NeoOffice, TextEdit, Nvu, Eudora,...etc ne donnant aucune erreur d'affichage, je penche
pour une limitation du support d'UTF8 dans Firefox et Camino.
De toute façon, merci et à la bonne vôtre.
Car dans les autres logiciels en effet ton document s'affiche correctement du moment qu'il le lit en tant que texte UTF-8...
Mais l'encodage utilisé par tes caractères étant "e" + "accent" (en 2 temps) ça explique un petit peu l'affichage à tort de Gecko, qui affiche bien la lettre, puis l'accent, même s'il devrait en effet affecter l'accent à la lettre qui le précède et non le mettre à part comme il le fait.
Un petit bugreport à l'équipe de Firefox ?
J'ai écrit la page de test d'Aligator (voir plus haut). Quelque soit le browser utilisé, le défaut n'apparait pas!
J'ai créé un dossier nommé "Noël Pâques". Dans la page de test, j'ai ajouté un < br> après "créé à Noël ou à Pâques".
Puis j'ai sélectionné le nom du dossier et je l'ai copier-coller après le < br>. Et là , le défaut réapparait (avec Firefox et Camino).
Du coup, je ne sais pas si le bugreport est à envoyer à Apple en raison d'un mauvais traitement du Glisser-déposer ou à Bugzilla pour le traitement insuffisant de l'utf-8.
- Apple, au moment de convertir l'UTF-16 (utilisé pour les noms de fichiers dans le Finder) en UTF-8, utilise la 2e écriture du "ë" et du "â" (e + accent, a + accent, au lieu du code de la lettre "ë" ou "â" directement).
En soit si c'est bien la faute à Apple si cette conversion UTF-16 vers UTF-8 donne ça, ce n'est pas un bug en soi, car l'écriture de "ë" sous cette forme est tout à fait correcte et Unicode-compliant me semble-t-il. Certes c'est une forme de codage moins usitée pour le "ë" que de coder directement le caractère "ë", mais elle est valide (enfin je suis pas allé vérifier dans les standards UTF8 mais bon tout semble montrer qu'elle l'est)
- Gecko ne reconnait pas le codage UTF-8 qui s'effectue de la sorte (lettre + accent au lieu de lettre accentuée directement), donc le décode mal.
Les autres logiciels semblent, dans l'ensemble, bien comprendre ce codage alternatif des lettres "ë" et "â" et les afficher correctement, du moins pour la plupart des softs.
Donc certes Apple (si c'est bien de sa faute) fait une conversion de ces caractères vers un codage que l'ont a moins l'habitude de voir, mais ce codage semble valide, et c'est plutôt Gecko dans ce cas du coup que je jugerait coupable, de ne pas correctement interpréter toute la gamme de possibilités du standard UTF8.
J'ai regardé le contenu du fichier.
Le problème vient de Firefox/Camino : ils interprètent mal la norme UNICODE.
Prenons l'exemple de la lettre â du mot "Pâques".
Dans le fichier fourni par Tablier, on y lit (je donne les lettres en ligne 1, et leur valeur hexadécimale en ligne 2) :
[tt]P  â      q  u  e  s
50Â 61Â CCÂ 82Â 71Â 75Â 65Â 73
[/tt]
Maintenant, décodons la séquence UTF :
â = 61 CC 82.
En binaire, cela s'écrit 01100001 11001100 10000010.
En UTF8, tout octet commençant par le motif binaire 110 signifie qu'il s'agit du début d'une séquence multi-octets pour représenter 1 caractère.
Chaque octet supplémentaire commence par le motif binaire 10.
Ici, un seul octet commence par 10. Donc la valeur finale du caractère UTF est donc :
11001100 10000010 soit 0110000010 (les motifs préfixes sont retirés).
En hexa, cela représente la valeur 302.
Or dans la table UNICODE, 302 fait partie du [url=http://fr.wikipedia.org/wiki/Table_des_caractères_Unicode/U0300#Diacritiques]bloc 300-36F[/url], qui est le bloc des diacritiques combinatoires.
302, dans ce bloc est le symbole ^.
Une diacritique combinatoire est un signe qui se combine (se superpose) au caractère précédent.
Dans notre cas, le caractère précédent est a, donc le résultat est â !
Firefox/Camino ne combinent pas, ils ne font que se faire suivre les 2 symboles.
Toutefois, utiliser 61 CC 82 pour â n'est pas la meilleure (plus fiable) solution en UTF8.
En unicode, la lettre â existe et a pour code hexa E2 (voir le bloc A0-FF qui est le bloc "Supplément Latin-1 ou ISO 8859").
Dans le fichier, E2 se code ainsi : C3 A2.
En binaire ça donne 11000011 10100010.
Après exclusion des motifs préfixes, cela donne : 11000011 10100010 ou 00011100010, soit E2 en hexa.
Au final, "Pâques" s'écrirait ainsi dans le fichier :
[tt]P  â    q  u  e  s
50Â C3Â A2Â 71Â 75Â 65Â 73[/tt]
C'est cette méthode que tout le monde utilise, et que Firefox/Camino utilisent.
Voilà , cette longue digression est terminée.
Pardonnez l'aspect technique et rébarbatif... (pour moi ça a permis de me remémorer mes cours).
.
Si on utilise une police qui ne contient pas ce jeu de caractères, l'affichage est tout à fait normal (Tahoma, Verdana, Trebuchet, Comic,...) .
je ne pensais pas qu'un simple post sur ce bug qui m'embete allait nous entraà®ner aussi loin.
Merci a vous tous pour vos explications et particulièrement à Bru pour le rappel.
J'ai envoyé un Bug report à Bugzilla pour ce problème, et je vais en revenir aux tag html
pour le cas qui m'interesse car je ne peux connaà®tre à l'avance le browser qui sera utilisé.
A+
:adios!:
déjà été reporté quelques mois après la sortie du browser. J'abandonne!!
Nous fe^terons donc Noe^l le 25 Décembre.
>:( Grrrrrrrrrrrr!