Écriture simultanée dans plusieurs fichiers

Bonjour tout le monde.
Je suis en train de développer une application en C++, et cette application va devoir me sortir comme résultat 3 fichiers plats (TXT):
- Le premier sera pour le résultat du traitement de mon programme
- Le deuxième pour les statistiques
- Le troisième pour le log des erreurs.
Ma question est la suivante:
Est ce que je peux, en toute sécurité, écrire simultanément dans ces trois fichiers? C'est à dire, est ce que je peux, au début de mon programme, localiser mes trois fichiers, les ouvrir en création, et écrire à chaque fois qu'il y a besoin, l'information nécessaire dans le fichier adéquat?
J'ai demandé à droite à gauche, on m'a dit que non, mais ce qui me casse la tête, c'est surtout si la quantité de données que j'aurai à traiter serait trop grande? et aussi si le programme ne trouvera pas de problème à se localiser dans l'un des fichiers à ma demande ?

Une solution qu'on m'a proposé: Créer mes fichiers au début du programme, ne les ouvrir en mode modification qu'en cas de besoin, et les refermer après chaque utilisation.
Est ce que ça n'a pas d'impact sur le temps de traitement? Sachant que la volumétrie de mes données risque d'être trop grande? D'où l'ouverture et la fermeture de mes fichiers serait une tâche à faire et à refaire ?


Merci d'avance pour vos réponse.

Il n'y a aucun problème pour conserver les 3 fichiers ouverts en même temps et à écrire dedans au fur et à mesure.

Oui, la seule condition c'est qu'il n'y ait pas d'accès concurrentiels (en écriture seulement?). C'est la base pour tout ce qui est "parrallèlisme".

Citation:

---

Oui, la seule condition c'est qu'il n'y ait pas d'accès concurrentiels (en écriture seulement?). C'est la base pour tout ce qui est "parrallèlisme".

---

J'ai pas bien saisi ce que tu veux dire par " Accès Concurrentiels " ? :aie:

Pour mes fichiers, je compte les ouvrir tout les trois au début de mon programme en mode création, leurs attribuer un fileName.
Puis, et au fur et à mesure de mon besoin, j'écrirai dans le fichier adéquat l'information souhaité.
Ce n'est qu'à la fin de mon programme que je vais fermer mes trois fichiers.

Merci pour vos réponse, et encore merci pour ton retour Klaim :ccool:

Je dirai comme Mathieu, aucun problème.
Un problème arriverai par contre si tu écrivais dans un même fichier depuis 2 threads différents. Mais ça n'a pas l'air d'être ton cas. ;)

Bonjour,
Sauf la capacité de la machine, il n'y a pas de limite au nombre de fichiers ouverts, en écriture et/ou en lecture. A condition, naturellement, que le même fichier ne soit pas ouvert plus d'une fois en même temps.
Il y a 2 fonctions qui permettent le contrôle d'état d'un fichier, access() et fstat(), mais leur portabilité n'est pas garantie.
Sous DOS, le nombre de fichiers ouverts en même temps était limité. Pour des applications compliquées, cela pouvait devenir pénalisant.

La quantité de données à écrire est une notion indépendante du nombre de fichier ouverts.
Il ne faut pas fermer un fichier pour une raison autre que celle de ne plus en avoir besoin.
Enfin, n'oubliez pas qu'il y a différents modes d'ouverture des fichiers.
Bon développement.

:ccool: :ccool:

Super les gars. Voilà pourquoi j'aime ce forum.

Merci beaucoup encore une fois.

Citation:

---

Envoyé par Imad_ing

3 fichiers plats

---

Merci à toi, je ne connaissais pas l'expression :mrgreen:

Bonjour,
Pardon pour cette petite remarque :
Un fichier est une suite de bits. On peut grouper ces bits en octets, et c'est ce qu'on fait généralement.
Un octet correspond à un caractère, pas forcément alphabétique ou numérique (en gros entre 33 et 128 plus éventuellement des caractères accentués, si on connait la table de code).
Qu'est-ce qui distingue un fichier TXT d'un fichier binaire ? réponse l'interprétation des 32 premiers caractères (au moins de certains des 32 caractères et en particulier Fin de Ligne et Retour Charriot : CRLF 0x0D et 0x0A)
Alors la différence d'écriture entre un fichier TXT et un fichier binaire (par exemple un raster ou un .EXE) ne réside que dans le choix d'interprétation de ces caractères de contrôle.

Ceci m'a été provoqué par la très jolie dénomination de fichier "plat" pour un fichier TXT. Appelle-t-on "creux" un fichier binaire? :P
Cordialement

Mr Pierre Dolez,

Citation:

---

Appelle-t-on "creux" un fichier binaire?

---

Vous auriez du faire cette remarque dès le début de votre intervention pour m'aider à mieux m'exprimer. Mais merci comme même parce que moi au fait, je connaissais pas cette nomination, et je n'ai fait qu'apprendre le terme à travers les gens Métiers (Mes Clients)! Merci encore ;)

Mr jblecanard

Citation:

---

Merci à toi, je ne connaissais pas l'expression

---

Mais de rien! Régales toi mon frère 8-)

Mais aujourd'hui, j'ai un autre problème, est c'est pour cela que je vais réouvrir cette discussion: Après avoir parsé mes fichiers XML avec TinyXML, je constitue des lignes dans une chaine de caractères, et chaque ligne est constitué de concaténation de plusieurs données en provenance de plusieurs balises.
Le problème est que lorsque je copie cette chaine de caractère dans mon fichier PLAT de sortie :mrgreen:, j'obtient dans mon fichier des caractères genre

Citation:

---

Forfait Maitrisé

---

au lieu d'avoir

Citation:

---

Forfait Maitrisé

---

.
J'ai cherché sur internet, et j'ai trouvé que TinyXML supporte l'UTF8, et la méthode que j'utilise pour copier ma chaine de caractères dans le fichier est :

Code:

---

MonFichier >> MaLigne >> endl

---

de la classe ofStream qui dérive de std::ios_base.
Donc ma question est: Quel type de sortie nous offre ofStream ? et y'a t'il une autre méthode pour garder mes caractères tel qu'elles sont sur le fichier XML?

Merci d'avance pour vos réponse.

Cordialement

Bonjour,
Ce type de problème ne date pas d'hier.
La table de caractère comporte 256 cases (de 0 à 255). Les 32 premiers son reservés. Les caractères 33 à 127 sont normalisés.
Par contre, les caractères 128 à 255 sont différents d'un table à l'autre.
Je ne vous donnerai pas la solution, parce qu'à mon avis, elle dépend de pas mal de choses que j'ignore.
Pour que je comprenne mieux il me faudrait plus de détails, par exemple, la chaine que vous appelez "LaLigne" et que vous écrivez, d'où vient-elle ?
Si je craignais les foudres des C++istes, j'arrêterais là.:mrgreen:

Essayer de faire une ouverture de fichier "Standard" et une écriture "Standard". On obtiendra certainement la même chose, mais un petit essai ne coûte rien.

Code:

---

1 2 3 4 5 6 7 8

FILE *ecr = fopen("Fichier_essai.txt","wt"); if (ecr) { ... // création de MaLigne fprintf(ecr,"%s\n",MaLigne); ... // suite fclose(ecr); }

---

Cordialement.

Merci tout d'abord pour ta réponse rapide. :)

Au fait, le but de mon programme est de transformer un fichier XML en un fichier txt. Ce fichier txt a bien une structure à respecter: (L'ordre des information dans chaque ligne commençant par un code spécifique.) Car dans le programme qui va prendre mon fichier txt, lui il lit les informations depuis une position donnée, et sur un nombre défini de caractères.

Voilà un exemple de ligne du fichier txt de sortie que je dois avoir:

Citation:

---

MAR100003 FR0300 0101190001011900000000173058

---

Donc, pour écrire ces données dans la ligne, je dois chercher chaque info à part, vu qu'elles ne se trouvent pas dans le même bloc de mon fichier xml, et les concaténer dans une variable string, et ce pour pouvoir construire ma ligne.

Une fois ma ligne est construite, je la copie dans le fichier txt et j'effectue un retour chariot.

Voilà un exemple de bloc xml d'ou proviennent mes données:

Code:

---

1 2 3 4 5

<ligneResumeClient categorie="" codeItem="MensCo" idBloc="0300"> <dateDebut>2010-06-01</dateDebut> <dateFin>2010-06-29</dateFin> <montantHT>432.39</montantHT> </ligneResumeClient>

---

Donc, si vous remarquez bien, dans ce bloc xml, j'ai le code ma ligne qui est

Citation:

---

idBloc="0300"

---

, mais pas toutes les informations qui constituent ma ligne ne se trouve dans ce bloc. ( Il y a d'autres informations en provenance d'autres balises ou d'autres blocs )

Quand je visualise mon fichier, je trouve que les données qui contiennent les caractères accentués sont affichés différemment.

J'espère que ça t'aidera à m'aider :?

Et merci encore pour tes réponses et tes clarifications.


Cordialement

J'ai oublié un truc :aie:

En effet, l'utilisation de fprintf me génère une erreur au niveau de la mémoire.
Lorsque j'exécute, ça retourne une erreur.
Même en faisant le test avec une simple chaine de caractère se composant de 4 caractères, en pensant que fprintf aurait une contrainte sur la longueur des chaines de caractères; mais apparemment ce n'est pas le cas.


Cordialement

tu as écris en UTF-8 en fait dans ton fichier texte, du coup tu as deux octets pour un caractère.

Si tu veux écrire en ASCII à partir de l'UTF-8, il faut que tu convertisses l'un dans l'autre (bon ça marchera pour le français).

( Sinon Pierre a vite tendance à revenir au C hein! )

Citation:

---

Si tu veux écrire en ASCII à partir de l'UTF-8, il faut que tu convertisses l'un dans l'autre

---

Vous n'auriez pas un exemple ? Car je n'ai jamais fait une chose pareille.:calim2:

Merci d'avance

@ imad-ing
Je pense que la solution est dans les toutes premières lignes du fichier XML.
C'est là qu'il y a la définition de la table de code utilisée.
Sinon, il y a une solution un peu brutale mais qui a l'avantage de marcher dans tous les cas, c'est de faire une table de correspondance.
Ce n'est pas du tout pénalisant en durée de traitement.
Ca peut être fait sous forme d'un switch:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

for (i=0; i<strlen(ligne); i++) { char c=ligne[i]; switch(c) { case 128: ligne[i]=212; break; case 129: ligne[i]=221; break; case '¤' : ligne[i]='à'; break; .... default : break; } }

---

Naturellement les 128, 129, 212, 221 sont au hasard.
La syntaxe de la 3è ligne est aussi correcte et un peu plus claire.

Concernant l"erreur générée par fprintf, il s'agit peut-être de caractères sur 2 octets, mais il s'agit pet-être aussi d'absence de 0 terminal, ce qui expliquerait qu'il y a un caractère de trop dans "Forfait Maitrisé".

@ Niko34
Oui, je l'avoue. Il y a une quinzaine d'années, lorsque je suis passé du C au C++, après avoir bien compris l'utilité des classes, j'ai voulu utiliser iostream qui est à priori un bonne première approche, je n'ai trouvé aucun avantage par rapport à mes fprintf(), fgetc(), fgets(), fread(), fwrite(), et je n'utilise pas cette librairie. Mais comme de toute façon, le C++ est une extension du C on ne peut rien me reprocher.
D'ailleurs, un langage en lui-même n'offre aucun intérêt, c'est le développement qui est intéressant.
Il devrait y avoir une section "Algorithme" dans ce forum.
Mais "faute avouée est à moitié pardonnée".

La théorie des 4 couleurs dit que l'on peut colorier des zones adjacentes, par exemple les départements français en utilisant seulement 4 couleurs et sans que 2 zones adjacentes n'aient la même couleur.
C'est ce type de problème qui m'intéresse, alors, C ou C++, quelle importance?
Cordialement.

Bonjour

Citation:

---

Envoyé par Pierre Dolez

Il devrait y avoir une section "Algorithme" dans ce forum.

---

Cela existe mon cher, ici même. ;)

Merci beaucoup, ça, ça m'intéresse.

(je vais pas revenir sur le débat C <-> C++ qu'on a déjà eu)

Pour passer de l'UTF-8 à Latin 1 ( et pas ASCII en fait ) il faut savoir:

que la taille d'un caractère en UTF-8 peut-être de 1, 2, 3 ou 4 octets.

Le nombre d'octet dépend du premier octet.

Si dans le premier octet le bit de poids fort est 0, alors on aura qu'un seul octet, et cet octet sera équivalent au caractère ASCII.

Si le premier octet est égal à "0xC2" alors le caractère sera codé sur 2 octets et tu peux trouver l'équivalent Latin 1 dans le 2e octet

Si le premier octet est égal à "0xC3" alors l'équivalent Latin 1 sera le deuxième octet plus "0x40".

Et je crois que ça devrait suffire pour le français...

Cool.

Mais que pensez vous de cette bibliothèque ?

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.

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

Code:

---

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:

---

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

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.

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

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)

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?

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).

Citation:

---

Envoyé par Pierre Dolez

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++.

Citation:

---

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. :calim2:
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 'é' ? :roll:
Donc, C++ va me rendre dingue !!:aie:

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

Citation:

---

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.

---

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

Citation:

---

Envoyé par Imad_ing

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).

Citation:

---

Envoyé par Pierre Dolez

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.

Citation:

---

Envoyé par Pierre Dolez

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.

Citation:

---

Envoyé par Imad_ing

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.

Citation:

---

Envoyé par gl

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).

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!

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.

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.

SetConsoleOutputCP

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

Citation:

---

oublie la console, c'est une perte de temps

---

Aussi :aie:

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...