Bonjour.
Merci pour votre soutient.
Désolé marot_r, mais votre dernière explication ne me permet pas de comprendre pourquoi dans une des trois procédures de test on indique manuellement une partie du texte comme balise, mais dans la procédure de test somme des trois autres, on n'indique pas ce même texte.
Cette dernière remarque devrait vous éclairer sur mon niveau résiduel…
Mais tout n'est pas perdu pour autant.
J'ai étudié la situation plus avant, notamment en m'appuyant sur vos propositions.
J'ai 4 pages internet qui sont sensiblement présentées de la même manière, mais le code est différent.
Le contenu de ces 4 pages, que ce soit la partie visible ou les liens qui sont attachés à ce contenu, est très intéressant et permettrait en "ne récupérant que 4 pages seulement" d'avoir pratiquement la totalité des données dont j'ai besoin.
Plutôt que de tenter de recopier les contenus de ces pages (qui sont interminables) tout en garantissant l'anonymat des données qui s'y trouvent, je vais essayer d'indiquer ce que j'ai repéré :
Page 1 :
- La partie intéressante du code est précédée de <tbody> et suivie de </tbody>
- Chaque "contenu de champ" commence par <td> ou <td quelque_chose> et finit par </td>
- Chaque enregistrement débute par <tr>
- Pas de balise <tr> après le dernier enregistrement
- Au début de chaque enregistrement, il y a 3 lignes
1 2 3
| <tr>
<td><span class="plus">+</span></td>
-------- Ligne vierge ----------- |
Le <tr> de la première ligne de ce paragraphe est la balise de début d'enregistrement
Page 2 :
- La partie intéressante du code est précédée de <tbody> et suivie de </table> (présent une seconde fois plus loin dans le code, après celui qui m'intéresse donc, après du code qui n'est pas intéressant)
- Chaque "contenu de champ" commence <td> et finit par </td>
- Le premier enregistrement est précédé d'une ligne avec uniquement <tr> et un retour à la ligne
- Chaque enregistrement se termine par <tr> et un retour à la ligne
- Chaque enregistrement est composé de 2 lignes
- Pas de balise <tr> après le dernier enregistrement
- En plein milieu du code intéressant, il y a un bloc de texte inutile qui n'est pas formaté comme le reste des enregistrements et qui démarre avec <td class="notvisibleInCsv"> et finit avec </td>Ce paragraphe pourrait planter la procédure (sauf si on ajoute un système qui le supprime avant d'extraire le contenu, ou un système qui le traite comme le reste et je supprimerais la ligne correspondante dans la table finale)
Page 3 :
- La partie intéressante du code est précédée de <tbody> et suivie de </table> (présent une seconde fois plus loin dans le code, après celui qui m'intéresse donc, après du code qui n'est pas intéressant)
- Chaque "contenu de champ" commence <td> et finit par </td>
- Chaque enregistrement débute par <tr>
- A la fin de chaque enregistrement il y a un morceau qui commence à la fin de la ligne de l'enregistrement et finit plusieurs lignes après, au début de l'enregistrement suivant :
1 2 3 4 5 6 7 8 9
| FIN DES DONNÉES UTILES de l'ENREGISTREMENT</a><br/></td> <td class="notvisibleInCsv">
<div class="btn-group">
<button type="button" class="btn btn-default dropdown-toggle" data-toggle="dropdown">
Action
<span class="caret"></span>
</button>
<ul class="dropdown-menu">
<li><a href="pdfgen/enrolment.php?uid=6777" target="_blank">Texte Affiché</a></li></ul>
</div></td></tr><tr><td>DEBUT DE L'ENREGISTREMENT SUIVANT |
Les balises <td> et </td> sont donc "perdues" au milieu de retours à la ligne…
Et du coup, il y a aussi une balise <tr> à la fin du dernier enregistrement
Page 4 :
- La partie intéressante du code est précédée de <tbody> et suivie de </table> (présent une autre fois plus loin dans le code)
- Chaque "contenu de champ" commence <td> et finit par </td>
- Chaque enregistrement se termine par <tr> et un retour à la ligne
- Le premier enregistrement est précédé d'une ligne avec uniquement <tr> et un retour à la ligne
Autres :
- Il n'y a pas toujours de balise </tbody> ou <table>
- Des fois <td> est au début de la ligne, dès fois seul sur la ligne avant
- Des fois on a <td class> (1 espace entre td et class), des fois <td class> (2 espaces entre td et class)…
- Des fois il y a une balise de fermeture du même type que celle d'ouverture (<Ouverture> au début et </Ouverture> à la fin),
- Des fois pas de balise de fermeture du même type que celle d'ouverture (peut-être que certaines balises </table> ferment tout ce qui a été ouvert avant et du coup si on en a besoin pour le dernier enregistrement il faudra la garder dans la phase de récupération du code interessant).
- Je ne sais pas si le fait que les balises soient au début de la ligne, une ligne avant, ou en fin de la ligne précédente influe quelque chose dans le fonctionnement du code et/ou dans sa lecture par une procédure
Idéalement une procédure du type suivant pourrait être la solution :
NomProcédure(LireHTML, BaliseDébutCode, BaliseFinCode, BaliseDébutChamp, BaliseFinChamp, BaliseDebutEnregistrement, [BaliseFinEnregistrement], [BaliseFinDernierEnregistrement])
Les deux derniers arguments pourraient être facultatifs…
Et le résultat serait une table (Même moche).
Je vois à peu près comment je pourrais simplifier et alléger les enregistrements via des requêtes successives.
J'en profite pour indiquer que je ne trouve plus le type de champ Memo sur Access 2016. On à juste le choix entre texte cours et texte long. Je suppose que texte long = memo, vu que j''ai pu y caser les 2500 caractères du code d'un enregistrement.
Mais je ne pourrais pas y arriver tant que je n'aurais pas le contenu de ces enregistrements dans une table… et de préférence avec une seule ligne par enregistrement et une colonne par champ.
Paradoxalement, je ne pourrais vérifier la faisabilité qu'en testant sur plusieurs dizaines de lignes (c'est généralement là qu'on voit si les moulinettes en ont oublié).
Très clairement, je n'ai pas les compétences pour créer le code nécessaire à faire tout cela.
Je vais essaye de voir si je peux me débrouiller en transformant LireHTLML en table pour commencer...
Encore merci.
Partager