On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote:
Le Thu, 08 Oct 2015 21:37:36 +0200, Francois Meyer a écrit :
> Le 08/10/2015 16:45, Bernard Schoenacker a écrit : > > bonjour, > > > > j'ai essayé avec sed : sed "s/xc2x92/'/g" > > > > sans résultat > > > > slt > > bernard > > > > > Les commandes proposées telles que > sed "s/<92>/'/g" > remplacent le mot ou la chaîne de caractère "<92>" par l'apostrophe. > Mais s'il s'agit d'un seul caractère, il faudrait en savoir un peu > plus, car <92> est alors sa représentation codée > dans un autre codage... > > François >
bonjour,
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( ) […] je sent que iconv sera de la partie ....
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… l'étau se ressert !). Auquel cas, éventuellement, un $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt … pour redresser la situation ?
On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote:
Le Thu, 08 Oct 2015 21:37:36 +0200,
Francois Meyer <francois-jean.meyer@ac-versailles.fr> a écrit :
> Le 08/10/2015 16:45, Bernard Schoenacker a écrit :
> > bonjour,
> >
> > j'ai essayé avec sed : sed "s/xc2x92/'/g"
> >
> > sans résultat
> >
> > slt
> > bernard
> >
> >
> Les commandes proposées telles que
> sed "s/<92>/'/g"
> remplacent le mot ou la chaîne de caractère "<92>" par l'apostrophe.
> Mais s'il s'agit d'un seul caractère, il faudrait en savoir un peu
> plus, car <92> est alors sa représentation codée
> dans un autre codage...
>
> François
>
bonjour,
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et
boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( )
[…]
je sent que iconv sera de la partie ....
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le
guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal…
l'étau se ressert !). Auquel cas, éventuellement, un
$ iconv -f WINDOWS-1252 -t UTF-8 filename.txt
… pour redresser la situation ?
On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote:
Le Thu, 08 Oct 2015 21:37:36 +0200, Francois Meyer a écrit :
> Le 08/10/2015 16:45, Bernard Schoenacker a écrit : > > bonjour, > > > > j'ai essayé avec sed : sed "s/xc2x92/'/g" > > > > sans résultat > > > > slt > > bernard > > > > > Les commandes proposées telles que > sed "s/<92>/'/g" > remplacent le mot ou la chaîne de caractère "<92>" par l'apostrophe. > Mais s'il s'agit d'un seul caractère, il faudrait en savoir un peu > plus, car <92> est alors sa représentation codée > dans un autre codage... > > François >
bonjour,
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( ) […] je sent que iconv sera de la partie ....
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… l'étau se ressert !). Auquel cas, éventuellement, un $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt … pour redresser la situation ?
Le Thu, 8 Oct 2015 23:49:13 +0200, Alexandre Hoïde a écrit :
On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote: > Le Thu, 08 Oct 2015 21:37:36 +0200, > Francois Meyer a écrit : > > > Le 08/10/2015 16:45, Bernard Schoenacker a écrit : > > > bonjour, > > > > > > j'ai essayé avec sed : sed "s/xc2x92/'/g" > > > > > > sans résultat > > > > > > slt > > > bernard > > > > > > > > Les commandes proposées telles que > > sed "s/<92>/'/g" > > remplacent le mot ou la chaîne de caractère "<92>" par > > l'apostrophe. Mais s'il s'agit d'un seul caractère, il faudrait > > en savoir un peu plus, car <92> est alors sa représentation codée > > dans un autre codage... > > > > François > > > > bonjour, > > le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et > boulle de gomme) et c'est la sortie avec vim ... > > tandis que avec emacs c'est "222" ( ) > […] > je sent que iconv sera de la partie .... >
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… l'étau se ressert !). Auquel cas, éventuellement, un $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt … pour redresser la situation ?
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est rentré dans l'ordre ....
Le Thu, 8 Oct 2015 23:49:13 +0200,
Alexandre Hoïde <alexandre.hoide@gmail.com> a écrit :
On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote:
> Le Thu, 08 Oct 2015 21:37:36 +0200,
> Francois Meyer <francois-jean.meyer@ac-versailles.fr> a écrit :
>
> > Le 08/10/2015 16:45, Bernard Schoenacker a écrit :
> > > bonjour,
> > >
> > > j'ai essayé avec sed : sed "s/xc2x92/'/g"
> > >
> > > sans résultat
> > >
> > > slt
> > > bernard
> > >
> > >
> > Les commandes proposées telles que
> > sed "s/<92>/'/g"
> > remplacent le mot ou la chaîne de caractère "<92>" par
> > l'apostrophe. Mais s'il s'agit d'un seul caractère, il faudrait
> > en savoir un peu plus, car <92> est alors sa représentation codée
> > dans un autre codage...
> >
> > François
> >
>
> bonjour,
>
> le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et
> boulle de gomme) et c'est la sortie avec vim ...
>
> tandis que avec emacs c'est "222" ( )
> […]
> je sent que iconv sera de la partie ....
>
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le
guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal…
l'étau se ressert !). Auquel cas, éventuellement, un
$ iconv -f WINDOWS-1252 -t UTF-8 filename.txt
… pour redresser la situation ?
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est
rentré dans l'ordre ....
Le Thu, 8 Oct 2015 23:49:13 +0200, Alexandre Hoïde a écrit :
On Thu, Oct 08, 2015 at 11:30:56PM +0200, Bernard Schoenacker wrote: > Le Thu, 08 Oct 2015 21:37:36 +0200, > Francois Meyer a écrit : > > > Le 08/10/2015 16:45, Bernard Schoenacker a écrit : > > > bonjour, > > > > > > j'ai essayé avec sed : sed "s/xc2x92/'/g" > > > > > > sans résultat > > > > > > slt > > > bernard > > > > > > > > Les commandes proposées telles que > > sed "s/<92>/'/g" > > remplacent le mot ou la chaîne de caractère "<92>" par > > l'apostrophe. Mais s'il s'agit d'un seul caractère, il faudrait > > en savoir un peu plus, car <92> est alors sa représentation codée > > dans un autre codage... > > > > François > > > > bonjour, > > le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et > boulle de gomme) et c'est la sortie avec vim ... > > tandis que avec emacs c'est "222" ( ) > […] > je sent que iconv sera de la partie .... >
Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… l'étau se ressert !). Auquel cas, éventuellement, un $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt … pour redresser la situation ?
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est rentré dans l'ordre ....
On Fri, Oct 09, 2015 at 12:06:22AM +0200, Bernard Schoenacker wrote:
Le Thu, 8 Oct 2015 23:49:13 +0200, Alexandre Hoïde a écrit : > Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le > guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… > l'étau se ressert !). Auquel cas, éventuellement, un > $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt > … pour redresser la situation ? >
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est rentré dans l'ordre ....
On Fri, Oct 09, 2015 at 12:06:22AM +0200, Bernard Schoenacker wrote:
Le Thu, 8 Oct 2015 23:49:13 +0200,
Alexandre Hoïde <alexandre.hoide@gmail.com> a écrit :
> Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le
> guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal…
> l'étau se ressert !). Auquel cas, éventuellement, un
> $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt
> … pour redresser la situation ?
>
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est
rentré dans l'ordre ....
On Fri, Oct 09, 2015 at 12:06:22AM +0200, Bernard Schoenacker wrote:
Le Thu, 8 Oct 2015 23:49:13 +0200, Alexandre Hoïde a écrit : > Ça serait-y pas du Windows-1252, par hasard ? U+2019 est le > guillemet-apostrophe (x92 en W-1252 = 146 en décimal et 222 en octal… > l'étau se ressert !). Auquel cas, éventuellement, un > $ iconv -f WINDOWS-1252 -t UTF-8 filename.txt > … pour redresser la situation ? >
bonjour,
merci du tuyau mais je l'ai employé avant de répondre et tout est rentré dans l'ordre ....
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( )
voici un extrait en pièce jointe ...
Personnellement, sur ma machine, la commande « file » me dit que ton fichier est en UTF-8 et je comprends que le caractère qui pose problème est le caractère dont le code point unicode est U+0092 (attention, le code point ce n'est pas la même chose que l'encodage numérique).
~$ file /tmp/out.txt /tmp/out.txt: UTF-8 Unicode text, with very long lines
En fait, il suffit a priori de saisir le caractère dans sed et un simple :
sed "s/<LE-CARACTÈRE>/'/g" le-fichier.txt
devrait marcher, exactement comme si on voulait remplacer les « a » par des « ' » sauf qu'ici ce n'est pas un « a » mais un caractère un peu étrange.
Une première méthode que j'ai pu tester est de générer le caractère avec Perl (a priori déjà installé sur ta Debian à 99,99%) :
char=$(perl -C -wE 'say "x{0092}"') sed -i "s/$char/'/g" le-fichier.txt
Une autre façon de faire est de taper le caractère directement dans le terminal (là je sais pas si ça marchera partout) en tapant sur le clavier (alors qu'on est dans un terminal) « shift + u + le-code-point-du-caractère ». Donc si je tape les caractères suivants :
=> « sed -i "s/ » => puis « shift + u + 0092 » => puis « /'/g" le-fichier.txt » => puis Entrée
alors la commande fonctionne chez moi.
Bref, les 2 méthodes ont fonctionné sur ma Debian Wheezy avec ton fichier en pièce jointe (md5sum => 83070902dea2600878d40602c396c0d4) sur mon terminal qui est Terminator en l'occurrence.
Voilà, j'espère qu'au moins une des deux méthodes marchera chez toi.
-- François Lafont
Bonsoir,
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et
boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( )
voici un extrait en pièce jointe ...
Personnellement, sur ma machine, la commande « file » me dit que ton
fichier est en UTF-8 et je comprends que le caractère qui pose problème
est le caractère dont le code point unicode est U+0092 (attention, le
code point ce n'est pas la même chose que l'encodage numérique).
~$ file /tmp/out.txt
/tmp/out.txt: UTF-8 Unicode text, with very long lines
En fait, il suffit a priori de saisir le caractère dans sed et un simple :
sed "s/<LE-CARACTÈRE>/'/g" le-fichier.txt
devrait marcher, exactement comme si on voulait remplacer les « a » par
des « ' » sauf qu'ici ce n'est pas un « a » mais un caractère un peu
étrange.
Une première méthode que j'ai pu tester est de générer le caractère avec
Perl (a priori déjà installé sur ta Debian à 99,99%) :
char=$(perl -C -wE 'say "x{0092}"')
sed -i "s/$char/'/g" le-fichier.txt
Une autre façon de faire est de taper le caractère directement dans le
terminal (là je sais pas si ça marchera partout) en tapant sur le clavier
(alors qu'on est dans un terminal) « shift + u + le-code-point-du-caractère ».
Donc si je tape les caractères suivants :
=> « sed -i "s/ »
=> puis « shift + u + 0092 »
=> puis « /'/g" le-fichier.txt »
=> puis Entrée
alors la commande fonctionne chez moi.
Bref, les 2 méthodes ont fonctionné sur ma Debian Wheezy avec ton
fichier en pièce jointe (md5sum => 83070902dea2600878d40602c396c0d4)
sur mon terminal qui est Terminator en l'occurrence.
Voilà, j'espère qu'au moins une des deux méthodes marchera chez toi.
le n° "<92>" est l'apostrophe mais de quel encodage ? (mystère et boulle de gomme) et c'est la sortie avec vim ...
tandis que avec emacs c'est "222" ( )
voici un extrait en pièce jointe ...
Personnellement, sur ma machine, la commande « file » me dit que ton fichier est en UTF-8 et je comprends que le caractère qui pose problème est le caractère dont le code point unicode est U+0092 (attention, le code point ce n'est pas la même chose que l'encodage numérique).
~$ file /tmp/out.txt /tmp/out.txt: UTF-8 Unicode text, with very long lines
En fait, il suffit a priori de saisir le caractère dans sed et un simple :
sed "s/<LE-CARACTÈRE>/'/g" le-fichier.txt
devrait marcher, exactement comme si on voulait remplacer les « a » par des « ' » sauf qu'ici ce n'est pas un « a » mais un caractère un peu étrange.
Une première méthode que j'ai pu tester est de générer le caractère avec Perl (a priori déjà installé sur ta Debian à 99,99%) :
char=$(perl -C -wE 'say "x{0092}"') sed -i "s/$char/'/g" le-fichier.txt
Une autre façon de faire est de taper le caractère directement dans le terminal (là je sais pas si ça marchera partout) en tapant sur le clavier (alors qu'on est dans un terminal) « shift + u + le-code-point-du-caractère ». Donc si je tape les caractères suivants :
=> « sed -i "s/ » => puis « shift + u + 0092 » => puis « /'/g" le-fichier.txt » => puis Entrée
alors la commande fonctionne chez moi.
Bref, les 2 méthodes ont fonctionné sur ma Debian Wheezy avec ton fichier en pièce jointe (md5sum => 83070902dea2600878d40602c396c0d4) sur mon terminal qui est Terminator en l'occurrence.
Voilà, j'espère qu'au moins une des deux méthodes marchera chez toi.
-- François Lafont
andre_debian
Je me permets de rebondir par une question très proche :
