Conversion structure fichier binaire big-endian

Version imprimable

Bonjour,

Je vais faire simple, j'ai la structure suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
struct ffb_init0 {
    unsigned long long fileID; /* 48 bits */
    unsigned short clientID; /* 16 bits */
    unsigned long long blockNumbers; /* use only 45 bits */
    unsigned long packetNumbers; /* 32 bits */
    unsigned long long magicValue; /* 64 bits */
    unsigned long long fileHash[4]; /* at least 512 bits */
    unsigned char hashMethod; /* 8 bits */
    unsigned char protocolVersion; /* use only 4 bits */
    unsigned long long fileTime; /* use only 48 bits, hold unixtime */
    unsigned long long dataBlockPayload; /* 64 bits */
    unsigned char hasMetadata; /* 1 bit */
    unsigned char uft8Filename[69]; /* 552 bits for utf8 filename */
    /* 6 bits left to pad at 0x0 */
};

Je veux la convertir en tableau de bits, alors j'ai commencé comme suit :

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
 
    unsigned char barr_p[175];
 
    /* FileID */
    barr_p[0] = (p->fileID >> 40) & 0xff;
    barr_p[1] = (p->fileID >> 32) & 0xff;
    barr_p[2] = (p->fileID >> 24) & 0xff;
    barr_p[3] = (p->fileID >> 16) & 0xff;
    barr_p[4] = (p->fileID >> 8) & 0xff;
    barr_p[5] = p->fileID & 0xff;
 
    /* clientID */
    barr_p[6] = (p->clientID >> 8) & 0xff;
    barr_p[7] = p->clientID  & 0xff;
 
 
    /* blockNumbers */
    barr_p[8] = (p->blockNumbers >> 37) & 0xff;
    barr_p[9] = (p->blockNumbers >> 29) & 0xff
    barr_p[10] = (p->blockNumbers >> 21) & 0xff;
    barr_p[11] = (p->blockNumbers >> 13) & 0xff;
    barr_p[12] = (p->blockNumbers >> 5) & 0xff;
    /* Start to mix data in a byte as blockNumbers is 45 bits, so 3 bits are
     * used in the last byte and so we have to complete with the five bits of
     * the next value in the structure.
     */
    barr_p[13] = (((p->blockNumbers << 3) & 0xff) +
            ((p->packetNumbers >> 29) & 0xff)) & 0xff;
    barr_p[14] = (p->packetNumbers >> 21) & 0xff;
    barr_p[15] = (p->packetNumbers >> 13) & 0xff;
    barr_p[16] = (p->packetNumbers >> 5) & 0xff;

Le problèmes est bien le suivant, j'ai 175 cases de tableaux à remplir comme ça, avec un décalage (champs 45 bits), et je me demandais si quelqu'un a juste une idée pour automatiser un peu ça.

Bonjour,

On pourrait utiliser une macro pour "alléger" la lecture

(non testé)
Code:

1 2 3 #define EXTRACTBIT(f,nb) ((f) >> (nb) & 0xff)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 unsigned char barr_p[175]; /* FileID */ barr_p[0] = EXTRACTBIT(p->fileID, 40); barr_p[1] = EXTRACTBIT(p->fileID, 32); barr_p[2] = EXTRACTBIT(p->fileID, 24); barr_p[3] = EXTRACTBIT(p->fileID, 16); barr_p[4] = EXTRACTBIT(p->fileID, 8) ; barr_p[5] = EXTRACTBIT(p->fileID, 0); /* clientID */ ....
Ce ne sont que 175 lignes.... ;)

Petite remarque: Tu utilises l'opérateur + pour combiner deux champs, pour ma part j'utiliserai plutôt le OU Logique |

Avec un truc de ce genre:

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
32
33
34
35
36
37
38
/* Sérialisation d'entier 64 bits "unchecked" */
void SerializeU64_u(unsigned char *pbuffer, size_t *pIndex, unsigned long long u64)
{
	/* Note: On peut aussi faire une boucle */
	pBuffer[(*pIndex)++] = (u64 >> 56) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 48) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 40) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 32) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 24) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >> 16) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >>  8) & 0xff;
	pBuffer[(*pIndex)++] = (u64 >>  0) & 0xff;
}
 
/* Sérialisation d'entier 64 bits */
int SerializeU64(unsigned char *pbuffer, size_t *pIndex, unsigned long long u64, size_t tailleBuffer)
{
	const size_t TAILLE = sizeof u64;
	/* --- Contrôle des paramètres --- */
	/* pIndex n'est jamais nul, en C++ ce serait une référence */
	assert(pIndex != NULL);
	/* Buffer nul+taille nulle: Calcul de la taille nécessaire */
	if(pBuffer == NULL && tailleBuffer == 0)
	{
		(*pIndex) += TAILLE;
		return 0;
	}
	/* Buffer nul ou insuffisant: Erreur */
	if(pBuffer == NULL)
		return -1;
	if((*pIndex) + TAILLE > tailleBuffer)
		return -1;
 
	SerializeU64_u(pBuffer, pIndex, u64);
	return 0;
}
 
/* Etc. */

Et tu appelles les bonnes fonctions pour les bons membres de la structure.

12/02/2009, 11h48
Tchetch
Ouais la macro, c'est clair, j'y ai même pas pensé ...

Citation:

Envoyé par jowo

Ce ne sont que 175 lignes....

J'ai plusieurs structures au final.

Citation:

Envoyé par jowo

Petite remarque: Tu utilises l'opérateur + pour combiner deux champs, pour ma part j'utiliserai plutôt le OU Logique |

Juste, merci.

Citation:

Envoyé par Médinoc

Et tu appelles les bonnes fonctions pour les bons membres de la structure.

J'y ai pensé, mais le problème est à partir du décalage. Je penses peut-être faire d'abord des morceaux de 64 bits (unsigned long long) à l'aide d'une fonction générique du genre :
Code:

1 2 3 unsigned long long (unsigned long long val1, int startVal1, int lenVal1, ...) { }
Et ensuite je peux rassembler ces morceaux en gros bloc de 1400 bits ... Ce serait une solution ...
12/02/2009, 11h58
Médinoc

Ah, je vois, c'est un tableau de bits qu'il te faut et non d'octets...
Enfin, tu peux sûrement faire à peu près la même chose.
Essaie de te faire une fonction générique de ce genre:

Code:

void CopyBits(unsigned char *dest, size_t iBitDest, unsigned char const *src, size_t iBitSrc, size_t nBits);

Et bien sûr, optimisée pour éviter de copier les bits un par un.
12/02/2009, 13h12
souviron34

Citation:

Envoyé par Tchetch

Je veux la convertir en tableau de bits, alors j'ai commencé comme suit :
..
Le problèmes est bien le suivant, j'ai 175 cases de tableaux à remplir comme ça, avec un décalage (champs 45 bits), et je me demandais si quelqu'un a juste une idée pour automatiser un peu ça.

Citation:

Envoyé par Tchetch

...
J'y ai pensé, mais le problème est à partir du décalage. Je penses peut-être faire d'abord des morceaux de 64 bits (unsigned long long) à l'aide d'une fonction générique du genre :
..
Et ensuite je peux rassembler ces morceaux en gros bloc de 1400 bits ... Ce serait une solution ...

D'après le contenu de la structure, es-tu sûr que ce soit des tableaux de bits que tu veuilles ?

et non avoir en entrée un tableau de unsigned char (lecture du buffer envoyé/reçu), et le décomposer suivant les paramètres des structures ?

Si c'est le cas, j'aurais plutôt tendance à avoir quelque chose comme :

Decode_Int ( adr, offset, longueur, &i );
Decode_Float ( adr, offset, longueur, &fl );
....

adr étant l'adresse d'un octet, offset le nombre de bits de décalage, longueur le nombre de bits où la varaible est stockée, et ensuite l'adresse où stocker...

(certains formats compressés sont faits comme ça)
12/02/2009, 13h31
Tchetch

Citation:

Envoyé par Médinoc

Ah, je vois, c'est un tableau de bits qu'il te faut et non d'octets...

Je change le boutisme de mes valeurs. Donc c'est au niveau des octets. Je crois qu'il faut que je prenne le problème différemment :

- Changer le boutisme de toute la structure
- Empaqueter sans espacement d'alignement.

Je vais faire ça je crois, c'est plus logique en fait.
12/02/2009, 13h42
souviron34

il y a les fonctions

htonl htons etc etc et leurs inverses ntohl ntohs ... (Host To Netwrok et Network To Host)
12/02/2009, 13h49
Médinoc

Si tu fais juste un tableau d'octets, tu peux utiliser des fonctions comme celles que je t'ai conseillées (et que souviron34 a également conseillé).
La fonction échantillon que t'ai montré fait ça pour un nombre 64 bits, puis il faut en faire pour les 32, 16, 8 bits...

Voilà, je vais utiliser un truc comme ça et juste gérer les croisement, ça devrait fonctionner

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#define ffbMASK(x) (x & 0xff)
#define ffbXR(a,n)  (ffbMASK((a >> n)))
#define ffbXL(a,n)  (ffbMASK((a << n)))
#define ffbMIX(a, b) (((a) & 0xff) | ((b) & 0xff))
 
inline void __ffb_doBoringStuff(unsigned long long x, BARR_TYPE * barr_p,
        unsigned int xLen)
{
    int i = 0;
 
    for(i = xLen; i >= 8; i-=8) {
        *barr_p = ffbXR(x, i);
        barr_p++;
    }
    return;
}

12/02/2009, 15h44
Médinoc

Donc finalement, c'est à l'échelle du bit ou de l'octet?
Tu m'as dit une chose et son contraire...

Franchement, pour moi, le mieux est de faire champ par champ.
Tu fais des fonctions Serialize_u64, Serialize_u48 si tu veux, Serialize_u32, Serialize_u16, Serialize_u8, et enfin une fonction Serialize_ffb_init...
12/02/2009, 16h23
Tchetch
Citation:

Envoyé par Médinoc

Tu fais des fonctions Serialize_u64, Serialize_u48 si tu veux, Serialize_u32, Serialize_u16, Serialize_u8, et enfin une fonction Serialize_ffb_init...

Et pour les valeurs qui ne sont pas divisible par un octet (45 bits, 1 bit, ...) ?
Code:

1 2 3 4 5 6 tab[x] tab[x+1] | | | 111 10000 111 10000 1111 0000 +++++++++ ++++++++++ ++++++++++ +s->val1 +s->val2 +s->val3
12/02/2009, 16h34
Médinoc

Donc, c'est bien un tableau de bits qu'il te faut et pas un tableau d'octets!
C'est à l'échelle du bit que tu dois gérer tout ça, donc mes propositions de sérialisation ne marchent pas, sauf celle pour une fonction CopyBits().

Pas facile de bosser avec quelqu'un qui se contredit sur les specs...
12/02/2009, 16h52
Tchetch

Dans un premier temps, on travail au niveau de l'octet pour avoir du gros-boutiste, mais on a pas d'espacement. Donc quand on a 45 bits, on va chercher 3 bit dans le nombre suivant pour compléter le dernier octet et on change le boutisme sur 48 bits.

Donc oui on travail au niveau de l'octet, mais il n'y a pas toutes les valeurs qui sont des multiples de 8, donc dans ces cas là, on va compléter la valeur et la traiter ensuite.
12/02/2009, 18h53
souviron34

je crois qu'il y a un problème de fond dans l'expression du besoin....

Je ne sais pas quel est le problème de fond.

Je mentionnais tout à l'heure une technique , utilisée par exemple pour les gros fichiers binaires de la météo (les modèles numériques compressés)(GRIB pour ceux qui veulent se rensiegner).

On lit par exemple le fichier d'un coup, comme un buffer de unsigned char.

Là dedans, le protocole dit que c'est fait de plusieurs structures, comme tu les déclares là-haut. Sauf qu'il donne une table de correspondance disant : "ça c'est un int codé sur 1 octet. ça c'est un réel codé sur 14 bits, suivi d'un int codé sur 6 bits, suivi d'un int codé sur 9 bits, etc etc.."

Pour fabriquer (et décoder) ces fichiers, c'est en fait une suite ininterrompue de bits. MAIS ce n'est pas en l'interprétant sous forme de tableaux de bits qu'on s'en sortira.

Il faut prendre la spec, le buffer de unsigned char, et démarrer :

adresse 0 : 8 bits.=> transformer 8 bits en un int
adresse 0 + 8 : => transformer 14 bits en un float
adresse 0 + 8 + 14 => transformer 6 bits en un int
adresse 0 + 8 + 14 + 6 => transformer 9 bits en un int

Ce dont je parlais tout à l'heure, c'était un truc comme ça...

(adr était le début de l'octet en cours, offset était le nombre de bits où commence le nombre , longueur était le nombre de bits représentant le nombre (les nombres sont souvent à cheval sur plusieurs octets)).

Je n'ai jamais vu un truc aussi compact.

Mais cela implique , comme le disait Médinoc, des routines de "base", c'est à dire disposer de 4 (ou 2) octets en mémoire, et faire des shifts et copies de bits pour transformer suivant le protocole.

Je ne sais pas si c'est cela que tu veux dire, ou si c'est bêtement faire aller d'un certain ordre à un autre, auquel cas les fonctions htonl ... font le travail toutes seules...
13/02/2009, 09h31
Tchetch

Il existe plein de protocole d'encodage binaire (comme XDR, CDF, ...) mais là ce n'est pas le problème. Le problème de fond était de convertir une structure donnée dans une série de bits sans le "padding" et en "big-endian".
Ici le format est défini. C'est pas du XDR, pas du CDF, pas du GRIB, pas du HDF ...
13/02/2009, 10h52
souviron34

Citation:

Envoyé par Tchetch

Le problème de fond était de convertir une structure donnée dans une série de bits sans le "padding" et en "big-endian".
Ici le format est défini.

Et ???

C'est pas ce que je mentionne ????

SANS "padding".... de bits...

Car si tu veux écrire juste la suite des éléments de la structure, la manière portable de le faire (que ce soit little ou big endian) est de se servir des fonctions faites pour (htons et ntohs par exemple).
13/02/2009, 11h14
Médinoc

Le problème, c'est que les htonX seuls ne suffisent pas, car il faut en plus les décalages de bits.

(D'ailleurs, les htonX sont moins portables que le faire soi-même (par décalages), car à ma connaissance, ils ne sont pas standard C mais POSIX. Bien sûr, sur un PC on s'en moque...)
13/02/2009, 11h21
souviron34

Citation:

Envoyé par Médinoc

Le problème, c'est que les htonX seuls ne suffisent pas, car il faut en plus les décalages de bits.

C'est là que je ne comprends pas...

SI il doit y avoir un flux continu de bits SANS paddings de bits, alors oui, mais il faut un protocole décrivant (comme je l'ai mentionné plus haut), la structure, car il est à priori impossible de savoir si un int sera codé sur 4, 7, 9, ou 13 bits, et où commencera l'élément suivant de la structure.

SI le "non-padding" s'applique au fait que les éléments se suivent sans tenir compte d'un éventuel padding de la structure, il n'y a aucun besoin de faire de shift de bits, les frontières tombant sur des octets..
13/02/2009, 11h36
Médinoc

Si j'ai bien compris, il doit bel et bien sérialiser la structure sous forme d'un flux continu de bits sans padding entre. Le protocole est décrit dans les commentaires sur la structure: Il y est indiqué qu'un des entiers ne fait que quatre bits, notamment.
13/02/2009, 11h40
souviron34

ok j'avais pas vu..

Donc c'est bien ce que je disais.....

Ce n'est pas un flux entier de bits qui marchera...

Il faut lire / écrire tout le buffer d'un coup, et explorer (comme je l'ai indiqué plus haut) les adresses par exemple en milieu d'octet, en tirer les m bits corrects sur la bonne longueur, là oui en le shiftant suivant le bon type ...

Je ne comprend donc pas pourquoi il me dit que ce n'est pas ça..

C'est exactement ce que j'ai décrit pour le format GRIB...
13/02/2009, 12h03
Tchetch

C'est exactement ça. La seule chose que je cherchais c'est si il y avait des astuces connues par quelqu'un pour le faire, parce que la seule méthode que j'avais trouvé était de le faire octet par octet, chacun des 175 octets de la structure.
13/02/2009, 12h08
souviron34

tu peux regarder le code (libre) de décodage de GRIB (cherche "wgrib").

Normalement, tu ne le fais pas octet par octet.

Tu fais (comme je l'ai dit plus haut), par nombre d'octets correpondants à ce qui est indiqué dans la structure.

(par exemple quand tu dois lire 48 bits, suivant à quelle adresse tu te trouves au début du nombre (au début ou en milieu d'octet), et où t'amènes la fin, tu devras lire 8 ou 9 ou 10 octets d'un coup...

tiens, un bout de code :

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
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
 
 
/*
  ---------------------------------------------------------------
    Jetons pour RCS:
 
    $Header: GbBitManip.c,v 4.5 99/01/29 05:08:49 bibsme Exp $
 
    $Log:	GbBitManip.c,v $
 * Revision 4.5  99/01/29  05:08:49  05:08:49  bibsme (Programmatheque)
 * Version operationnelle au 28 Janvier 1999. Derivee de la 4.0 issue du CRIM
 * 
 * Revision 1.0  98/06/11  19:14:47  19:14:47  bibsme (Programmatheque)
 * Initial revision
 * 
  ---------------------------------------------------------------
*/
 
/********************************************** Grib_Bits_Manipulation.c
**
**      This file contains the bit manipulation routines needed for
**      decoding GRIB files. Its main routine allows the reading
**      of a specified number of bits starting at a specified address
**      within a byte stream, and outputs the results in a 32-bits
**      integer. It is used everywhere in decoding GRIB records.
**
**      Copyright CRIM/Centre de recherche informatique de Montreal 1993
**      Author : Jean Souviron
*************************************************************************/
 
#include "GbBitManip.h"
 
/*
----------------------------------------------------------------------
----------------------------------------------------------------------
 
	This routine reads any number of bits starting at any adress
	within a byte and outputs it as an 32-bits integer.
 
	It's the basic stone of the GRIB format decoding.
 
----------------------------------------------------------------------
----------------------------------------------------------------------
*/
 
void	Grib_Get_Bits_From_Bytes ( char	*Message,
				   int	*Stockage,
				   int	Adresse,
				   int	Nbits )
{
	int	I_Depart, I_Origine ;
	int	N_Car, I_Equiv, I, J, K1, Ko ;
	char	Buffer ;
 
 
/*
--- Gets the starting bit, and the number of bytes to be read
*/
	I_Depart = Adresse / 8 ;
	I_Origine = Adresse - I_Depart*8 ;
	N_Car = 1 + (Nbits-1)/8 ;
 
/*
--- Gets the number of bits to be read in the last byte
*/
	Ko = 8 ;
	if ((I_Origine == 0)&&((Nbits/8)*8 != Nbits)) Ko=((Nbits/8)+1)*8-Nbits;
	if ( Nbits < 8 ) Ko = I_Origine+Nbits ;
 
	I_Equiv = 0 ;
 
/*
--- If there are several bits to be retrieved
*/
	if ( Nbits != 1 )
	  {
/*
   Reads them and stores them at the right place relative to weights
*/
		for ( I = 1 ; I <= N_Car ; I++ )
		  {
			Buffer = *(Message+I_Depart+I-1) ;
 
 
			K1 = 0 ;
			if ( (I == 1) && (I_Origine != 0) ) K1 = I_Origine ;
 
			for ( J = K1 ; J < 8 ; J++ )
			  {
				if ( getbitbyte(&Buffer, 7-J) == 1 )
				  {
					setbit ( &I_Equiv, 7-J+(N_Car-I)*8 );
				  }
			  } 
		  }
/*
   If we are not finishing on byte boundary, resets the end of the byte
*/
		if ( Ko != 8 )
		  {
			J = I_Equiv ;
			I_Equiv = 0 ;
			for ( I = Ko ; I < 32 ; I++ )
			  {
				K1 = getbit ( &J, I );
				if ( K1 == 1 ) setbit ( &I_Equiv, I-Ko );  
			  }
		  }
	  }
/*
--- If only one bit to retrieve
*/
	else
	  {
		Buffer = *(Message+I_Depart);
		if ( getbitbyte ( &Buffer, 7-I_Origine ) == 1 )
			setbit ( &I_Equiv, 0 ) ;
	  }
 
	*Stockage = I_Equiv ;
}
 
/*
----------------------------------------------------------------------
 
	Gets bit # Numero in integer Entier
 
----------------------------------------------------------------------
*/
 
int	getbit ( int	*Entier,
		 int	Numero )
{
	return ((*Entier >> Numero) & ~(~0 << 1)) ;
}
 
/*
----------------------------------------------------------------------
 
	Gets bit # Numero in byte Byte
 
----------------------------------------------------------------------
*/
 
int	getbitbyte ( char *Byte,
		     int  Numero )
{
	return ((*Byte >> (Numero)) & ~(~0 << 1)) ;
}
 
/*
----------------------------------------------------------------------
 
	Sets bit # Numero in integer Entier
 
----------------------------------------------------------------------
*/
 
void	setbit ( int	*Entier,
		 int	Numero )
{
	*Entier = *Entier | (1 << Numero) ;
}

Avec un petit exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Size, Adr, 24 ) ;
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Code_Table2, Adr+24, 8 ) ;
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Center_Id, Adr+32, 8 ) ;
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Generating_Process,
				   Adr+40, 8 ) ;
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Grid_Definition,
				   Adr+48, 8 ) ;
	for ( i = 0 ; i < 8 ; i++ )
	  {
		Grib_Get_Bits_From_Bytes ( Message, &Struct->Flags[i],
					   Adr+56+i, 1 );
	  }
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Params_Indic, Adr+64, 8 ) ;
.....
	Grib_Get_Bits_From_Bytes ( Message, &Struct->Units_Scale_Factor,
				   Adr+201, 15 ) ;
	Grib_Get_Bits_From_Bytes ( Message, &Signe, Adr+200, 1 ) ;