Salut,
j'ai créé un logiciel (en c++) qui doit lire des fichiers binaires. La plupart du temp il viennent de PC et pas de problème... seulement dans certains cas, il vienne de stations UNIX et sont donc en big endian.    
J'ai donc créé une petite moulinette de conversion et ca interverti bien mes octets   (sous un éditeur hexa j'avait 01 02 03 04 et après 04 03 02 01 par exemple). Le problème vien des chaines de caractères qui, elle ne doivent a priori pas être interverties (dans le fichier unix, si j'avais "CHAINE  " ca me donne "IAHC  EN" ): comment on peut faire pour savoir si il faut ou non intervertir les octets si on ne connait pas le format du fichier à l'avance?    
J'espère être clair dans ma question  

ben les stations unix peuvent utiliser la meme endianess que ton PC. ton problème est insoluble: tu te frottes à un problème ou il n'y a que 2 solutions viables: décider une fois pour toute de lordre des octets(et il existe plein d'autre chose que little et big) ou utiliser une représentation textuelle portable. bref il faut revenir à ce qu'est un fichier binaire: un fichier non binaire. rien à voir avec l'OS. tu vas peut etre arriver à te démener pour faire marcher avec un seul fichier venant d'un ordinateur particulier, mais ça ne marchera pas avec les autres. pense aussi à autre chose: la taille des entiers vairent d'une machine à l'autre (la taille d'un int varie)

Je trouve ta question un peu bizarre.
Normalement, quand tu lis un fichier, tu sais si tu dois lire des nombres ou des chaines de caracteres.
Si tu lis des nombres, tu transformes.
Si tu lis des chaines, ben c'est bon, tu ne fais rien de plus.
 
Apparement, ton problème vient du fait que tu ne sais pas ce qu'il y a dans le fichier => aucune solution possible sans savoir ce que tu lis.
 

En fait, je sais ce que je dois lire mais le format est assez complexe et si je me lance dans la gestion de tous les cas, j'en ai pour un bon bout de temps mais si je ne peux as y échapper, c'est ce que je vais faire...
Pour être plus précis je dois lire des OP2 venant de NASTRAN (un logiciel de calcul elements finis) qui tourne sur pc ou sous unix, d'ou les deux possibilités de format de fichier. Les fichiers OP2 contiennent des dizaines de sortes de résultats et pour chaque type il y a des valeurs entières, réelle et ascii... ce qui fait une masse de travail assez grande si je dois faire du cas par cas...

Tu récupères comment ces fichiers ?

En général, ils tournent sur un serveur mais je ne sais pas comment les gens les récupèrent... en tout cas, dans un éditeur hexa, les octets sont bien inversés 4 par 4... sauf pour les chaines de caractères...
mais je pense qu'effectivement je vais devoir traiter tous les cas ou il y a des chaines de caractères(les positions de ces chaines dépendent des valeurs entières et réelles du reste du fichier)

Vu que c'est des données 32 bits, je pense transformer tout le fichier puis rechercher les endroit ou il y a des chaines de caractères pour les remettre dans le bon ordre...
Est-ce que ca c'est correct si je veut inverser tout mon fichier?:

Le problème c'est que mon fichier de sortie ne fait pas la même taille que mon fichier d'entrée    ... quelqu'un voit-il une solution?

C'est un peu cavalier ton code, que se passe-t-il si le fichier d'entré n'a pas une taille multiple de 4 ?
Par curiosité, la différence de taille des 2 fichiers est de combien ?

Je sais que le fichier à obligatoirement une taille multiple de 4 (les réels et entier sont sur 32 bits et les valeurs alphanum sont écrites par groupe de 4 caractères)...
Mon fichier d'entrée fait 7033748 octets et le fichier de sortie 7049435 octets   (heu, c'est impaire mais ca doit être du au fait que je fait un read dans le while pour savoir si c'est la fin du fichier)...

Heu... c'est bon pour le nombre d'octets: j'ouvraibien le fichier pour lecture binaire (flag: wb), mais pour l'écriture j'avais oublié le b...

Au moment où tu lis chaque groupe de 4 octets, tu dois savoir sous quel format le décoder, tu ne peux pas y couper (parce qu'il n'y a pas moyen de différencier 4 octets qui représentent un entier au format machine -x86, sparc, etc- de 4 octets qui font parties d'un texte ascii).

OK merci, je m'en suis sorti      :  
dans un premier temp je converti tout le fichier et après, en fonction des valeurs réelles et entières je déduit les emplacement ou il doit y avoir du texte et là je re-inverse pour que ca revienne dans le bon sens...

Bonjour,
Je suis à la recherche du format de lecture des fichiers op2 nastran. EN fait, j'utilise le C, C++ et fortan pour lire des fichiers résultats de calcul élément finis pour les post traiter en fatigue.
Jusqu'à là je n'ai pas trouvé une documentation claire sur le format des fichiers op2.  
Je serai reconnaissant si quelqu'un ici peut m'aider dans ce sens.
merci.