Discussion :

[petitclem]

Bonjour,

je réalise une application qui récupère des données sur le port série.
J'arrive bien à recevoir (lire) les bonnes données mais lorsque je les stocke dans un fichier de type texte, c'est des hiéroglyphes.

Voici mon code de la fonction d'écriture dans le fichier :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
ReadFile(hdl,&buf,1,&nblu,NULL);
if (nblu!=0)
{
    int i=0;
    for (buf [i]; i < 18; i++)
    {
        printf ("Octets lus : %x\n\n", buf[i]);
        write(  handle, &(buf[i])   , sizeof(buf[i]));
        printf ("Stockage fichier\n");
        break;
    }
}

J'aimerai savoir ce qu'il faut faire pour récupérer les bonnes données, c'est du type : 1er octet FF, deuxième EE ...

Merci d'avance pour vos réponses !

[BainE]

bonjour,

normal, les caractères 0xFF et 0xEE ne sont pas des caractères affichables (peut etre en Unicode...) mais si tu veux voir tes valeurs faut prendre un éditeur hexadécimal, comme ca tu verra ton premier octet a la valeur : 0xFF.

[petitclem]

Comment ça un éditeur hexadécimal !!!

Quel programme je dois choisir pour pouvoir visualiser les données de mon fichier ?

[BainE]

re,

ben c'est comme ca notre alphabet latin n'as que 26 caracteres, on a pas besoin de 256 possibilités pour les stocker tous (bon avec les majuscules et les caracteres spéciaux ca fait un peu plus OK...), toutes les possibilités de caracteres ne sont soit pas utilisé soit pas lisibles. Mais des soft comme hexedit, hexaedit, notepad++ doit pouvoir le faire aussi...

[wogkiller]

si tu veux juste voir les valeurs dans ton fichier, tu peux toujours les transformer en chaînes de caractères avant des les écrire dans le fichier :

Code :

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

1
2
CString t="";
	t.Format("%x",0xff);

[Médinoc]

Ou, avec le standard:

Code C++ :

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

1
2
3
std::ostringstream oss;
oss << std::hex << (int)0xFF;
std::string t = oss.str();

[koala01]

si tu veux juste voir les valeurs dans ton fichier, tu peux toujours les transformer en chaînes de caractères avant des les écrire dans le fichier :

Code :

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

1
2
CString t="";
	t.Format("%x",0xff);

Attention, CString n'est pas portable

Ceci dit:

D'abord et avant tout, je te conseillerais d'éviter les fonctions typiquement C au profit de leur équivalent C++...

Ainsi, tu aurais fortement avantage à préférer la sortie standard std::cout à printf, et à préférer l'utilisation d'un flux de sortie de fichier (std::ofstream) et son opérateur << à la fonction write.

Ensuite, ainsi que BainE l'a si bien fait remarquer, il se fait que, en français, nous nous contentons généralement d'à peu près septante (soixante-dix, pour nos amis français ) de caractères lorsque nous écrivons.

L'anglais, pour sa part, ne connaissant pas les caractères accentués (exit éèçî et consorts) en utilisen encore moins

Or, en informatique, les valeurs acceptable pour un "caractère" s'étalent allègrement entre 0 et 127 voir 255 ...

Cela implique qu'il y a entre 50 et 185 caractères (à peu près) qui ne représentent pas ce que l'on appelle une "valeur alpha-numérique" (un chiffre ou une lettre).

Il faut aussi bien comprendre que, si le message que tu lis prend un sens pour toi, c'est parce qu'il existe une convention utilisée par tous les ordinateurs qui lui permet de transformer une valeur - à la base binaire, mais souvent représentée sous la forme hexadécimale - en quelque chose "d'humainement compréhensible" en remplaçant, par exemple, la valeur binaire 01100001 (0x61 en hexadécimal ou 97 en décimal) par... le caractère 'a'.

Le problème, c'est que, comme il y a plus de valeurs admises que de caractères suposément lisibles par l'humain, il a bien fallut décider de permettre de représenter les autres sous une forme quelconque: les "hiéroglyphes" dont tu parles

En outre, il faut savoir qu'un fichier "humainement lisible" fait généralement mauvais ménage avec un fichier "traitable par l'ordinateur en tant que données": tu peux décider de faire remplir le fichier sous une forme humainement lisible, mais cela impliquera une "conversion" lorsque l'ordinateur voudra récupérer les données (pour tout autre chose que le fait de te les afficher).

Inversement, si tu décide d'écrire les données dans un fichier de manière à ce qu'elles soient facilement récupérable par l'ordinateur, il faudra commencer par ... convertir ces données (ce que font hexedit et autre) de manière à te les présenter sous une forme "compréhensible" (sans recourir aux "hiéroglyphes")...

Quoi qu'il en soit, la classe ofstream (pour l'écriture dans le fichier) te viendra bien en aide...

Ainsi, tu pourrait envisager que ta fonction travaille sous la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
ReadFile(hdl,&buf,1,&nblu,NULL);
ofstream ofs("tonfichier.txt");
if (nblu!=0)
{
    for ( int i = buf [i]; i < 18; i++)
    {
        cout<<"Octets lus "<<buf[i]<<endl<<endl;
        ofs<<hex<<(int)buf[i]<<" ";
        break;
    }
}

pour te permettre de "lire" les valeurs reçues ou sous la forme (très peu modifiée ) de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
ReadFile(hdl,&buf,1,&nblu,NULL);
ofstream ofs("tonfichier.dat",ios::bin);
if (nblu!=0)
{
    for ( int i = buf [i]; i < 18; i++)
    {
        cout<<"Octets lus "<<buf[i]<<endl<<endl;
        ofs<<buf[i];
        break;
    }
}

qui facilitera l'accès de l'ordinateur aux informations, mais qui rendra la lecture humaine plutôt... compliquée

[petitclem]

Merci, c'est gentil toutes vos réponses, mais je dois dire que je ne comprends pas tout.

[BainE]

Re,

jette un oeil la dessus peut etre qu'ils expliquent mieux que nous.

P.S. : a lire apres lecture :
1°/ La norme ascii est la norme de codage des char en C.
2°/ ils ne parlent meme pas des caracteres apres 127 (c'est l'ascii etendu qui doit rajouter des caracteres a accents et autres broutilles, mais la majeur parties des codes n'est pas affichables).

Sinon dis nous ce que tu comprends pas

[koala01]

Je vais donc essayer d'être plus clair...

Tu n'es pas sans savoir que nous avons:

• 10 chiffres (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
• 26 lettre fois deux (tout l'alphabet et leur équivalent en majuscule)
• quelques signes de poncutation (", ', ; .)
• (pour les langues latine uniquement, quelque lettre accentuées (é, à, è, ç)

Au total, avec les lettre accentuées, cela correspond à peu près à 70 caractères que tu utilise dés que tu écris quelque chose sur une feuille de papier (ou à l'aide du clavier de ton ordinateur).

Il se fait que l'ordinateur est plus bête que ma nièce qui est en primaire, dans le sens où il ne comprend que deux "symboles": 0 et 1.

De plus, il n'a aucun "libre arbitre": il fait ce qu'on lui dit de faire, sans se poser la question de savoir si c'est bien de le faire ou s'il est ne serait-ce que opportun de le faire.

Cette restriction est posée par le fait qu'un ordinateur est composé exlusivement "d'interrupteurs" que l'on nomme "bit" et donc, on remarque que les symboles qu'il connait sont:

• 1: le courent passe
• 0: le courent ne passe pas

Pour pouvoir représenter des valeurs supérieures à 1, il doit donc regrouper plusieurs bits entre eux.

A l'heure actuelle, on peut considérer que la plus petite unité utilisable séparément par l'ordinateur est composée de 8 bits: un "octet" ou, en anglais, un "byte".

Or, il se fait que les différentes possibilités que l'on rencontre si 8 interrupteurs sont soit allumés soit éteints permettent de représenter... 255 possibilités.

En plus, au départ, il faut savoir que l'un des bits qui composent l'octet était réservé à la représentation du signe "-"... du coup, il était possible de représenter... 127 valeurs positives avec les 7 bits restants.

Et tu te rend bien compte qu'il est très difficile pour un humain de comprendre la signification de 01000000 01010100 00111111 01000111 11111111

Du coup, les ingénieurs qui ont créé le premier processeur ont mis au point une "table d'équivalence" entre les valeurs binaires comprises par l'ordinateur et les caractères "humainement lisibles" qui dit à l'ordinateur "si tu rencontre la valeur binaire 01100001, affiche à l'écran une représentation de 'a' ".

Comme ils étaient anglophones, ils se sont basés... sur les caractères qu'ils utilisaient, (les 26 lettres fois deux et les 10 chiffres).

Comme il restait quelques valeurs possibles, ils ont décidé de donner une signification particulière aux 32 premiers (les valeurs de 0 à 31) pour qu'ils servent d'instruction à l'ordinateur, et de rajouter une série de caractères jugés "utiles" (tout ce qui est parenthèses, accolade, arobase, crochets etc.)

Cela a donné la table de caractères ASCII, qui est toujours utilisée de nos jours.

En outre, ils n'ont pas été longs à choisir une autre base de calcul (pour rappel, nous calculons généralement "en base 10") : l'hexadécimal.

Cette base permet de fournir 16 valeurs différentes avec un seul "symbole", ce qui permet de représenter les 255 valeurs possibles avec seulement... 2 symboles (représenté par les 10 chiffres de 0 à 9 et les lettres A, B, C, D, E, F).

Plus tard, ils se sont rendus compte qu'il était possible d'utiliser le bit de signe comme valeur supplémentaire à un caractère.

Cela permettait de faire passer les valeur potentielle de 127 à ... 255.

Et ils ont donc décidé "d'étendre" la table de caractères en rajoutant les lettres accentuées et autres "signes cabalistiques".

Comme les 127 premiers caractères sont toujours ceux de la table ASCII d'origine, on parle maintenant de la table ASCII "étendue"

Mais le problème reste entier...

Quand tu décide d'ouvrir un fichier texte avec un éditeur de texte classique (notepad, par exemple), l'ordinateur ne fait rien d'autre que ce qu'on lui demande de faire, à savoir: se baser sur la table ASCII étendue pour afficher à l'écran les valeurs, regroupées par 8 bits, qu'il rencontre.

Et s'il se fait que le fichier contient des informations qui, pour l'ordinateur, devrait avoir une signification différente (entre autre parce qu'il devrait gérer les valeurs lues en tant que valeur et non en tant que "caractère à afficher"), il ne faut pas s'étonner qu'il se mette à nous afficher du "grand portnawak"...

J'ai pris un tas de raccourcis - sans doute un peu osés - dans cette explication, mais le but était de te faire comprendre la différence qu'il peut exister entre l'interprétation que tu fais de ce que tu vois et celle que peut faire l'ordinateur face à des données

Maintenant, il faut savoir que certains logiciels - dont ceux cités plus haut - permettent de donner une représentation "différente" des données que peut contenir un fichier.

Ils sont donc en mesure de représenter ces valeurs sous la forme hexadécimale, qui permet de "comprendre" plus facilement ces valeurs qui sont - normalement - destinées à être utilisées directement par l'ordinateur.

Ton problème vient principalement du fait que ton application reçoit des données qui sont "typiquement destinées" à l'ordinateur et que le fait que tu puisse les récupérer avec le type "char" ne veut en réalité dire qu'une seule chose: les différentes valeurs représentées seront toujours comprises entre 0 et 255 ou entre -127 et +127...

Si tu souhaites que ton application écrive ces données de manière à ce que tu puisse les lire, il faudra - au minimum - veiller à ce que l'application fasse une conversion qui permette de reproduire ces valeurs dans un format "humainement lisible"... ou décider d'utiliser un logiciel dont le but n'est pas d'afficher... des caractères

[petitclem]

Merci beaucoup à tous,


j'arrive à lire la trame impeccable, maintenant j'essaie de convertir de l'hexa (1 octet) en décimal ou caractère mais c'est chaud j'y arrive pas

[koala01]

Comme on essaye de te le faire comprendre, le caractère est sans doute la pire des solutions si tu souhaites pouvoir lire toi même les informations qui se trouvent dans le fichier...

L'idée est donc de demander à l'application d'écrire ces informations, selon tes préférences

• au format hexadécimal ( ex: 0xF1)
• au format décimal (241)
• (après tout, pourquoi pas ) au format binaire (11110001)

La question à te poser est donc: quelle serait - selon toi - la représentation la plus simple à analyser

[petitclem]

c'est la représentation décimal !

[BainE]

Oui mais deja pour ecrire dans un fichier lisible faut utiliser fprintf voir encore mieux si tu fais du C++ std::ofstream (va voir la FAQ http://cpp.developpez.com/faq/cpp je crois, c est tres facile, y a plein d exemple) .

Apres un simple cast de chaque char en int.

[koala01]

c'est la représentation décimal !

je ne vois pas pourquoi ...

Après tout, comme tu récupère l'état de 8 broches distinctes, il pouvait parfaitement sembler cohérent que la notation binaire puisse t'apporter une représentation intéressante, en indiquant 1 si la broche était active et 0 si elle ne l'était pas

Ceci dit, pourrais tu m'indiquer précisément le type de ta variable buf, histoire que je ne doive pas "partir à la pêche" et faire des suppositions qui seront trop souvent fausses

Oui mais deja pour ecrire dans un fichier lisible faut utiliser fprintf voir encore mieux si tu fais du C++ std::ofstream (va voir la FAQ http://cpp.developpez.com/faq/cpp je crois, c est tres facile, y a plein d exemple) .

J'ai déjà abordé ce point dés mon premier message, mais merci du rappel

Apres un simple cast de chaque char en int.

à condition qu'il s'agisse bel et bien de unsigned char... sinon, la conversion en int risque de t'apporter quelque... surprises

[petitclem]

Mon buf est bien un "unsigned char" donc je peux faire un cast en int ?
Pour ensuite avoir des valeurs plus lisibles dans mon fichier !

[Médinoc]

Ça ne change rien, ça.
Tu as deux choix:

• Écrire un fichier texte au lieu d'un fichier de données brutes (dit "fichier binaire"), avec des fprintf() au lieu de fwrite(), et tout et tout...
• Écrire un fichier de données brutes et un programme de lecture, qui lit les valeurs avec fwrite() et les affiche avec printf().

Un éditeur hexadécimal fait un truc assez proche de la seconde solution: Il lit les données brutes et affiche chaque octet (ou mot de plusieurs octets) sous forme hexadécimale.

[petitclem]

Mon programme lit bien ce que je veux (avec printf), ensuite j'utilise "open" pour créer et ouvrir le fichier (fichier .txt), et "write" pour écrire à l'intérieur.
Lorsque j'ouvre mon fichier avec "hexedit" j'ai exactement tous les octets que je veux.
Ce que je voudrais, c'est pouvoir convertir un octet en valeur décimal, puis le stocker (write) dans le fichier de type texte.
Et lorsque j'ouvrirai le fichier manuellement avec le bloc notes par exemple je puisse lire normalement cet octet.

[Médinoc]

Attends: Tu écris dans un fichier .txt avec write() ?

PS: Pourquoi utiliser les fonctions bas niveau POSIX (open et write) alors que les fonctions standard (fopen() et fwrite()) font très bien le job?

[petitclem]

Bon alors que dois je faire !!!

L'application :je réceptionne une trame sur le port série, chaque octet (18 octets) de cette trame correspond à une info. Je sélectionne les infos (octets) qui m'intéressent pour les stocker au format décimal dans un fichier de type texte qui doit être lisible.

Et pourquoi pas "write ()" ??