Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Un exemple de ce qui est représentable en texte et pas autrement ? Du texte !
Le texte est une suite de caractere ascii, et c'est du binaire ! C'est dans un ordinateur donc c'est binaire ou on m'aurait menti ;-P
Doms.
Loïc Joly
Un format texte a typiquement beaucoup de rédondance, c-à-d qu'il faut plus de bits physiques pour représenter la même quantité de bits d'information réele (mais ce n'est pas toujours le cas, et les formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles, dont la majorité valait 0. Et bien la sauvegarde en format texte prenait beaucoup moins de place qu'en format binaire.
-- Loïc
Un format
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut
plus de bits physiques pour représenter la même quantité de bits
d'information réele (mais ce n'est pas toujours le cas, et les
formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles,
dont la majorité valait 0. Et bien la sauvegarde en format texte prenait
beaucoup moins de place qu'en format binaire.
Un format texte a typiquement beaucoup de rédondance, c-à-d qu'il faut plus de bits physiques pour représenter la même quantité de bits d'information réele (mais ce n'est pas toujours le cas, et les formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles, dont la majorité valait 0. Et bien la sauvegarde en format texte prenait beaucoup moins de place qu'en format binaire.
-- Loïc
James Kanze
On May 1, 1:54 pm, Fabien LE LEZ wrote:
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard :
Un exemple de ce qui est représentable en texte et pas autrement ?
Un nombre décimal par exemple, sera plus précis en texte que sous fo rme de flottant.
Si tu veux représenter un flottant machine (float ou double), le format binaire (i.e. copie directe depuis la RAM) gardera toutes les informations, sans aucune perte. Une conversion en décimal, au contraire, perdra des informations la plupart du temps, même s'il y a cent chiffres décimaux.
Pas forcément, mais d'abord, il faudrait définir ce qu'on entend par « perdre des informations ». Toute valeur représentable dans un double IEEE peut se représenter exactement comme fraction décimale, avec au maximum 52 chiffres. Si dans le contexte, en revanche, on s'ait qu'il s'agit d'un double IEEE, et non simplement d'un réel quelconque, 17 chiffres décimaux suffissent pour savoir sans ambiguité lequel (et donc, de les transmettre sans perte d'information).
Enfin, d'autres formats, sont possible. On pourrait, par exemple, transmettre la mantisse multiplié par 2^52 (ce qui en fait un entier, représentable exactment), avec la signe et l'exposant. Voire simplement un dump des 8 octets, en hexadécimal (16 caractères totaux) ou base-64 (12 caractères).
Et on peut dire la même chose d'un flottant codé en RAM sur 1000 bits : une copie des octets de la RAM vers le disque garantit l'absence de perte, donc une précision aussi parfaite que possible.
Certes, on peut représenter un nombre décimal sous forme de texte, mais on ne pourra pas le charger dans un flottant. Par ailleurs, on peut représenter le même nombre en base 100, ce qui permet de le stocker avec deux fois moins d'octets, mais dans un format non lisible par un humain.
Base 100 est la solution adoptée souvent quand la spécification exige BCD packé, et que le hardware ne le supporte pas. Ce n'est pas trop difficile d'écrire une classe qui se comporte comme si c'était du BCD, mais qui internalement travaille en base 100. (Si mes souvenirs sont exacts -- ma ça date -- le format « portable » des flottants en CISAM était base 100.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 1, 1:54 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard
<loufo...@gmail.com>:
Un exemple de ce qui est représentable en texte et pas autrement ?
Un nombre décimal par exemple, sera plus précis en texte que sous fo rme
de flottant.
Si tu veux représenter un flottant machine (float ou double), le
format binaire (i.e. copie directe depuis la RAM) gardera toutes les
informations, sans aucune perte. Une conversion en décimal, au
contraire, perdra des informations la plupart du temps, même s'il y a
cent chiffres décimaux.
Pas forcément, mais d'abord, il faudrait définir ce qu'on entend
par « perdre des informations ». Toute valeur représentable
dans un double IEEE peut se représenter exactement comme
fraction décimale, avec au maximum 52 chiffres. Si dans le
contexte, en revanche, on s'ait qu'il s'agit d'un double IEEE,
et non simplement d'un réel quelconque, 17 chiffres décimaux
suffissent pour savoir sans ambiguité lequel (et donc, de les
transmettre sans perte d'information).
Enfin, d'autres formats, sont possible. On pourrait, par
exemple, transmettre la mantisse multiplié par 2^52 (ce qui en
fait un entier, représentable exactment), avec la signe et
l'exposant. Voire simplement un dump des 8 octets, en
hexadécimal (16 caractères totaux) ou base-64 (12 caractères).
Et on peut dire la même chose d'un flottant codé en RAM sur
1000 bits : une copie des octets de la RAM vers le disque garantit
l'absence de perte, donc une précision aussi parfaite que possible.
Certes, on peut représenter un nombre décimal sous forme de texte,
mais on ne pourra pas le charger dans un flottant.
Par ailleurs, on peut représenter le même nombre en base 100, ce qui
permet de le stocker avec deux fois moins d'octets, mais dans un
format non lisible par un humain.
Base 100 est la solution adoptée souvent quand la spécification
exige BCD packé, et que le hardware ne le supporte pas. Ce n'est
pas trop difficile d'écrire une classe qui se comporte comme si
c'était du BCD, mais qui internalement travaille en base 100.
(Si mes souvenirs sont exacts -- ma ça date -- le format
« portable » des flottants en CISAM était base 100.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Tue, 01 May 2007 13:19:34 +0200, Mathias Gaunard :
Un exemple de ce qui est représentable en texte et pas autrement ?
Un nombre décimal par exemple, sera plus précis en texte que sous fo rme de flottant.
Si tu veux représenter un flottant machine (float ou double), le format binaire (i.e. copie directe depuis la RAM) gardera toutes les informations, sans aucune perte. Une conversion en décimal, au contraire, perdra des informations la plupart du temps, même s'il y a cent chiffres décimaux.
Pas forcément, mais d'abord, il faudrait définir ce qu'on entend par « perdre des informations ». Toute valeur représentable dans un double IEEE peut se représenter exactement comme fraction décimale, avec au maximum 52 chiffres. Si dans le contexte, en revanche, on s'ait qu'il s'agit d'un double IEEE, et non simplement d'un réel quelconque, 17 chiffres décimaux suffissent pour savoir sans ambiguité lequel (et donc, de les transmettre sans perte d'information).
Enfin, d'autres formats, sont possible. On pourrait, par exemple, transmettre la mantisse multiplié par 2^52 (ce qui en fait un entier, représentable exactment), avec la signe et l'exposant. Voire simplement un dump des 8 octets, en hexadécimal (16 caractères totaux) ou base-64 (12 caractères).
Et on peut dire la même chose d'un flottant codé en RAM sur 1000 bits : une copie des octets de la RAM vers le disque garantit l'absence de perte, donc une précision aussi parfaite que possible.
Certes, on peut représenter un nombre décimal sous forme de texte, mais on ne pourra pas le charger dans un flottant. Par ailleurs, on peut représenter le même nombre en base 100, ce qui permet de le stocker avec deux fois moins d'octets, mais dans un format non lisible par un humain.
Base 100 est la solution adoptée souvent quand la spécification exige BCD packé, et que le hardware ne le supporte pas. Ce n'est pas trop difficile d'écrire une classe qui se comporte comme si c'était du BCD, mais qui internalement travaille en base 100. (Si mes souvenirs sont exacts -- ma ça date -- le format « portable » des flottants en CISAM était base 100.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 1 May 2007 23:54:43 -0700, James Kanze :
Toute valeur représentable dans un double IEEE peut se représenter exactement comme fraction décimale, avec au maximum 52 chiffres.
Oups, oui, effectivement... J'avais oublié que 2 divise 10 :-/
On 1 May 2007 23:54:43 -0700, James Kanze <james.kanze@gmail.com>:
Toute valeur représentable
dans un double IEEE peut se représenter exactement comme
fraction décimale, avec au maximum 52 chiffres.
Oups, oui, effectivement... J'avais oublié que 2 divise 10 :-/
Toute valeur représentable dans un double IEEE peut se représenter exactement comme fraction décimale, avec au maximum 52 chiffres.
Oups, oui, effectivement... J'avais oublié que 2 divise 10 :-/
James Kanze
On May 2, 6:23 am, Loïc Joly wrote:
Un format
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut plus de bits physiques pour représenter la même quantité de bits d'information réele (mais ce n'est pas toujours le cas, et les formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles, dont la majorité valait 0. Et bien la sauvegarde en format texte prenait beaucoup moins de place qu'en format binaire.
Et un format binaire sur mesure aurait peut-être pris encore moins de place. (Disons, un bool « isZero », suivi du flottant en binaire seulement dans le cas de faux.) De même, si tu avais systèmatiquement formatté chacun des doubles en format scientifique, avec 16 chiffres derrière le décimal, le format texte n'aurait pas été plus court.
En général, si les valeurs ne sont pas réparties d'une façon un peu aléatoire, on a souvent intérêt à adopter un format à longueur variable. Un format texte qui ne sort pas les '0' sans signification, par exemple. Ou le format des entiers à longueur variable de BER : 7 bits par octets, avec le bit de poids forts comme drappeau de fin. (On n'a donc besoin que d'un octet pour des valeurs de 0 a 127, mais on peut également représenter toutes les valeurs possibles. C'est une bonne solution, par exemple, pour la longueur d'une chaîne de texte, où on a très souvent des valeurs inférieur à 127, mais où on pourrait, à l'occasion, avoir des valeurs très élevées.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 2, 6:23 am, Loïc Joly <loic.actarus.j...@numericable.fr> wrote:
Un format
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut
plus de bits physiques pour représenter la même quantité de bits
d'information réele (mais ce n'est pas toujours le cas, et les
formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles,
dont la majorité valait 0. Et bien la sauvegarde en format texte prenait
beaucoup moins de place qu'en format binaire.
Et un format binaire sur mesure aurait peut-être pris encore
moins de place. (Disons, un bool « isZero », suivi du flottant
en binaire seulement dans le cas de faux.) De même, si tu avais
systèmatiquement formatté chacun des doubles en format
scientifique, avec 16 chiffres derrière le décimal, le format
texte n'aurait pas été plus court.
En général, si les valeurs ne sont pas réparties d'une façon un
peu aléatoire, on a souvent intérêt à adopter un format à
longueur variable. Un format texte qui ne sort pas les '0' sans
signification, par exemple. Ou le format des entiers à longueur
variable de BER : 7 bits par octets, avec le bit de poids forts
comme drappeau de fin. (On n'a donc besoin que d'un octet pour
des valeurs de 0 a 127, mais on peut également représenter
toutes les valeurs possibles. C'est une bonne solution, par
exemple, pour la longueur d'une chaîne de texte, où on a très
souvent des valeurs inférieur à 127, mais où on pourrait, à
l'occasion, avoir des valeurs très élevées.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
texte a typiquement beaucoup de rédondance, c-à-d qu'il faut plus de bits physiques pour représenter la même quantité de bits d'information réele (mais ce n'est pas toujours le cas, et les formats binaires ont souvent de la rédondance aussi).
On a effectivement eu le cas d'un fichier qui contenait des doubles, dont la majorité valait 0. Et bien la sauvegarde en format texte prenait beaucoup moins de place qu'en format binaire.
Et un format binaire sur mesure aurait peut-être pris encore moins de place. (Disons, un bool « isZero », suivi du flottant en binaire seulement dans le cas de faux.) De même, si tu avais systèmatiquement formatté chacun des doubles en format scientifique, avec 16 chiffres derrière le décimal, le format texte n'aurait pas été plus court.
En général, si les valeurs ne sont pas réparties d'une façon un peu aléatoire, on a souvent intérêt à adopter un format à longueur variable. Un format texte qui ne sort pas les '0' sans signification, par exemple. Ou le format des entiers à longueur variable de BER : 7 bits par octets, avec le bit de poids forts comme drappeau de fin. (On n'a donc besoin que d'un octet pour des valeurs de 0 a 127, mais on peut également représenter toutes les valeurs possibles. C'est une bonne solution, par exemple, pour la longueur d'une chaîne de texte, où on a très souvent des valeurs inférieur à 127, mais où on pourrait, à l'occasion, avoir des valeurs très élevées.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Yann Renard
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML
pour former une structure hiérarchique binaire. C'est utilisé comme base
au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là :
http://ebml.sourceforge.net/specs/
http://ebml.sourceforge.net/
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
TestMan
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ... mais au prix du cout processeur. Pas grave is la solution est de type point à point, mais s'il y a un central soumit à une grosse charge l'impact vaut à y réfléchir.
A+ TM
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML
pour former une structure hiérarchique binaire. C'est utilisé comme base
au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là :
http://ebml.sourceforge.net/specs/
http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+
Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ...
mais au prix du cout processeur. Pas grave is la solution est de type
point à point, mais s'il y a un central soumit à une grosse charge
l'impact vaut à y réfléchir.
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ... mais au prix du cout processeur. Pas grave is la solution est de type point à point, mais s'il y a un central soumit à une grosse charge l'impact vaut à y réfléchir.
A+ TM
TestMan
Hello
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
Bonjour PKD,
Pouvez-vous détailler la raison qui vous fait écarter IIOP dès le départ ?
Intégré en standard dans Java, portable quelque soit les machines et les languages (et forcement C++), compact, performant, distribué, sécurisé ...
PS: Envoi croisé sur f.c.l.c supprimé ;-)
A+ TM
Hello
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
Bonjour PKD,
Pouvez-vous détailler la raison qui vous fait écarter IIOP dès le départ ?
Intégré en standard dans Java, portable quelque soit les machines et les
languages (et forcement C++), compact, performant, distribué, sécurisé ...
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
Bonjour PKD,
Pouvez-vous détailler la raison qui vous fait écarter IIOP dès le départ ?
Intégré en standard dans Java, portable quelque soit les machines et les languages (et forcement C++), compact, performant, distribué, sécurisé ...
PS: Envoi croisé sur f.c.l.c supprimé ;-)
A+ TM
Yann Renard
TestMan wrote:
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ... mais au prix du cout processeur. Pas grave is la solution est de type point à point, mais s'il y a un central soumit à une grosse charge l'impact vaut à y réfléchir.
A+ TM
Il ne s'agit pas d'EBXML mais d'EBML
Yann
TestMan wrote:
Philip K Dick wrote:
Hello
Je cherche des solutions pour encoder/décoder
des structures de données que je puisse échanger
entre des programmes Java et C++.
Qui plus est, je souhaiterais :
- que les programmes puissent tourner indifféremment
sur des machines à représentation big ou little endian
- que l'encodage soit le plus compact possible car
destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de
type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML
pour former une structure hiérarchique binaire. C'est utilisé comme
base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là :
http://ebml.sourceforge.net/specs/
http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+
Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ...
mais au prix du cout processeur. Pas grave is la solution est de type
point à point, mais s'il y a un central soumit à une grosse charge
l'impact vaut à y réfléchir.
Je cherche des solutions pour encoder/décoder des structures de données que je puisse échanger entre des programmes Java et C++.
Qui plus est, je souhaiterais : - que les programmes puissent tourner indifféremment sur des machines à représentation big ou little endian - que l'encodage soit le plus compact possible car destiné à des échanges par réseau
(Je ne souhaite pas m'orienter vers des solution de type CORBA ou DCOM).
Merci d'avance pour toute piste !
PKD
L'EBML (extensible binary markup language) reprend la logique du XML pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
A+ Yann
Bonjour,
Sauf erreur, EBXML n'est pas vraiment "compact" ;-)
Bien sûr on peut envisager du FastInfoset ou tout autre compression ... mais au prix du cout processeur. Pas grave is la solution est de type point à point, mais s'il y a un central soumit à une grosse charge l'impact vaut à y réfléchir.
A+ TM
Il ne s'agit pas d'EBXML mais d'EBML
Yann
Mathias Gaunard
L'EBML (extensible binary markup language) reprend la logique du XML
Tout spécialiste du XML dira que ça n'a pas grand chose à voir, en fait.
pour former une structure hiérarchique binaire. C'est utilisé comme base au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là : http://ebml.sourceforge.net/specs/ http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
Non seulement gratuite, mais libre en plus. Mais il n'y a pas d'implémentation Java.
L'EBML (extensible binary markup language) reprend la logique du XML
Tout spécialiste du XML dira que ça n'a pas grand chose à voir, en fait.
pour former une structure hiérarchique binaire. C'est utilisé comme base
au container audio/video matroska. Je pense que ça peut t'aider.
Tu peux trouver plus d'infos là :
http://ebml.sourceforge.net/specs/
http://ebml.sourceforge.net/
Il y a une implémentation C++ gratuite.
Non seulement gratuite, mais libre en plus.
Mais il n'y a pas d'implémentation Java.
