Discussion :

[neokal]

Bonjour � tous,
C'est la premi�re fois que je viens poster sur ce forum. Je d�bute en c++, m�me si j'ai longtemps 'bricoler' en C. Je bloque aujourd'hui sur un probl�me extr�mement b�te que je ne comprend pas.
Voici mon code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
#include <string>  
#include <fstream>
using namespace std;
int main()
{
	string line;
	fstream text("monfichier.txt");
	while (getline(text,line))
	{
		cout << line << endl;	
	}
return 0;
}

Il n'y a, pour la plupart des fichiers que je traite, aucun probl�me, par contre j'ai pu identifier, sur des fichiers registre (*.reg) un probl�me lors de la sortie de ma chaine.
En effet, celle ci contient des espaces entre chaque caract�re, c'est tr�s p�nible � traiter.
Quand j'affiche la variable �� �crit par exemple ce genre de chose :
[ H K E Y _ C U R R E N T _ C O N F I G \ \ S y s t e m \ C u r r e n t C o n t r o l S e t \ C o n t r o l \ V I D E O ]
alors que mon fichier d'origine contient bien :
[HKEY_CURRENT_CONFIG\\System\CurrentControlSet\Control\VIDEO]
Et du coup impossible de , par exemple, r�injecter les chaine obtenu dans un nouveau fichier.
J'ai test� avec des .reg fabriqu� manuellement il n'y a aucun probl�me.
Les fichiers qui pr�sente des probl�mes sont fabriqu� � partir de la commande regedit /e.
Ce que je ne comprend absolument pas c'est pourquoi cette diff�rence de r�sultat alors que les fichiers sont trait�s de la m�me mani�re?
J'ai clairement loup� un truc essentiel mais quoi?
Si quelqu'un veux bien m'�clairer?
Merci d'avance

[M�dinoc]

Ce ne sont pas des espaces, mais des octets nuls, je parie. Probl�me d'encodage, entre UTF-16 et les ASCIIs �tendus.

Je ne connais pas assez la biblioth�que standard du C++ natif (surtout avec les normes r�centes) pour savoir s'il y a quelque chose pour g�rer �a directement.
Mon conseil: Puisque tu as post� dans le sous-forum consacr� au langage C++/CLI pour le Framework .net, utilise le framework .Net pour de bon, car lui est fait pour �a (un System::IO::StreamReader permet de sp�cifier l'encodage des fichiers).

[bacelar]

C'est la premi�re fois que je viens poster sur ce forum

Et vraisemblablement la derni�re dans cette partie du forum.
Ne le prend pas mal, c'est juste que cette partie du forum est li� � "C++/CLI", une version �tendue par M$ du C++.
Il y a donc beaucoup moins de "flux" ici que dans les parties du forum plus g�n�raliste.
https://www.developpez.net/forums/f1...p/cpp/debuter/

T'es loin d'�tre le premier et tu ne seras pas le dernier � faire cette petite erreur.

J'ai clairement loup� un truc essentiel mais quoi?

Le fait que distinguer des fichiers en ASCII et en UNICODE, c'est la mer.. .

Votre code ne fonctionne qu'avec des fichiers textes en ASCII (�tendu 8bits).
Le fichier "*.reg" que vous lisez n'est pas en ASCII, mais en UNICODE-16 (sans BOM (Byte Order Mark)).
Pour des caract�res contenus dans la table des ASCII 7bits, la version UNICODE-16 de ce caract�re est compos� d'un octet � '\0' suivi du m�me octet que son encodage en ASCII.
'H' en ASCII : 72 (ou 0x48)
'H' en UNICODE-16 (en little endian): 00-72 (ou 0x0048)

La console que vous utilisez doit afficher un '\0' sous forme d'un espace.

La mer.., c'est que rien n'indique l'encodage d'un fichier.
Je crois que l'encodage officiel des .reg est UNICODE-16 (ou UTF-8 ?).
Il est possible que les interpr�teurs de ".reg" utilisent des heuristiques pour d�tecter un mauvais encodage pour encaisser des fichiers "mals" encod�s.

C'est quoi votre objectif ?

Pour lire directement de UTF-16/UNICODE-16 :
http://www.cplusplus.com/reference/fstream/wfstream/

[neokal]

Bonjour et merci pour vos r�ponses rapides.
En effet, je suis pas du tout dans la bonne partie du forum et j'en suis d�sol� (je d�couvre ) ).
Si un mod�rateur veux bien d�placer le sujet je le remercie d'avance.
Effectivement quand j��cris ma chaine dans un fichier et que je visionne celui-ci je n'ai pas d'espace mais des petit logos 'NULL'.
Donc clairement un probl�me ASCII vs UNICODE. J'avoue que je n'avais jamais eu ce probl�me en C donc j��tais un peu perplexe.
Je cherche une solution de ce cot� la et je viens poster la solution ici, au cas ou quelqu'un rencontre le m�me probl�me.
Mon objectif est de pouvoir extraire les donn�es registre avant et apr�s l'installation , par exemple, d'un programme, afin de pouvoir 'fabriquer' un point reg permettant de 'bricoler' un d�ploiement r�seau pour les rares logiciels qui ne le permettent pas par d�faut. �galement pour diff�rencier ou se trouve certaine information dans le registre avant et apr�s modification de certaines configurations etc...
Bref, c'est un probl�me auquel je suis parfois confront� et je me bricole mon outil maison.
Merci de votre regard ext�rieur qui m'a permis d'avancer , un peu plus, dans cette direction.

[neokal]

A premi�re vue je suis loin d��tre le seul � avoir eu ce genre de soucis.
Je pense qu'il y a une solution viable de ce cot� la
https://msdn.microsoft.com/fr-fr/lib...code-snippet-2
(Je poste aussi ce lient pour m�moire � moi m�me).
Par contre j'ai �norm�ment de mal avec la syntaxe et je n'y connais rien dans l'impl�mentation (arr�t� moi si le mot n'est pas bon) des framework en c++.
J'ai copi�/coll� le code en exemple tel quel sans aucun autre r�sultat qu'une longue s�rie d'erreur.
Je continu de chercher/fouill� et je viendrais de toutes fa�ons post� ma r�ponse ici.

[bacelar]

J'avoue que je n'avais jamais eu ce probl�me en C donc j��tais un peu perplexe.

Le probl�me n'a rien � voir avec le langage.
Vous aurez le m�me probl�me en C qu'en C++.

Je pense que vous n'aviez pas conscience du probl�me car UNICODE c'est r�pandu qu'� la fin des ann�es 1990 dans les syst�mes "desktop" et je pense qu'il a pris du temps pour arriver dans les syst�mes embarqu�s.
Donc si vous faisiez du C dans un p�rim�tre (temporel / plateforme) o� l'UNICODE n'�tait pas r�pandu, vous n'�tiez pas tomb� dessus, mais c'est pas "gr�ce" au C.

Je ne comprend pas trop pourquoi la version "wide" des manipulations de stream dont j'ai post� le lien (http://www.cplusplus.com/reference/fstream/wfstream/) n'est pas une solution viable ?

Avec cette version, vous ne manipulez que de l'UNICODE, donc vous �tes d'�querre avec le format des ".reg" en UTF-16.

Vos besoins sont assez classique, me semble-t-il, c'est pourquoi j'ai l'impression qu'il serait peut-�tre possible de faire ces choses juste avec des outils pr�-existant, non ?
Peut-�tre avec des fichiers ".bat" de quelques lignes ?

Je pense qu'il y a une solution viable de ce cot� la

Ce que vous regardez, ce n'est pas du C++ "standard", c'est du code en "C++/CLI" (oui, celui de ce forum ).
Pour pouvoir se servir de ces trucs, il faut �tre dans un contexte d'ex�cution .NET.
L�, je pense que c'est un peu overkill et un peu dangereux pour une personne sans un background en C++ ou dans un langage .NET.
En plus, avec ces API, il faut aussi sp�cifier l'encodage du fichier que l'on cherche � lire.

Donc, � moins d'avoir oublier un d�tail, je pense que l'approche "wfstream" sera bien plus simple.

[foetus]

La mer.., c'est que rien n'indique l'encodage d'un fichier.

Si le BOM (Byte order mark)

Ensuite si tu parses un fichier .html, il y a les m�ta-donn�es.

Donc clairement un probl�me ASCII vs UNICODE.

Pas vraiment, puisque en C, il y a char[*] VS wchar_t

*: sign� ou pas, quoique pour l'UTF8 j'utilise du non sign�

[M�dinoc]

Je ne comprend pas trop pourquoi la version "wide" des manipulations de stream dont j'ai post� le lien (http://www.cplusplus.com/reference/fstream/wfstream/) n'est pas une solution viable ?

La derni�re fois que j'avais essay� un truc de ce genre, il m'a ouvert le fichier en tant qu'ASCII et faisait la conversion (voire un b�te cast, je ne suis pas s�r) en wchar_t � la vol�e...

[Pyramidev]

Au cas o� mon code soit utile � quelqu'un, voici un programme qui lit un fichier encod� en UTF-16 et le convertit en UTF-8 :

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#include <codecvt>
#include <fstream>
#include <iostream>
#include <locale>
 
int main(int argc, char** argv)
{
	try {
 
		if(argc < 2) {
			throw std::runtime_error("Pas assez d'arguments. Il en faut deux :"
				" l'adresse d'un fichier en entree encode en UTF-16"
				" et l'adresse d'un fichier en sortie qui sera encode en UTF-8.");
		}
 
		const char* const cheminFichierEntreeUTF16 = argv[1];
		const char* const cheminFichierSortieUTF8  = argv[2];
 
		std::basic_ifstream<char32_t> fic_entree_utf16(cheminFichierEntreeUTF16, std::ios::binary);
		if(!fic_entree_utf16)
			throw std::runtime_error("Impossible d'ouvrir le fichier en entree.");
		fic_entree_utf16.imbue(std::locale(
			fic_entree_utf16.getloc(),
			new std::codecvt_utf16<char32_t, 0x10ffff, std::consume_header>
		));
 
		std::basic_ofstream<char32_t> fic_sortie_utf8(cheminFichierSortieUTF8, std::ios::binary);
		if(!fic_sortie_utf8)
			throw std::runtime_error("Probleme avec le fichier en sortie.");
		fic_sortie_utf8.imbue(std::locale(
			fic_sortie_utf8.getloc(),
			new std::codecvt_utf8<char32_t, 0x10ffff, std::generate_header>
		));
 
		char32_t carac_utf32;
		while(fic_entree_utf16.good())
		{
			fic_entree_utf16.get(carac_utf32);
			if(fic_entree_utf16.fail() == false)
			{
				fic_sortie_utf8 << carac_utf32;
				if(fic_sortie_utf8.fail())
					throw std::runtime_error("Probleme lors de l'ecriture du fichier en sortie.");
			}
		}
 
	} catch(const std::exception& e) {
		std::cerr << e.what();
		return 1;
	} catch(...) {
		std::cerr << "Erreur inconnue.";
		return 2;
	}
 
	return 0;
}

Remarques :

• S'il n'y a pas de caract�re BOM dans le fichier en entr�e, il faut remplacer std::consume_header par (std::codecvt_mode)0 (qui est d�j� l'argument de template par d�faut) ou std::little_endian.
• Si on ne veut pas de caractere BOM dans le fichier en sortie, il faut remplacer std::generate_header par (std::codecvt_mode)0.

[Pyramidev]

La derni�re fois que j'avais essay� un truc de ce genre, il m'a ouvert le fichier en tant qu'ASCII et faisait la conversion (voire un b�te cast, je ne suis pas s�r) en wchar_t � la vol�e...

C'est normal. En fait, il faut distinguer la suite d'octets du fichier et la suite de caract�res de type CharT stock�e dans le buffer de type std::basic_filebuf<CharT, Traits> encapsul� par std::basic_ifstream<CharT, Traits> et std::basic_ofstream<CharT, Traits>.
Dans le cas o� CharT n'est pas char (par exemple char32_t dans le code de mon pr�c�dent message), il y a une conversion avec un std::codecvt. Pour ma�triser la conversion, il faut alors changer la locale utilis�e par le flux.

[M�dinoc]

Ah merci, je me disais bien (avec le recul; ma tentative d'utiliser wifstream remonte � des ann�es) que les locales seraient impliqu�es, mais je ne me souvenais plus du tout comment.

[neokal]

J'ai utilis� cette petite fonction, elle permet d'avoir en retour une chaine string au format utf8 de la chaine string utf16 pass� en argument,
C'est juste une fonction qui fait sauter un caract�re sur deux , pas forc�ment super �l�gant mais �a m'a bien d�pann�.

Merci en tout cas pour l'aide apport�e.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
string utf16_to_utf8(string into)    {
	string outo;
	int i=0;
	bool pendulum = 0;
	for(i=0;i<into.size();i++)
	{
		if (pendulum==1)	
			outo+=into[i];
		if (pendulum == 0) pendulum=1;
			else pendulum = 0;
	}
	return outo;
}	//END utf16utf8

[M�dinoc]

Le nom de ta fonction est archi-faux: M�me en supposant que le "un octet sur deux" est syst�matiquement nul, le r�sultat n'est pas de l'UTF-8, mais de l'ISO 8859-1.

Si tu veux faire de la vraie conversion en UTF-8 sans appeler de fonctions non-standard et sans avoir � comprendre comment marchent les locales, il te faudra une fonction de ce genre:
https://www.developpez.net/forums/d1...e/#post8502203
(note que la fonction de conversion prend un code point en entr�e; cela veut dire que lui passer directement les paires d'octets lus est appropri� pour convertir depuis l'UCS-2; pour convertir depuis du vrai UTF-16, il faut un peu plus de travail).