mais comment puis-je vérifier l'encodage dans ces conditions ?
si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le
changer...
j'imagine que cette URL passe par tout un tas de couches logicielles
(mac os x) avant d'être fournie à mon script ruby...
--
« La télévision n'exige du spectateur qu'un acte de courage,
mais il est surhumain, c'est de l'éteindre. »
(Pascal Bruckner)
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens longs avec un lien court de type tinyurl :
mais comment puis-je vérifier l'encodage dans ces conditions ?
si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le changer...
j'imagine que cette URL passe par tout un tas de couches logicielles (mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
Cordialement, -- Olivier Miakinen
Le 25/10/2010 07:17, Une Bévue a écrit :
je
Oui, bonjour aussi.
télécharge automatiquement le contenu de pages en utilisant leur URL
par le menu contexturel de FireFox 3 (latest) en faisant (Mac OS X) :
ctrl + click maintenu > Copier l'adresse du lien.
le lien obtenu de cette manière me sert à télécharger la page et je
rencontre un problème d'encodage car ruby me dit :
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce
serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens
longs avec un lien court de type tinyurl :
mais comment puis-je vérifier l'encodage dans ces conditions ?
si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le
changer...
j'imagine que cette URL passe par tout un tas de couches logicielles
(mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les
entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les
%NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de
l'UTF-8 (ce qui est le format recommandé), peut-être aussi
en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas
imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet
qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait
encodé %E2%80%99.
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens longs avec un lien court de type tinyurl :
mais comment puis-je vérifier l'encodage dans ces conditions ?
si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le changer...
j'imagine que cette URL passe par tout un tas de couches logicielles (mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
Cordialement, -- Olivier Miakinen
Olivier Miakinen
Le 25/10/2010 10:53, j'écrivais :
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8> Caveats * Setting this preference to true can cause incompatibilities in some websites. </cit.>
Le 25/10/2010 10:53, j'écrivais :
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les
%NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de
l'UTF-8 (ce qui est le format recommandé), peut-être aussi
en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas
imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet
qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait
encodé %E2%80%99.
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton
problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8>
Caveats
* Setting this preference to true can cause incompatibilities in
some websites.
</cit.>
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8> Caveats * Setting this preference to true can cause incompatibilities in some websites. </cit.>
unbewusst.sein
Olivier Miakinen <om+ wrote:
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens longs avec un lien court de type tinyurl : <http://tinyurl.com/2vrtbc9>
OK, il faudra que j'y pense )))
> elle marche "normalement" avec FF3 > > mais comment puis-je vérifier l'encodage dans ces conditions ? > > si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le > changer... > > j'imagine que cette URL passe par tout un tas de couches logicielles > (mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
bon, j'ai du mal m'exprimer.
je reçois tous les jours un email de "http://www.ptitchef.com" que je lis avec Google Mail / FireFox 3.
c'est sur cet email que j'utilise le menu contecturel pour copier l'adresse d'une image laquelle adresse renvoit à une recette que je télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à partir du charset détecté par "lynx" : /opt/local/bin/lynx -head -dump <l'URL en question>
MAIS, tu me fais découvrir que la tsring de l'URL doit aussi être décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas l'encodage...
je vais essayer avec une "vérue" supposant que pour ce site l'encodage est tjs en "ISO-8859-1".
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1" vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème. (lynx me donne bien "ISO-8859-1")
mais donc il ne viendrait peut-être pas de FF3 ???
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen <om+news@miakinen.net> wrote:
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce
serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens
longs avec un lien court de type tinyurl :
<http://tinyurl.com/2vrtbc9>
OK, il faudra que j'y pense )))
> elle marche "normalement" avec FF3
>
> mais comment puis-je vérifier l'encodage dans ces conditions ?
>
> si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le
> changer...
>
> j'imagine que cette URL passe par tout un tas de couches logicielles
> (mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les
entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les
%NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de
l'UTF-8 (ce qui est le format recommandé), peut-être aussi
en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas
imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet
qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait
encodé %E2%80%99.
bon, j'ai du mal m'exprimer.
je reçois tous les jours un email de "http://www.ptitchef.com" que je
lis avec Google Mail / FireFox 3.
c'est sur cet email que j'utilise le menu contecturel pour copier
l'adresse d'une image laquelle adresse renvoit à une recette que je
télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à
partir du charset détecté par "lynx" :
/opt/local/bin/lynx -head -dump <l'URL en question>
MAIS, tu me fais découvrir que la tsring de l'URL doit aussi être
décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas
l'encodage...
je vais essayer avec une "vérue" supposant que pour ce site l'encodage
est tjs en "ISO-8859-1".
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1"
vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème.
(lynx me donne bien "ISO-8859-1")
mais donc il ne viendrait peut-être pas de FF3 ???
--
« La télévision n'exige du spectateur qu'un acte de courage,
mais il est surhumain, c'est de l'éteindre. »
(Pascal Bruckner)
MacSOUP coupant sans vergogne les liens qu'il considère trop longs, ce serait bien d'accompagner (je n'ai pas dit « de remplacer ») ces liens longs avec un lien court de type tinyurl : <http://tinyurl.com/2vrtbc9>
OK, il faudra que j'y pense )))
> elle marche "normalement" avec FF3 > > mais comment puis-je vérifier l'encodage dans ces conditions ? > > si ce n'est pas de l'UTF-8 il faut que je connaisse l'encodage pour le > changer... > > j'imagine que cette URL passe par tout un tas de couches logicielles > (mac os x) avant d'être fournie à mon script ruby...
La page elle-même est en ISO-8859-1, correctement annoncé dans les entêtes HTTP. Rien à redire dessus.
À mon avis, le problème vient de ce que Firefox essaye d'interpréter les %NN de l'URL, et qu'il essaye certainement de les voir d'abord comme de l'UTF-8 (ce qui est le format recommandé), peut-être aussi en ISO-8859-1 (ce qui est encore assez fréquent), mais qu'il n'ose pas imaginer que cela puisse être du Windows CP1252. Or %92 donne un octet qui est invalide aussi bien en UTF-8 qu'en Latin1 ; en UTF-8, il serait encodé %E2%80%99.
bon, j'ai du mal m'exprimer.
je reçois tous les jours un email de "http://www.ptitchef.com" que je lis avec Google Mail / FireFox 3.
c'est sur cet email que j'utilise le menu contecturel pour copier l'adresse d'une image laquelle adresse renvoit à une recette que je télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à partir du charset détecté par "lynx" : /opt/local/bin/lynx -head -dump <l'URL en question>
MAIS, tu me fais découvrir que la tsring de l'URL doit aussi être décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas l'encodage...
je vais essayer avec une "vérue" supposant que pour ce site l'encodage est tjs en "ISO-8859-1".
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1" vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème. (lynx me donne bien "ISO-8859-1")
mais donc il ne viendrait peut-être pas de FF3 ???
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
unbewusst.sein
Olivier Miakinen <om+ wrote:
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8> Caveats * Setting this preference to true can cause incompatibilities in some websites. </cit.>
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen <om+news@miakinen.net> wrote:
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton
problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8>
Caveats
* Setting this preference to true can cause incompatibilities in
some websites.
</cit.>
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
--
« La télévision n'exige du spectateur qu'un acte de courage,
mais il est surhumain, c'est de l'éteindre. »
(Pascal Bruckner)
Tiens, je parie que mettre ce paramètre à false devrait résoudre ton problème :
<cit. http://kb.mozillazine.org/Network.standard-url.encode-utf8> Caveats * Setting this preference to true can cause incompatibilities in some websites. </cit.>
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen
Le 25/10/2010 11:39, Une Bévue a écrit :
bon, j'ai du mal m'exprimer.
je reçois tous les jours un email de "http://www.ptitchef.com" que je lis avec Google Mail / FireFox 3.
Effectivement, je n'avais pas compris ça. D'autant que je n'aime pas beaucoup les webmails et que je ne connais pas celui de Google.
c'est sur cet email que j'utilise le menu contextuel pour copier l'adresse d'une image laquelle adresse renvoit à une recette que je télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à partir du charset détecté par "lynx" : /opt/local/bin/lynx -head -dump <l'URL en question>
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les caractères correspondants ?
MAIS, tu me fais découvrir que la string de l'URL doit aussi être décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but est de créer sur ton disque un fichier portant ce nom (et encore... conserver le %NN est peut-être moins beau, mais c'est plus sûr).
je vais essayer avec une "verrue" supposant que pour ce site l'encodage est tjs en "ISO-8859-1".
En l'occurrence, ce serait plutôt Windows-1252 pour ce qui concerne l'URL (bien que le contenu soit, lui, en ISO-8859-1).
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1" vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème. (lynx me donne bien "ISO-8859-1")
Essaye "CP1252" ou "Win1252" ou "Windows1252" ou "Windows-1252" ou...
mais donc il ne viendrait peut-être pas de FF3 ???
Peut-être pas en effet.
Le 25/10/2010 11:39, Une Bévue a écrit :
bon, j'ai du mal m'exprimer.
je reçois tous les jours un email de "http://www.ptitchef.com" que je
lis avec Google Mail / FireFox 3.
Effectivement, je n'avais pas compris ça. D'autant que je n'aime pas
beaucoup les webmails et que je ne connais pas celui de Google.
c'est sur cet email que j'utilise le menu contextuel pour copier
l'adresse d'une image laquelle adresse renvoit à une recette que je
télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à
partir du charset détecté par "lynx" :
/opt/local/bin/lynx -head -dump <l'URL en question>
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle
quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les
caractères correspondants ?
MAIS, tu me fais découvrir que la string de l'URL doit aussi être
décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas
l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but
est de créer sur ton disque un fichier portant ce nom (et encore...
conserver le %NN est peut-être moins beau, mais c'est plus sûr).
je vais essayer avec une "verrue" supposant que pour ce site l'encodage
est tjs en "ISO-8859-1".
En l'occurrence, ce serait plutôt Windows-1252 pour ce qui concerne
l'URL (bien que le contenu soit, lui, en ISO-8859-1).
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1"
vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème.
(lynx me donne bien "ISO-8859-1")
Essaye "CP1252" ou "Win1252" ou "Windows1252" ou "Windows-1252" ou...
mais donc il ne viendrait peut-être pas de FF3 ???
je reçois tous les jours un email de "http://www.ptitchef.com" que je lis avec Google Mail / FireFox 3.
Effectivement, je n'avais pas compris ça. D'autant que je n'aime pas beaucoup les webmails et que je ne connais pas celui de Google.
c'est sur cet email que j'utilise le menu contextuel pour copier l'adresse d'une image laquelle adresse renvoit à une recette que je télécharge à travers un script qui bien sûr ré-encode le html en UTF-8 à partir du charset détecté par "lynx" : /opt/local/bin/lynx -head -dump <l'URL en question>
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les caractères correspondants ?
MAIS, tu me fais découvrir que la string de l'URL doit aussi être décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but est de créer sur ton disque un fichier portant ce nom (et encore... conserver le %NN est peut-être moins beau, mais c'est plus sûr).
je vais essayer avec une "verrue" supposant que pour ce site l'encodage est tjs en "ISO-8859-1".
En l'occurrence, ce serait plutôt Windows-1252 pour ce qui concerne l'URL (bien que le contenu soit, lui, en ISO-8859-1).
je viens juste de faire l'essai en forçant une conversion "ISO-8859-1" vers "UTF-8" pour l'URL copiée, j'ai toujours le même problème. (lynx me donne bien "ISO-8859-1")
Essaye "CP1252" ou "Win1252" ou "Windows1252" ou "Windows-1252" ou...
mais donc il ne viendrait peut-être pas de FF3 ???
Peut-être pas en effet.
Olivier Miakinen
Le 25/10/2010 11:39, Une Bévue a écrit :
[Network.standard-url.encode-utf8]
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
Ok, le problème doit être ailleurs, peut-être dans le script faisant appel à lynx.
Le 25/10/2010 11:39, Une Bévue a écrit :
[Network.standard-url.encode-utf8]
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
Ok, le problème doit être ailleurs, peut-être dans le script faisant
appel à lynx.
j'ai essayé (par about:config) ça ne change rien au pb rencontré...
Ok, le problème doit être ailleurs, peut-être dans le script faisant appel à lynx.
unbewusst.sein
Olivier Miakinen <om+ wrote:
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les caractères correspondants ?
OUI, oui !
> MAIS, tu me fais découvrir que la string de l'URL doit aussi être > décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas > l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but est de créer sur ton disque un fichier portant ce nom (et encore... conserver le %NN est peut-être moins beau, mais c'est plus sûr).
effectivement ça marche très bien aussi sans faire de "unescape"...
> mais donc il ne viendrait peut-être pas de FF3 ???
Peut-être pas en effet.
je suis quasiment sûr ce ça vient d'une lib ruby URI#unescape car en la shutant c'est tout bon aussi bien avec :
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen <om+news@miakinen.net> wrote:
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle
quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les
caractères correspondants ?
OUI, oui !
> MAIS, tu me fais découvrir que la string de l'URL doit aussi être
> décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas
> l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but
est de créer sur ton disque un fichier portant ce nom (et encore...
conserver le %NN est peut-être moins beau, mais c'est plus sûr).
effectivement ça marche très bien aussi sans faire de "unescape"...
> mais donc il ne viendrait peut-être pas de FF3 ???
Peut-être pas en effet.
je suis quasiment sûr ce ça vient d'une lib ruby URI#unescape car en la
shutant c'est tout bon aussi bien avec :
C'est cette URL qui contient le %92 ? Est-ce qu'elle est transmise telle quelle, ou bien est-ce que Firefox essaye de remplacer les %NN par les caractères correspondants ?
OUI, oui !
> MAIS, tu me fais découvrir que la string de l'URL doit aussi être > décodée, c'est génant car, recevant cet URL par un mail, je n'ai pas > l'encodage...
Justement non, il ne faudrait pas la décoder, sauf bien sûr si le but est de créer sur ton disque un fichier portant ce nom (et encore... conserver le %NN est peut-être moins beau, mais c'est plus sûr).
effectivement ça marche très bien aussi sans faire de "unescape"...
> mais donc il ne viendrait peut-être pas de FF3 ???
Peut-être pas en effet.
je suis quasiment sûr ce ça vient d'une lib ruby URI#unescape car en la shutant c'est tout bon aussi bien avec :
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
unbewusst.sein
Olivier Miakinen <om+ wrote:
Ok, le problème doit être ailleurs, peut-être dans le script faisant appel à lynx.
ben la fonction utilisant lynx dans mon script est OK, c'est ailleurs. c'est curieux car j'utilise ce script tous les matins et c'est la première fois que ce genre de problème arrive.
la partie de string/URL mise en cause, amha, est le "%92" qui encode l'apostrophe "'".
alors que le titre de la page est "Verrine de saumon au pesto de fenouil et d'ail"
j'ai mis une vérue dans mon script car apparemment c'est la fonction URI.unescape qui transforme ce "%92" en "?" :
donc si je remplace ce "%92" en "'" ça roule !!! avec :
def basename r=File.basename(self.path) return r unless r =~ /%/ return r.gsub(/%92/,''') if r =~ /%92/ return URI.unescape(r) end
mais je ne comprends pas pourquoi URI.unescape déconne ???
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen <om+news@miakinen.net> wrote:
Ok, le problème doit être ailleurs, peut-être dans le script faisant
appel à lynx.
ben la fonction utilisant lynx dans mon script est OK, c'est ailleurs.
c'est curieux car j'utilise ce script tous les matins et c'est la
première fois que ce genre de problème arrive.
la partie de string/URL mise en cause, amha, est le "%92" qui encode
l'apostrophe "'".
Ok, le problème doit être ailleurs, peut-être dans le script faisant appel à lynx.
ben la fonction utilisant lynx dans mon script est OK, c'est ailleurs. c'est curieux car j'utilise ce script tous les matins et c'est la première fois que ce genre de problème arrive.
la partie de string/URL mise en cause, amha, est le "%92" qui encode l'apostrophe "'".
-- « La télévision n'exige du spectateur qu'un acte de courage, mais il est surhumain, c'est de l'éteindre. » (Pascal Bruckner)
Olivier Miakinen
[réponse en UTF-8]
Le 25/10/2010 13:46, Une Bévue a écrit :
la partie de string/URL mise en cause, amha, est le "%92" qui encode l'apostrophe "'".
Non, pas la simple quote « ' » mais l'apostrophe « ’ ». Je te les mets côte à côte (ou quote à quote !) pour que tu voies la différence : '’'’'’ ’'’'’'
Normal. L'apostrophe ’ n'existe pas dans ISO-8859-1 (pas plus qu'elle n'existe dans ISO-8859-15, ce qui me force à te répondre en UTF-8 pour l'afficher).
alors que le titre de la page est "Verrine de saumon au pesto de fenouil et d'ail"
Non, le titre est « Verrine de saumon au pesto de fenouil et d’ail ». C'est une vraie apostrophe typographique et pas une patte de mouche ASCII.
j'ai mis une vérue dans mon script car apparemment c'est la fonction URI.unescape qui transforme ce "%92" en "?" :
Oui, avec raison.
donc si je remplace ce "%92" en "'" ça roule !!! avec :
Normal.
mais je ne comprends pas pourquoi URI.unescape déconne ???
Cf. ci-dessus.
Voir aussi : http://www.miakinen.net/vrac/charsets/?or=4&pr6 (’ dans CP1252) http://www.miakinen.net/vrac/charsets/?or=4&pr9 (' dans CP1252) http://www.miakinen.net/vrac/charsets/?or=1&pr9 (' dans ASCII)
[réponse en UTF-8]
Le 25/10/2010 13:46, Une Bévue a écrit :
la partie de string/URL mise en cause, amha, est le "%92" qui encode
l'apostrophe "'".
Non, pas la simple quote « ' » mais l'apostrophe « ’ ». Je te les mets
côte à côte (ou quote à quote !) pour que tu voies la différence :
'’'’'’
’'’'’'
Normal. L'apostrophe ’ n'existe pas dans ISO-8859-1 (pas plus qu'elle
n'existe dans ISO-8859-15, ce qui me force à te répondre en UTF-8 pour
l'afficher).
alors que le titre de la page est "Verrine de saumon au pesto de fenouil
et d'ail"
Non, le titre est « Verrine de saumon au pesto de fenouil et d’ail ».
C'est une vraie apostrophe typographique et pas une patte de mouche ASCII.
j'ai mis une vérue dans mon script car apparemment c'est la fonction
URI.unescape qui transforme ce "%92" en "?" :
Oui, avec raison.
donc si je remplace ce "%92" en "'" ça roule !!! avec :
Normal.
mais je ne comprends pas pourquoi URI.unescape déconne ???
Cf. ci-dessus.
Voir aussi :
http://www.miakinen.net/vrac/charsets/?or=4&pr6 (’ dans CP1252)
http://www.miakinen.net/vrac/charsets/?or=4&pr9 (' dans CP1252)
http://www.miakinen.net/vrac/charsets/?or=1&pr9 (' dans ASCII)
la partie de string/URL mise en cause, amha, est le "%92" qui encode l'apostrophe "'".
Non, pas la simple quote « ' » mais l'apostrophe « ’ ». Je te les mets côte à côte (ou quote à quote !) pour que tu voies la différence : '’'’'’ ’'’'’'
Normal. L'apostrophe ’ n'existe pas dans ISO-8859-1 (pas plus qu'elle n'existe dans ISO-8859-15, ce qui me force à te répondre en UTF-8 pour l'afficher).
alors que le titre de la page est "Verrine de saumon au pesto de fenouil et d'ail"
Non, le titre est « Verrine de saumon au pesto de fenouil et d’ail ». C'est une vraie apostrophe typographique et pas une patte de mouche ASCII.
j'ai mis une vérue dans mon script car apparemment c'est la fonction URI.unescape qui transforme ce "%92" en "?" :
Oui, avec raison.
donc si je remplace ce "%92" en "'" ça roule !!! avec :
Normal.
mais je ne comprends pas pourquoi URI.unescape déconne ???
Cf. ci-dessus.
Voir aussi : http://www.miakinen.net/vrac/charsets/?or=4&pr6 (’ dans CP1252) http://www.miakinen.net/vrac/charsets/?or=4&pr9 (' dans CP1252) http://www.miakinen.net/vrac/charsets/?or=1&pr9 (' dans ASCII)
