Je n'ai pas dit fin de ligne mais fin de chaînes ! Le caractères fin de chaîne c'est le caractère '\0' qui a la valeur numérique 0. ton fichier en est bourré !
Désolé, je n'ai pas compris la composition de ton fichier, qui semble venir d'un éditeur hexa. C'est un fichier texte sous la forme que tu as posté alors ?
Pour toi, c'est quoi un bloc, tout ce qui ce trouve entre DATA_BLK et la ligne vide ? Je ne comprend pas tout !
Argh, c'est compliqué... C'est vrai que la tête de l'exemple ci-dessus suggère un fichier binaire vu par un éditeur hexadécimal. Mais qu'est-ce que c'est, ce fichier sur lequel tu travailles depuis quelque temps ? Là maintenant, j'avoue que je suis un peu découragé. C'est si compliqué !
Est-ce que ce fichier a un format précis, documenté ?
- tu cherches le \n qui la termine, puis +1 --> tu as le début de ton bloc (void *block_begin) (à faire seulement si la ligne clé ne doit pas être incluse dans le bloc)
- à partir de block_begin, tu cherches les \n. Dès que tu en as deux qui se suivent, tu sais que le second est le début de ta ligne vierge
Tu n'as plus qu'a copier le bloc où tu le souhaites (tu as le début et la longueur)
- Edité par edgarjacobs 24 juin 2020 à 23:18:56
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
- tu cherches le \n qui la termine, puis +1 --> tu as le début de ton bloc (void *block_begin) (à faire seulement si la ligne clé ne doit pas être incluse dans le bloc)
- à partir de block_begin, tu cherches les \n. Dès que tu en as deux qui se suivent, tu sais que le second est le début de ta ligne vierge
Tu n'as plus qu'a copier le bloc où tu le souhaites (tu as le début et la longueur)
- Edité par edgarjacobs il y a 7 minutes
Ça me parait bien, je vais essayer un truc du genre !
robun a écrit:
Argh, c'est compliqué... C'est vrai que la tête de l'exemple ci-dessus suggère un fichier binaire vu par un éditeur hexadécimal. Mais qu'est-ce que c'est, ce fichier sur lequel tu travailles depuis quelque temps ? Là maintenant, j'avoue que je suis un peu découragé. C'est si compliqué !
Est-ce que ce fichier a un format précis, documenté ?
- Edité par robun il y a 31 minutes
Pourquoi compliquer ? au final les traitement du fichier se fait comme un fichier texte, juste en remplaçant le strstr par binstr.
Et non ce fichier n'a pas de documentation, c'est un dump system, en gros c'est une image des machines à l'instant où elles ont un crash.
Donc tu imagine bien que les informations sont de base en binaire et converti en texte par je ne sais quel moyen.
Le genre d'idée que j'avais en tête, c'est que par exemple dans un fichier de ce type, les blocs font toujours 1024 octets (valeur au hasard). Ça ne me surprendrait pas du tout (puisque les fichiers dumps sont destinés à être lus automatiquement par des programmes de débogage). Connaître ce genre d'information faciliterait ta tâche.
Il faut que je récupère un bloc de texte situé entre une ligne clé et s’arrêtant à une ligne vierge.
Une ligne vierge, je c'est ce que c'est. Du moins je crois, ton fichier a des ligne de longueur fixe apparemment, je suppose que le "<br>*" est un parasite ?
Mais une ligne clé je ne sais pas, comment tu reconnais une ligne clé ! Je te pose la question pour ne pas partir dans un sujet à 31 ou 54 post !
Pour moi la ligne clé ça serait " " avec le nombre d'espace égal à celui de la ligne vide du dump.
Donc la clé et la ligne "vide" (constituée uniquement d'espaces) sont des lignes identiques ? Donc tu cherches à récupérer le bloc entre deux lignes vide (constituée uniquement d'espaces) ? Je sens qu'il va falloir cinquante post pour savoir ce que tu souhaites faire ! (J'aurais capitulé avant) !
//ligne vide ici qui ne s'affiche pas, ne pas prendre en compte <br>
Comme tu peux le voir le début du bloc à rechercher commence par le mot clé "DATA BLK," et se fini par une ligne composée de 135 espaces.
Il faut donc que je récupère tout (sauf les lignes "SYSTEM ERROR NUMBER OPR-I000004 VIRTUAL STORAGE ERROR TAPE G01738 DUMP 3589 PAGE 00000166" mais c'est un détail on verra plus tard)
ce qu'il y a entre "DATA BLK, LEVEL 1" et la première ligne d'espace.
Puis ce qu'il y a entre "DATA BLK, LEVEL 3" et la deuxième ligne d'espace.
Puis ce qu'il y a entre "DATA BLK, LEVEL 4" et la troisième ligne d'espace.
etcétéra etcétéra etcétéra...
Jusqu'au "LEVEL F"
J'espère que ça t’éclaircit l'esprit, sinon je ne peux plus rien pour toi !!!
C'est pourquoi, mon premier algorithme :
lire ligne fichier
| POUR nb_info_a_rechercher
| SI info_affichée=FALSE
| rechercher_chaine --> resultat
| afficher ce_qu'il_y_a_apres_chaine
| info_affichée=TRUE
Et je voudrais :
Lire ligne fichier
rechercher chaine (DATA BLK, LEVEL)
SI chaine trouvée
TANTQUE ligne != " "
afficher ligne
J'espère que mes explications sont clairs cette fois !
(Je viens de taper cette réponse avant d'avoir vu l'explication détaillée d'ElouanBesnard. Je corrige en vert...)
J'avais compris que la ligne-clé est la ligne qui commence par le mot-clé "DATA BLK" qui veut probablement dire « bloc de données ». Le but est de récupérer ce « bloc de données », qui est situé entre la ligne-clé et la prochaine ligne vide (en fait une ligne de 135 espaces).
Si on lit ligne par ligne, il faut donc détecter qu'on est sur une ligne-clé (facile), puis continuer à parcourir les lignes, mais cette fois en les recopiant quelque part, et arrêter la recopie dès qu'on tombe sur une ligne vide (une ligne de 135 espaces). En gros :
Lire une ligne
Si la ligne commence par un mot-clé :
/* Traitement du bloc associé à ce mot-clé */
Initialiser bloc := un tableau de lignes
Initialiser le booléen fin_bloc := false
Faire :
Lire une ligne
Si la ligne n'est pas vide : // n'est pas faite de 135 espaces
L'envoyer dans 'bloc'
Incrémenter l'indice du tableau 'bloc'
sinon :
/* Fin du bloc */
fin_bloc := true
Exploiter le bloc, ou le stocker quelque part, je ne sais pas...
Jusqu'à fin_bloc
Tu n'y arriveras pas avec la boucle que je t'avais montrée. Là, tu vas commencer à faire du bidouillage "pour que ça fonctionne avec le code de base". Mais il s'agit d'un traitement spécifique: repérage d'un début et d'une fin de bloc, et copie (quelque part) des lignes qui s'y trouvent, mais à la condition (je suppose) qu'elles commencent pas un chiffre.
Pour les deux \n qui se suivent, je ne pouvais savoir que la ligne contenait des espaces: ce n'est pas visible à l'écran. Encore un manque d'info (quoique c'est peut-être moi qui ai n'ai pas saisi la subtilité entre 'vierge' et 'vide'). Et je ne me baserais pas sur le fait qu'il y ait 135 espaces, je me baserai sur le fait qu'il n'y ait que des espaces.
Ce qui est dommage, c'est que si tu avais exposé clairement tout le machin dès ton premier post, il y avait surement une solution plus adaptée.
- Edité par edgarjacobs 25 juin 2020 à 19:21:27
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
J'ai donné un algorithme qui me semble adéquat, donc j'ai la conscience tranquille...
ElouanBesnard : au fait, tu en penses quoi, de cet algorithme ?
Mais c'est vrai que c'est difficile de t'aider. Tu demandes de l'aide concernant des points précis, c'est très bien, c'est la bonne façon de faire, et tu donnes les infos concernant ces points précis. Du coup on n'a pas la vision globale du sujet, ce qui fait que c'est encore plus difficile pour nous. Le risque, c'est qu'on ne peut que répondre à tes questions. C'est risqué parce que si tu pars dans une mauvaise direction, on ne le saura pas et on t'aidera à avancer dans la mauvaise direction.
Par exemple je soupçonne toujours que le fichier de départ a un format connu (par des gens, pas forcément par toi) et documenté (quelque part). Si c'est le cas, il faut forcément exploiter ce format, ce que tu ne fais pas (puisque tu penses, si j'ai bien compris, qu'il n'a pas de format connu − c'est peut-être vrai, mais je suis sceptique). Tiens, un exemple : je me souviens que tu n'avais pas remarqué que les deux caractères indiquant la version étaient toujours à la même position dans la ligne. Du coup, tu voulais les trouver en avançant dans le fichier jusqu'à tomber dessus. C'est bien plus simple si on remarque qu'ils sont toujours à la même position dans la ligne : on y accède directement avec leur indice. Mais si on ne connaît pas ce genre de détail, on se retrouve à t'aider à avancer dans le fichier, donc à perdre du temps...
Ah oui, le machin dans lequel (ibm 360) il fallait d'abord décoder le psp avant de pouvoir analyser d'où venait le plantage
- Edité par edgarjacobs il y a 2 minutes
Tu as connu ce genre de monstre? Ce n'était pas mieux avec le CDC Cyber 74 (bonus, le dump était en octal)
Le Tout est souvent plus grand que la somme de ses parties.
Extraire un bloc d'un fichier texte
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.