"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)
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 ? ;-)
J'ai eu des problèmes de ce genre aussi, assez récemment. Je soupçonne un scénario foireux dans le genre:
- fichier initialement en <CR><LF> sur le Web - conversion indue vers le format Windows - ce qui donne <CR><CR><LF> - donc caractère bizzare (selon interprétation) + saut de ligne correct ... ou donc quelque chose de similaire.
Pour les utilisateurs de Windows que ça intéresse, je me suis doté il y a quelques temps de deux petits convertisseurs qui s'intègrent dans le menu "Envoyer Vers" de l'Explorateur. C'est assez pratique et je vous les donne gratuitement :-) http://cjoint.com/?jnvxyWA46z (lien valide 21 jours)
Attention, c'est pas protégé du tout : - si vous les faites passer sur du binaire, il sera converti aussi, - le format actuel du fichier n'est pas vérifié avant, - Je ne les ai pas vraiement testés sur un gros fichier de 1Go en une seule ligne : le buffer est une CString, vous risquez une exception dans ce cas :-D
Mais les deux sont tout de même symétriques.
En regardant le code, je vois que j'ai fait confiance à la fonction CStdioFile::ReadString() qui se débrouille bien avec les deux formes de saut de ligne...
Hope It Helps,
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Sergio <laposte@serge.delbono.net.invalid>
qui dans mn.6c4c7d592c039e00.9866@serge.delbono.net.invalid a écrit :
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 ? ;-)
J'ai eu des problèmes de ce genre aussi, assez récemment. Je soupçonne un
scénario foireux dans le genre:
- fichier initialement en <CR><LF> sur le Web
- conversion indue vers le format Windows
- ce qui donne <CR><CR><LF>
- donc caractère bizzare (selon interprétation) + saut de ligne correct
... ou donc quelque chose de similaire.
Pour les utilisateurs de Windows que ça intéresse, je me suis doté il y a
quelques temps de deux petits convertisseurs qui s'intègrent dans le menu
"Envoyer Vers" de l'Explorateur. C'est assez pratique et je vous les donne
gratuitement :-)
http://cjoint.com/?jnvxyWA46z (lien valide 21 jours)
Attention, c'est pas protégé du tout :
- si vous les faites passer sur du binaire, il sera converti aussi,
- le format actuel du fichier n'est pas vérifié avant,
- Je ne les ai pas vraiement testés sur un gros fichier de 1Go en une seule
ligne : le buffer est une CString, vous risquez une exception dans ce cas
:-D
Mais les deux sont tout de même symétriques.
En regardant le code, je vois que j'ai fait confiance à la fonction
CStdioFile::ReadString() qui se débrouille bien avec les deux formes de saut
de ligne...
Hope It Helps,
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
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 ? ;-)
J'ai eu des problèmes de ce genre aussi, assez récemment. Je soupçonne un scénario foireux dans le genre:
- fichier initialement en <CR><LF> sur le Web - conversion indue vers le format Windows - ce qui donne <CR><CR><LF> - donc caractère bizzare (selon interprétation) + saut de ligne correct ... ou donc quelque chose de similaire.
Pour les utilisateurs de Windows que ça intéresse, je me suis doté il y a quelques temps de deux petits convertisseurs qui s'intègrent dans le menu "Envoyer Vers" de l'Explorateur. C'est assez pratique et je vous les donne gratuitement :-) http://cjoint.com/?jnvxyWA46z (lien valide 21 jours)
Attention, c'est pas protégé du tout : - si vous les faites passer sur du binaire, il sera converti aussi, - le format actuel du fichier n'est pas vérifié avant, - Je ne les ai pas vraiement testés sur un gros fichier de 1Go en une seule ligne : le buffer est une CString, vous risquez une exception dans ce cas :-D
Mais les deux sont tout de même symétriques.
En regardant le code, je vois que j'ai fait confiance à la fonction CStdioFile::ReadString() qui se débrouille bien avec les deux formes de saut de ligne...
Hope It Helps,
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Sergio
Michel Giacomazzi vient de nous annoncer :
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)
J'utilise CONText pour ça. Pas de macros, mais le rechercher-remplacer multifichier.
Sinon, en ligne de commande, il existe GSAR, que tu peux mettre dans un batch.
CONText (éditeur de texte) : http://www.context.cx GSAR : http://gnuwin32.sourceforge.net/packages/gsar.htm
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Michel Giacomazzi vient de nous annoncer :
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)
J'utilise CONText pour ça. Pas de macros, mais le rechercher-remplacer
multifichier.
Sinon, en ligne de commande, il existe GSAR, que tu peux mettre dans un
batch.
CONText (éditeur de texte) : http://www.context.cx
GSAR : http://gnuwin32.sourceforge.net/packages/gsar.htm
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
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)
J'utilise CONText pour ça. Pas de macros, mais le rechercher-remplacer multifichier.
Sinon, en ligne de commande, il existe GSAR, que tu peux mettre dans un batch.
CONText (éditeur de texte) : http://www.context.cx GSAR : http://gnuwin32.sourceforge.net/packages/gsar.htm
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
claude et claudine
Dans son message précédent, Eric Rossé a écrit :
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
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
Même en mode texte, word reste un outil inadapté.
Ouf,...je confirme : (win)word est un compromis entre html et txt qui ne réalise bien ni le html, ni le txt. __ CB C&Claudine promise_cuitée
Dans son message précédent, Eric Rossé a écrit :
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
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
Même en mode texte, word reste un outil inadapté.
Ouf,...je confirme : (win)word est un compromis entre html et txt qui
ne réalise bien ni le html, ni le txt.
__
CB
C&Claudine promise_cuitée
Le Tue, 13 Sep 2005 19:32:12 +0200, Michel Giacomazzi écrivait:
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
Même en mode texte, word reste un outil inadapté.
Ouf,...je confirme : (win)word est un compromis entre html et txt qui ne réalise bien ni le html, ni le txt. __ CB C&Claudine promise_cuitée
