Discussion :

[Invité]

Là j'ai un peu de mal à suivre.
Soit le caractère 128 == 0x80 = 10000000 == 'ç' .
Le bit de poids est 1, pourtant c'est un caractère ASCII page de code Latin 1 (je suppose)
Il me semble que la notion d'Unicode s'intercale entre celle d'UTF-8 et de code ASCII. Je ne me suis jamais penché en détail sur ce sujet, je n'en ai pas eu l'occasion, mais j'ai relu mon bouquin.
Je pense que la meilleure solution pour Imad-Ing est de fait une impression, juste après la lecture d'une ligne du fichier XML, et avant tout traitement.
Je pense aussi qu'un sizeof(<ce qu'on lit>, ou strlen ou je ne sais quoi, permettrait d'être sûr du nombre d'octets lus et imprimés.

@ Imad-ing
N'hésitez pas à m'envoyer un bout de votre XML.

[Imad_ing]

@ Pierre Dolez
Voilà l'entête de mon xml:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<?xml version="1.0" encoding="UTF-8"?>
<factureSimple codeClient="1" codeCommune="30000" pays="MAR" langue="FR" xmlns:xsi="

Et voilà un bout du fichier XML:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<totauxFacture>
		<montantHT>107.03</montantHT>
		<montantTVA>21.41</montantTVA>
		<raisonTVA/>
		<montantTTC>128.44</montantTTC>
		<montantADeduire>128.44</montantADeduire>
		<montantTTCaPayer>0</montantTTCaPayer>
		<montantFacturesPrecedentes>0</montantFacturesPrecedentes>
	</totauxFacture>
	<infoAbonnement numContrat="12345678">
		<msisdn>212660000000</msisdn>
		<typeAbonnement>Forfait Maitrisé</typeAbonnement>
		<indicForfait>N</indicForfait>
		<indicFactureDet>N</indicFactureDet>
	</infoAbonnement>
	<grpFraisAbonnement>
		<fraisAbonnement codeFrais="MensCoIt" idBloc="0400">
			<dateDebut>2009-09-01</dateDebut>
			<dateFin>2009-09-30</dateFin>
			<desCourte>FM6H</desCourte>
			<des>Forfait maitrisé 6h30</des>
			<montantHT>400.00</montantHT>
		</fraisAbonnement>
		<fraisAbonnement codeFrais="MensCoIt" idBloc="0400">
			<dateDebut>2009-10-01</dateDebut>
			<dateFin>2009-10-31</dateFin>
			<desCourte>FM6H</desCourte>
			<des>Forfait maitrisé 6h30</des>
			<montantHT>400.00</montantHT>
		</fraisAbonnement>
        </grpFraisAbonnement>

Avez vous vu la bibliothèque que j'ai envoyé ? Je pense qu'elle est super intéressante

Bonne réception

[Invité]

Donc, effectivement, c'est encodé en UTF-8 : c'est indiqué dans la première ligne.
Par contre, lorsque je le copie (copier-coller) dans un fichier vide de mon éditeur, que je le sauve, puis que je l'ouvre, c'est codé sur 1 caractère.

J'ai regardé les fonctions encode et décode base64, elle ne vous conviendront pas, parce que il n'y a que les chiffres, les lettres non accentuées le + et le /.

J'ai bien "Forfait Maitrisé" avec le bon accent.

Donc, il semble que le passage de UTF-8 en ASCII se fait correctement et automatiquement, pas contre il s'agit, à mon avis, d'un problème de page de code.
Donc, vraiment je pense que le plus simple pour vous est de faire la transformation des caractères bizarres en caractères accentués, là, il suffit de faire un passage, de noter les transformations et de rajouter le petit traitement juste avant l'impression (pardon, l'écriture) et le passage suivant devrait être bon. Cette transformation sera toujours vraie. C'est tout de même pas à négliger.
Ce changement de page se fait à un endroit qu'il serait plus difficile à trouver.
Autre chose, à mon avis, il manque le 0 terminal. Même si vous faites des impressions avec iostream, il est préférable de le rajouter.
De toute façon, ce n'est pas une anomalie, mais il faut le corriger parce que c'est pas joli.

[nikko34]

ASCII c'est de 0 à 127, 'ç' n'y est pas.

[Invité]

Pardon, oui, j'ai compris la nuance.
L'article de Wikipétia parle d'abus de langage. J'aurais dû dire ASCII étendu.
Mais ça ne résout pas le problème, comment faire pour qu'un 'ç' soit bien un 'ç' ?
L'article de Wikipédia donne des tables de code (que je n'ai pas retrouvé dans mes documents)

[nikko34]

Eh bien comme je l'ai dit dans mon post précédent (si on parle bien de la meme chose).

'ç' en UTF-8 c'est deux octets -deux caractères dans une string- (en hexa): C3 A7

Comme on l'a vu, quand on a C3 dans le premier octet, on prend le deuxième et on ajoute 40: A7+40 = E7

Et dans la table Latin 1 iso_8859-1 on a bien : E7: ç


non? ou j'ai pas compris un truc?

[white_tentacle]

C'est pierre qui a manqué une subtilité : le copier-coller de windows fait la transcription utf-8 vers cp-1252 (en général) au besoin.

Pour convertir entre différents encodages, il y a libiconv. Ou alors, passer par un wofstream et les imbue qui vont bien lorsqu'on écrit le fichier.

A noter que le fichier produit est juste, et qu'il est simplement dans le tort du programme utilisé pour le lire (bloc-notes) de ne pas proposer une option pour le lire dans son format (bloc-notes se base sur les bom, mais elles n'ont rien d'obligatoire et au contraire, sont évitées sur tous les systèmes non-windows).

[Matthieu Brucher]

Mais comme de toute façon, le C++ est une extension du C on ne peut rien me reprocher.

Si, c'est une erreur, le C++ n'est plus une extension du C. Un code C correct n'est pas compilable avec un compilateur C++.

[Imad_ing]

Pour convertir entre différents encodages, il y a libiconv. Ou alors, passer par un wofstream et les imbue qui vont bien lorsqu'on écrit le fichier.

Le problème se pose pour moi au moment de la lecture de mon fichier xml; parce que j'ai fait un test, et j'ai affiché une chaine de caractères contenant des caractères accentués et le ç, et sa s'affiche bien.
Mais quand j'affiche directement du fichier xml, dans la console windows, c'est là que se pose le problème: j'obtient des trucs illisible si je peux me permettre de le dire.
Encore un autre problème encore plus dangereux pour moi, c'est que j'ai pensé à faire un traitement sur la donnée que j'extrais du xml, et chercher les caractères lus genre 'é', puis les remplacer par le caractère initial 'é', mais sous Unix, qui me dit que j'aurai 'é' à la place d'un 'é' ?
Donc, C++ va me rendre dingue !!

[Invité]

Bonjour,
Mais comme l'a dit Nikko, on en a déjà parlé. Je ne cherche en aucun cas à rouvrir le débat, mais je répète ce qu'a dit un modérateur sur ce site, j'ai demandé un exemple de code C (logique et correct) que le C++ ne supporte pas, on m'a renvoyé un lien de la FAQ qui ne répondait en rien à ma question.
Alors, s'il vous plait cessez de me poursuivre, moi, j'essaye simplement d'aider Imad-ing, et les problèmes de langage ne m'intéressent pas. La seule chose qui m'intéresse est d'essayer d'aider quelqu'un à se dépatouiller avec un fichier qu'il essaye de sortir.

@ White-tentacle,
Qui a parlé de Bloc-note ? Surement pas moi, j'ai parlé de MON éditeur.
En fait, je voulais constater que le binaire contenait bien 1 octet par caractère. Soit la transformation s'est faite entre le fichier d'origine et la copie sur le post, en pièce jointe, mais comme j'ai fait une copie d'écran, jpeut-être que l'OS de Windoxs a pu intervenir. De toute façon, le problème reste le même, il faut sortir un fichier texte où les lettres accentuées sont correctement reproduites.

@Imad-ing

Pour convertir entre différents encodages, il y a libiconv. Ou alors, passer par un wofstream et les imbue qui vont bien lorsqu'on écrit le fichier.

[Matthieu Brucher]

Ou comme l'original est en UTF8, changer le display de l'éditeur pour indiquer qu'on fait de l'UTF8.

[gl]

Cool.

Mais que pensez vous de cette bibliothèque ?

Aucun rapport avec ton problème.

Les fonctions présentées dans ce lien permettent de convertir vers et à partir de base64, il n'y a strictement aucun rapport avec les différents jeux de caractères.

En simplifiant, base64 est un encodage utilisant un nombre réduit de caractères imprimables. L'utilité de base64 est de convertir des flux binaires pouvant contenir n'importe quel valeur vers une représentation ne comportant que des caractères (et réciproquement) afin d'intégrer des données binaires quelconque dans un support purement texte (par exemple pour envoyer des images GIF dans un protocole orienté texte).

Là j'ai un peu de mal à suivre.
Soit le caractère 128 == 0x80 = 10000000 == 'ç' .
Le bit de poids est 1, pourtant c'est un caractère ASCII page de code Latin 1 (je suppose)

Non.

Il 'ç' n'est pas dans ASCII (ni aucune lettre accentuée d'ailleurs). ASCII est un codage sur 7 bits.
Il n'y a pas différentes pages de code en ASCII.
Et enfin latin1 n'a rien à voir avec ASCII.

Latin1 (ou ISO/CEI 8859-1) est la première partie de la norme ISO 8859 qui défini différents charset. Latin est celui qui correspond aux langues de l'Europe de l'ouest (bien que tous les caractères ne soient pas présents).

Latin1 inclus l'ASCII (comme de nombreux autres jeux de caractères) mais n'est pas équivalent.

Donc, effectivement, c'est encodé en UTF-8 : c'est indiqué dans la première ligne.
Par contre, lorsque je le copie (copier-coller) dans un fichier vide de mon éditeur, que je le sauve, puis que je l'ouvre, c'est codé sur 1 caractère.

J'ai bien "Forfait Maitrisé" avec le bon accent.

Donc, il semble que le passage de UTF-8 en ASCII se fait correctement et automatiquement, pas contre il s'agit, à mon avis, d'un problème de page de code.

Le texte dans ton éditeur n'est pas en UTF-8 (et les pages du forum non plus, c'est de l'ISO 8859-1).

En outre ce n'est pas parce que le copier/coller, un éditeur de texte ou un utilitaire quelconque convertit de manière transparente de l'UTF-8 en ASCII (ou tout autre conversion d'ailleurs) que l'on peut attendre le même résultat partout.

Encore un autre problème encore plus dangereux pour moi, c'est que j'ai pensé à faire un traitement sur la donnée que j'extrais du xml, et chercher les caractères lus genre 'é', puis les remplacer par le caractère initial 'é', mais sous Unix, qui me dit que j'aurai 'é' à la place d'un 'é' ?

Les différentes consoles n'utilisent pas toutes le même jeu de caractères (et c'est également pour les éditeurs et autres utilitaires).

Tout comme white_tentacle je te recommande libiconv qui est un peu le couteau suisse de l'encodage de caractères.

[white_tentacle]

Tout comme white_tentacle je te recommande libiconv qui est un peu le couteau suisse de l'encodage de caractères.

En fait je crois qu'avant il faut acquérir un peu de connaissance sur les problématiques d'encodage de caractère, faute de comprendre ça je pense que c'est le casse-pipe assuré.

Wikipedia (http://fr.wikipedia.org/wiki/Codage_de_caract%C3%A8res) donne un minimum, et des pistes pour aller plus loin.

Après, je recommande de jouer avec un éditeur qui permette de choisir l'encodage lorsqu'on affiche un fichier texte (sous linux la plupart le font, sous win c'est la galère, mais on peut utiliser firefox par exemple pour lire le fichier et changer l'encodage).

[nikko34]

surtout si c'est juste pour que ça soit joli sous la console de windows.

sinon sous Linux normalement ta console (et le reste) reconnaîtra l'UTF-8 automatiquement et tu n'auras pas de problème de visualisation!

[Imad_ing]

Effectivement.
J'ai ouvert mon fichier sous Unix, et ça marche très bien! Pas de encodage bizarre; soit en forçant l'écriture du fichier en UTF-8 ou pas.

[Klaim]

C'est exclusivement l'affichage de la console qui n'est pas dans le bon encodage. Il me semble qu'il n'est pas possible de le changer sous windows mais je peux me tromper.
Dans tous les cas, si tu dois afficher du non-ascii sous windows, oublie la console, c'est une perte de temps.

[bacelar]

SetConsoleOutputCP

http://msdn.microsoft.com/en-us/libr...36(VS.85).aspx

oublie la console, c'est une perte de temps

Aussi

[Klaim]

J'ajoute qu'éventuellement utiliser une console générée via Qt est peut être une meilleure solution lorsqu'on a absolument besoin d'une console, encore plus quand on veut que sont comportement soit le même sur toutes les plateformes.
Cela dit, cela impose d'avoir un systeme d'affichage graphique sur les plateformes en question...