"Caractères" inconnus dans un fichier texte, non affichables en hexadécimal
13 réponses
Michel Giacomazzi
Bonjour,
J'ai aspiré une portion de site internet avec WinHTTrack et j'ai donc
notamment des fichiers HTML, qui normalement ne comportent rien d'autre
que du texte.
Problème :
Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des
caractères non affichables à la fin de certaines lignes, matérialisés
par des petits carrés.
Lorsque je les ouvre sous un éditeur hexadécimal (HexWorkshop), je n'ai
que des codes normaux.
Exemple :
sous Word : <carré><saut de ligne><carré><saut de ligne>
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de
ligne><saut de ligne>
Un petit exemple (6 ko) sur :
http://michel.giacomazzi.free.fr/telechar/index.zip
Je ne comprends pas ce qui se passe et je ne vois pas de piste de
recherche pour trouver comment éliminer ces caractères bizarres.
Donc si quelqu'un avait une idée ...
Les pages HTML en question s'affichent normalement (un navigateur ignore
ce qu'il ne comprend pas), mais je ne peux pas supprimer ces caractères
spéciaux, si ce n'est un par un.
Ce que je veux faire, que j'ai déja fait souvent pour d'autres sites :
- Aspirer le site
- Virer ce qui est inutile
- Le stocker sur CD pour consultation hors ligne
Pour cela, j'utilise notamment une macro Word perso qui reformate un
ensemble de fichiers HTML.
En l'occurrence, il restait plein de lignes vides après le traitement.
J'ai donc effectué manuellement :
- ouverture sous Word d'une page HTML (en tant que fichier texte)
- remplacement global de "^p^p" par "^p"
ce qui veut dire "remplace 2 sauts de ligne successifs par un seul"
mais <saut de ligne><carré><saut de ligne> n'est pas pris en compte dans
le remplacement, alors qu'à cet endroit on a bien 0D0A 0D0A en hexadécimal.
"Y a quéqu'chos' qui cloch' là-d'dans - J'y retourne immédiat'ment"
(comme chantaient BV puis SR)
Le Mon, 12 Sep 2005 22:14:55 +0200, Michel Giacomazzi écrivait:
Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des caractères non affichables à la fin de certaines lignes, matérialisés par des petits carrés.
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait à mon avis préférable d'utiliser un vrai éditeur de textes tel qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire un truc spécialisé dans le html, (dreamweaver ou autre).
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de ligne) deux fois de suite. Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Le Mon, 12 Sep 2005 22:14:55 +0200, Michel Giacomazzi écrivait:
Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des
caractères non affichables à la fin de certaines lignes, matérialisés
par des petits carrés.
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait
à mon avis préférable d'utiliser un vrai éditeur de textes tel
qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire
un truc spécialisé dans le html, (dreamweaver ou autre).
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de
ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de
ligne) deux fois de suite.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute
interprétation html par Word.
Le Mon, 12 Sep 2005 22:14:55 +0200, Michel Giacomazzi écrivait:
Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des caractères non affichables à la fin de certaines lignes, matérialisés par des petits carrés.
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait à mon avis préférable d'utiliser un vrai éditeur de textes tel qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire un truc spécialisé dans le html, (dreamweaver ou autre).
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de ligne) deux fois de suite. Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Michel Giacomazzi
Eric Rossé a écrit :
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait à mon avis préférable d'utiliser un vrai éditeur de textes tel qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire un truc spécialisé dans le html, (dreamweaver ou autre).
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de ligne) deux fois de suite. Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Cela ne change rien. Merci quand même
Eric Rossé a écrit :
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait
à mon avis préférable d'utiliser un vrai éditeur de textes tel
qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire
un truc spécialisé dans le html, (dreamweaver ou autre).
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des
remplacements dans toutes les pages web aspirées. A ma connaissance il
n'y a pas cela.
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de
ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de
ligne) deux fois de suite.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute
interprétation html par Word.
Euh, msWord en tant qu'éditeur html n'a rien de génial... Il serait à mon avis préférable d'utiliser un vrai éditeur de textes tel qu'Ultra-Edit (payant) ou SrcEdit (si on ne veut pas payer), voire un truc spécialisé dans le html, (dreamweaver ou autre).
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Plus exactement, c'est la séquence <CR><LF> (retour chariot, saut de ligne) deux fois de suite. Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Cela ne change rien. Merci quand même
Sergio
Le 12/09/2005, Michel Giacomazzi a supposé :
J'ai aspiré une portion de site internet avec WinHTTrack et j'ai donc notamment des fichiers HTML, qui normalement ne comportent rien d'autre que du texte. Problème : Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des caractères non affichables à la fin de certaines lignes, matérialisés par des petits carrés. Lorsque je les ouvre sous un éditeur hexadécimal (HexWorkshop), je n'ai que des codes normaux. Exemple : sous Word : <carré><saut de ligne><carré><saut de ligne> sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit : - <lf> suel, texte issu du monde Unix - <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows - <cr> seul, texte issu du monde Mac
La plupart des éditeurs de textes un peu évolués savent s'en tirer. Je viens d'essayer avec mes deux favoris, ça marche : - CONText gratuit http://www.context.cx/ - SciTe gratuit et libre http://www.scintilla.org
Même avec le bloc-note de XP ça marche.
Word n'est pas réputé pour éditer les textes...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 12/09/2005, Michel Giacomazzi a supposé :
J'ai aspiré une portion de site internet avec WinHTTrack et j'ai donc
notamment des fichiers HTML, qui normalement ne comportent rien d'autre que
du texte.
Problème :
Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des
caractères non affichables à la fin de certaines lignes, matérialisés par des
petits carrés.
Lorsque je les ouvre sous un éditeur hexadécimal (HexWorkshop), je n'ai que
des codes normaux.
Exemple :
sous Word : <carré><saut de ligne><carré><saut de ligne>
sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de
ligne><saut de ligne>
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de
lignes sont soit :
- <lf> suel, texte issu du monde Unix
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
- <cr> seul, texte issu du monde Mac
La plupart des éditeurs de textes un peu évolués savent s'en tirer. Je
viens d'essayer avec mes deux favoris, ça marche :
- CONText gratuit http://www.context.cx/
- SciTe gratuit et libre http://www.scintilla.org
Même avec le bloc-note de XP ça marche.
Word n'est pas réputé pour éditer les textes...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
J'ai aspiré une portion de site internet avec WinHTTrack et j'ai donc notamment des fichiers HTML, qui normalement ne comportent rien d'autre que du texte. Problème : Lorsque je les ouvre sous Word 2000 en tant que fichier texte, j'ai des caractères non affichables à la fin de certaines lignes, matérialisés par des petits carrés. Lorsque je les ouvre sous un éditeur hexadécimal (HexWorkshop), je n'ai que des codes normaux. Exemple : sous Word : <carré><saut de ligne><carré><saut de ligne> sous l'éditeur hexa : 0D0A 0D0A, ce qui normalement signifie <saut de ligne><saut de ligne>
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit : - <lf> suel, texte issu du monde Unix - <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows - <cr> seul, texte issu du monde Mac
La plupart des éditeurs de textes un peu évolués savent s'en tirer. Je viens d'essayer avec mes deux favoris, ça marche : - CONText gratuit http://www.context.cx/ - SciTe gratuit et libre http://www.scintilla.org
Même avec le bloc-note de XP ça marche.
Word n'est pas réputé pour éditer les textes...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Eric Rossé
Le Tue, 13 Sep 2005 08:41:10 +0200, Sergio écrivait:
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Même avec le bloc-note de XP ça marche.
Si la séquence est incomplète (fichier issu du monde Unix ou Mac), le bloc-note ne sait pas correctement afficher et mettra des carrés à la place des passage à la ligne.
Word n'est pas réputé pour éditer les textes...
Sauf qu'il est tout de même vendu (depuis la version 97) comme sachant lire et interpréter le html... voire même l'écrire si on n'a pas peur de lire ensuite le généré...
Le Tue, 13 Sep 2005 08:41:10 +0200, Sergio écrivait:
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de
lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la
séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Même avec le bloc-note de XP ça marche.
Si la séquence est incomplète (fichier issu du monde
Unix ou Mac), le bloc-note ne sait pas correctement
afficher et mettra des carrés à la place des passage
à la ligne.
Word n'est pas réputé pour éditer les textes...
Sauf qu'il est tout de même vendu (depuis la version 97)
comme sachant lire et interpréter le html... voire même
l'écrire si on n'a pas peur de lire ensuite le généré...
Le Tue, 13 Sep 2005 08:41:10 +0200, Sergio écrivait:
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Même avec le bloc-note de XP ça marche.
Si la séquence est incomplète (fichier issu du monde Unix ou Mac), le bloc-note ne sait pas correctement afficher et mettra des carrés à la place des passage à la ligne.
Word n'est pas réputé pour éditer les textes...
Sauf qu'il est tout de même vendu (depuis la version 97) comme sachant lire et interpréter le html... voire même l'écrire si on n'a pas peur de lire ensuite le généré...
Eric Rossé
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui peut expliquer l'anomalie obtenue dans une version plus récente.
2 / le document est malformé; il y a des doublons de certaines balises (</body>, </html>) ce qui peut empêcher un affichage correct si l'éditeur est trop strict dans la syntaxe... Et comme word n'est pas simple éditeur de textes, mais essaie de rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...) qu'on se demande comment un navigateur arrive à afficher correctement...
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des
remplacements dans toutes les pages web aspirées. A ma connaissance il
n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers"
d'un éditeur de textes.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute
interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui
peut expliquer l'anomalie obtenue dans une version plus récente.
2 / le document est malformé; il y a des doublons de certaines
balises (</body>, </html>) ce qui peut empêcher un affichage
correct si l'éditeur est trop strict dans la syntaxe... Et
comme word n'est pas simple éditeur de textes, mais essaie de
rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...)
qu'on se demande comment un navigateur arrive à afficher
correctement...
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui peut expliquer l'anomalie obtenue dans une version plus récente.
2 / le document est malformé; il y a des doublons de certaines balises (</body>, </html>) ce qui peut empêcher un affichage correct si l'éditeur est trop strict dans la syntaxe... Et comme word n'est pas simple éditeur de textes, mais essaie de rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...) qu'on se demande comment un navigateur arrive à afficher correctement...
Sergio
Eric Rossé a pensé très fort :
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus. Utiliser OpenOffice à la place ? ;-)
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Eric Rossé a pensé très fort :
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de
lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la
séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus.
Utiliser OpenOffice à la place ? ;-)
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Effectivement, c'est des séquences <cr><lf>. Normalement les fins de lignes sont soit :
- <lf><cr> (et non <cr><lf> !) issu du monde DOS / Windows
Sans vouloir pinailler, j'ai toujours rencontré la séquence hexa 0D 0A; et 0D, c'est <CR> et non <LF>.
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus. Utiliser OpenOffice à la place ? ;-)
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Michel Giacomazzi
Eric Rossé a écrit :
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines. De plus, j'utilise cette macro depuis fort longtemps (la première version était sous Word 6 !), ne l'ai pas modifiée depuis au moins un an et c'est la première fois que je rencontre ce cas de figure.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui peut expliquer l'anomalie obtenue dans une version plus récente.
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
2 / le document est malformé; il y a des doublons de certaines balises (</body>, </html>) ce qui peut empêcher un affichage correct si l'éditeur est trop strict dans la syntaxe... Et comme word n'est pas simple éditeur de textes, mais essaie de rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...) qu'on se demande comment un navigateur arrive à afficher correctement...
Même remarque que précédemment.
Eric Rossé a écrit :
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des
remplacements dans toutes les pages web aspirées. A ma connaissance il
n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers"
d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu
qu'il en a quelques centaines.
De plus, j'utilise cette macro depuis fort longtemps (la première
version était sous Word 6 !), ne l'ai pas modifiée depuis au moins un an
et c'est la première fois que je rencontre ce cas de figure.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute
interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui
peut expliquer l'anomalie obtenue dans une version plus récente.
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que
fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que
fichier *texte*.
2 / le document est malformé; il y a des doublons de certaines
balises (</body>, </html>) ce qui peut empêcher un affichage
correct si l'éditeur est trop strict dans la syntaxe... Et
comme word n'est pas simple éditeur de textes, mais essaie de
rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...)
qu'on se demande comment un navigateur arrive à afficher
correctement...
Le Tue, 13 Sep 2005 05:15:24 +0200, Michel Giacomazzi écrivait:
J'ai Dremweaver 4, mais comme je l'ai dit je cherche à faire des remplacements dans toutes les pages web aspirées. A ma connaissance il n'y a pas cela.
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines. De plus, j'utilise cette macro depuis fort longtemps (la première version était sous Word 6 !), ne l'ai pas modifiée depuis au moins un an et c'est la première fois que je rencontre ce cas de figure.
Essaie le renommage préalable du fichier en .txt ce qui évitera toute interprétation html par Word.
Ayant un peu examiné l'exemple,
1 / word97 affiche "tableaux imbriqués trop complexes", ce qui peut expliquer l'anomalie obtenue dans une version plus récente.
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
2 / le document est malformé; il y a des doublons de certaines balises (</body>, </html>) ce qui peut empêcher un affichage correct si l'éditeur est trop strict dans la syntaxe... Et comme word n'est pas simple éditeur de textes, mais essaie de rendre un résultat "wysiwig"...
3 / Il y a de tels croisements de balises (<form>, <table>,...) qu'on se demande comment un navigateur arrive à afficher correctement...
Même remarque que précédemment.
Michel Giacomazzi
Sergio a écrit :
Eric Rossé a pensé très fort :
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus. Utiliser OpenOffice à la place ? ;-)
Je rappelle quand même que Word est un traitement de texte à la base ... là, ce sont des fonctions élémentaires.
OpenOffice (1.1.2 sous Linux) se met en éditeur HTML, même si l'extension est txt.
Sergio a écrit :
Eric Rossé a pensé très fort :
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus.
Utiliser OpenOffice à la place ? ;-)
Je rappelle quand même que Word est un traitement de texte à la base ...
là, ce sont des fonctions élémentaires.
OpenOffice (1.1.2 sous Linux) se met en éditeur HTML, même si
l'extension est txt.
Argh ! autant pour moi. Alors bizarre que Word se vautre là-dessus. Utiliser OpenOffice à la place ? ;-)
Je rappelle quand même que Word est un traitement de texte à la base ... là, ce sont des fonctions élémentaires.
OpenOffice (1.1.2 sous Linux) se met en éditeur HTML, même si l'extension est txt.
Eric Rossé
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot. Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer, la chaîne remplaçante, le répertoire de départ (sait se promener récursivement dans les sous-répertoires) et le filtre de fichiers. On peut même faire de la macro avec certains éditeurs (par exemple avec UltraEdit).
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux toujours faire un remplacement de ^p par ^p, ça fera disparaître les carrés...
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers"
d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu
qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot.
Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer,
la chaîne remplaçante, le répertoire de départ (sait se promener
récursivement dans les sous-répertoires) et le filtre de fichiers.
On peut même faire de la macro avec certains éditeurs (par exemple
avec UltraEdit).
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que
fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que
fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux
toujours faire un remplacement de ^p par ^p, ça fera disparaître
les carrés...
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot. Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer, la chaîne remplaçante, le répertoire de départ (sait se promener récursivement dans les sous-répertoires) et le filtre de fichiers. On peut même faire de la macro avec certains éditeurs (par exemple avec UltraEdit).
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux toujours faire un remplacement de ^p par ^p, ça fera disparaître les carrés...
Michel Giacomazzi
Eric Rossé a écrit :
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot. Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer, la chaîne remplaçante, le répertoire de départ (sait se promener récursivement dans les sous-répertoires) et le filtre de fichiers. On peut même faire de la macro avec certains éditeurs (par exemple avec UltraEdit).
D'accord, UltraEdit (que je n'avais pas testé jusqu'à présent) fait cela , mais j'ai besoin de de faire des recherches/remplacements successifs sur un ensemble de fichiers (dont je fournis la liste dans un fichier texte)
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux toujours faire un remplacement de ^p par ^p, ça fera disparaître les carrés...
En fait, cela remplace les carrés par des sauts de ligne. Ca ne m'explique pas la cause du problème mais ça permet de le contourner ... et comme ce souci semble très rare, je m'en contenterai ... et te remercie de cette solution.
En l'occurrence, j'utilise Word dans ce cas, non pas par vice, mais pour les possibilités que permettent les macros : c'est de la programmation rudimentaire certes, mais un rapide coup d'oeil sur l'aide d'UltraEdiut me laisse à penser que je ne pourrais pas faire avec une macro ce que je souhaite dans ce cas (ou du moins pas aussi facilement). Deux exemples : - cette macro permet de traiter en une fois un ensemble de fichiers, qu'ils soient dans le même répertoire ou pas (un fichier texte en indique la liste) - elle ne modifie pas les parties dont le formatage est imposé manuellement (<pre>...</pre>, par exemple)
Eric Rossé a écrit :
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers"
d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu
qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot.
Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer,
la chaîne remplaçante, le répertoire de départ (sait se promener
récursivement dans les sous-répertoires) et le filtre de fichiers.
On peut même faire de la macro avec certains éditeurs (par exemple
avec UltraEdit).
D'accord, UltraEdit (que je n'avais pas testé jusqu'à présent) fait cela
, mais j'ai besoin de de faire des recherches/remplacements successifs
sur un ensemble de fichiers (dont je fournis la liste dans un fichier
texte)
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que
fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que
fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux
toujours faire un remplacement de ^p par ^p, ça fera disparaître
les carrés...
En fait, cela remplace les carrés par des sauts de ligne.
Ca ne m'explique pas la cause du problème mais ça permet de le
contourner ... et comme ce souci semble très rare, je m'en contenterai
... et te remercie de cette solution.
En l'occurrence, j'utilise Word dans ce cas, non pas par vice, mais pour
les possibilités que permettent les macros : c'est de la programmation
rudimentaire certes, mais un rapide coup d'oeil sur l'aide d'UltraEdiut
me laisse à penser que je ne pourrais pas faire avec une macro ce que je
souhaite dans ce cas (ou du moins pas aussi facilement).
Deux exemples :
- cette macro permet de traiter en une fois un ensemble de fichiers,
qu'ils soient dans le même répertoire ou pas (un fichier texte en
indique la liste)
- elle ne modifie pas les parties dont le formatage est imposé
manuellement (<pre>...</pre>, par exemple)
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
Utilise alors la fonction "rechercher/remplacer dans des fichiers" d'un éditeur de textes.
Mais il me faudrait alors ouvrir manuellement chaque fichier ... vu qu'il en a quelques centaines.
Mais non, justement; cette fonction traite les fichiers par lot. Tout ce qu'il y a à faire est d'indiquer la chaîne à remplacer, la chaîne remplaçante, le répertoire de départ (sait se promener récursivement dans les sous-répertoires) et le filtre de fichiers. On peut même faire de la macro avec certains éditeurs (par exemple avec UltraEdit).
D'accord, UltraEdit (que je n'avais pas testé jusqu'à présent) fait cela , mais j'ai besoin de de faire des recherches/remplacements successifs sur un ensemble de fichiers (dont je fournis la liste dans un fichier texte)
Pour avoir ce message, je suppose que vous l'avez ouvert en tant que fichier HTML ; ce n'est pas ce que je fais : je l'ouvre en tant que fichier *texte*.
Même en mode texte, word reste un outil inadapté. Mais tu peux toujours faire un remplacement de ^p par ^p, ça fera disparaître les carrés...
En fait, cela remplace les carrés par des sauts de ligne. Ca ne m'explique pas la cause du problème mais ça permet de le contourner ... et comme ce souci semble très rare, je m'en contenterai ... et te remercie de cette solution.
En l'occurrence, j'utilise Word dans ce cas, non pas par vice, mais pour les possibilités que permettent les macros : c'est de la programmation rudimentaire certes, mais un rapide coup d'oeil sur l'aide d'UltraEdiut me laisse à penser que je ne pourrais pas faire avec une macro ce que je souhaite dans ce cas (ou du moins pas aussi facilement). Deux exemples : - cette macro permet de traiter en une fois un ensemble de fichiers, qu'ils soient dans le même répertoire ou pas (un fichier texte en indique la liste) - elle ne modifie pas les parties dont le formatage est imposé manuellement (<pre>...</pre>, par exemple)
