mon fichier php a le header :
header("Content-Type: text/html;charset=utf-8");
et mon butineur (Google Chrome 16 et Firefox 10) voient bien ce fichier
comme étant en UTF-8
la doc d'utf8_decode() dit qu'utf8_decode() décode la chaîne data, en
supposant qu'elle est au format UTF-8, et la convertit au format ISO-8859-1.
donc le flux parsé par yaml_parse_file('../setup.yaml')
est mal décodé ??? je ne comprends pas pourquoi utf8_decode me donne de
l'UTF-8, ce que j'espérais obtenir dès le départ...
sur la doc :
<http://www.php.net/manual/fr/function.yaml-emit-file.php>
il y a bien une option, à l'écriture correspondant à l'encodage.
mais sur la doc de yaml_parse_file :
<http://www.php.net/manual/fr/function.yaml-parse-file.php>
il n'y est pas fait mention d'une option spécifiant l'encodage...
je suis sous :
.-(~)--------------------------------------------------------(yt@D620)-
`--> uname -a
Linux D620 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
le php utilisé :
PHP Version 5.3.6-13ubuntu3.6
les infos concernant yaml :LibYAML Support enabled
Module Version 1.0.1
LibYAML Version 0.1.4
Directive Local Value Master Value
yaml.decode_binary 0 0
yaml.decode_timestamp 0 0
yaml.output_canonical 0 0
yaml.output_indent 2 2
yaml.output_width 80 80
dans le fichier setup.yml d'origine, M"dical est codé ainsi :
M\xC3\xA9dical
Le contenu du fichier setup.yaml ne serait-il pas « doublement encodé » en UTF-8 ? Le caractère « é », par exemple, qui se code en principe en deux octets C3 et A9, ne serait-il pas codé par quatre octets C3, 83, C2 et A9 ?
mon fichier php a le header : header("Content-Type: text/html;charset=utf-8"); et mon butineur (Google Chrome 16 et Firefox 10) voient bien ce fichier comme étant en UTF-8
Merci d'avoir ainsi écarté l'autre hypothèse qui serait un mauvais Content-Type.
la doc d'utf8_decode() dit qu'utf8_decode() décode la chaîne data, en supposant qu'elle est au format UTF-8, et la convertit au format ISO-8859-1.
donc le flux parsé par yaml_parse_file('../setup.yaml') est mal décodé ??? je ne comprends pas pourquoi utf8_decode me donne de l'UTF-8, ce que j'espérais obtenir dès le départ...
sur la doc : <http://www.php.net/manual/fr/function.yaml-emit-file.php> il y a bien une option, à l'écriture correspondant à l'encodage. mais sur la doc de yaml_parse_file : <http://www.php.net/manual/fr/function.yaml-parse-file.php> il n'y est pas fait mention d'une option spécifiant l'encodage...
La doc est assez sommaire, du coup je n'arrive pas à deviner ce que sont censés faire les différents choix d'encodage.
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
dans le fichier setup.yml d'origine, M"dical
Médical je suppose.
est codé ainsi : MxC3xA9dical
Ah. Et xC3 est censé représenter un octet ou un caractère ? Est-ce que ça ne fonctionnerait pas mieux en écrivant « Médical » plutôt que « MxC3xA9dical » ? Tu as une doc de la syntaxe de ce setup.yml ou setup.yaml (tu parles des deux) ?
Soit dit en passant, si le setup.yml est la même chose que le setup.yaml dont tu parlais au début, et s'il est donc « encodé en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi s'embêter avec des xNN illisibles au lieu de mettre les vrais caractères ! En effet, je ne connaissais pas YAML, mais une recherche Google m'indique que la syntaxe YAML a été conçue spécifiquement pour être facilement lisible par les gens plutôt que par les machines.
Cordialement, -- Olivier Miakinen
Bonjour,
Le 16/02/2012 15:19, Une Bévue a écrit :
je lis un fichier "setup.yaml" écrit par ruby, il est encodé en UTF-8 NO
BOM.
pour lire son contenu, depuis PHP, je fais :
$setup=yaml_parse_file('../setup.yaml');
[...]
foreach ($parameters_a as $key => $value) {
echo "$key => $value<br />";
foreach ($value as $cle => $valeur){
echo "$cle => $valeur<br />";
echo utf8_decode ($cle) . " => " . utf8_decode ($valeur) . "<br />";
}
echo "<br />";
}
echo "<br /><br />";
Le contenu du fichier setup.yaml ne serait-il pas « doublement encodé »
en UTF-8 ? Le caractère « é », par exemple, qui se code en principe en
deux octets C3 et A9, ne serait-il pas codé par quatre octets C3, 83,
C2 et A9 ?
mon fichier php a le header :
header("Content-Type: text/html;charset=utf-8");
et mon butineur (Google Chrome 16 et Firefox 10) voient bien ce fichier
comme étant en UTF-8
Merci d'avoir ainsi écarté l'autre hypothèse qui serait un mauvais
Content-Type.
la doc d'utf8_decode() dit qu'utf8_decode() décode la chaîne data, en
supposant qu'elle est au format UTF-8, et la convertit au format ISO-8859-1.
donc le flux parsé par yaml_parse_file('../setup.yaml')
est mal décodé ??? je ne comprends pas pourquoi utf8_decode me donne de
l'UTF-8, ce que j'espérais obtenir dès le départ...
sur la doc :
<http://www.php.net/manual/fr/function.yaml-emit-file.php>
il y a bien une option, à l'écriture correspondant à l'encodage.
mais sur la doc de yaml_parse_file :
<http://www.php.net/manual/fr/function.yaml-parse-file.php>
il n'y est pas fait mention d'une option spécifiant l'encodage...
La doc est assez sommaire, du coup je n'arrive pas à deviner ce que sont
censés faire les différents choix d'encodage.
Directive Local Value Master Value
yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
dans le fichier setup.yml d'origine, M"dical
Médical je suppose.
est codé ainsi :
MxC3xA9dical
Ah. Et xC3 est censé représenter un octet ou un caractère ?
Est-ce que ça ne fonctionnerait pas mieux en écrivant « Médical »
plutôt que « MxC3xA9dical » ? Tu as une doc de la syntaxe de
ce setup.yml ou setup.yaml (tu parles des deux) ?
Soit dit en passant, si le setup.yml est la même chose que le
setup.yaml dont tu parlais au début, et s'il est donc « encodé
en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi
s'embêter avec des xNN illisibles au lieu de mettre les vrais
caractères ! En effet, je ne connaissais pas YAML, mais une
recherche Google m'indique que la syntaxe YAML a été conçue
spécifiquement pour être facilement lisible par les gens
plutôt que par les machines.
Le contenu du fichier setup.yaml ne serait-il pas « doublement encodé » en UTF-8 ? Le caractère « é », par exemple, qui se code en principe en deux octets C3 et A9, ne serait-il pas codé par quatre octets C3, 83, C2 et A9 ?
mon fichier php a le header : header("Content-Type: text/html;charset=utf-8"); et mon butineur (Google Chrome 16 et Firefox 10) voient bien ce fichier comme étant en UTF-8
Merci d'avoir ainsi écarté l'autre hypothèse qui serait un mauvais Content-Type.
la doc d'utf8_decode() dit qu'utf8_decode() décode la chaîne data, en supposant qu'elle est au format UTF-8, et la convertit au format ISO-8859-1.
donc le flux parsé par yaml_parse_file('../setup.yaml') est mal décodé ??? je ne comprends pas pourquoi utf8_decode me donne de l'UTF-8, ce que j'espérais obtenir dès le départ...
sur la doc : <http://www.php.net/manual/fr/function.yaml-emit-file.php> il y a bien une option, à l'écriture correspondant à l'encodage. mais sur la doc de yaml_parse_file : <http://www.php.net/manual/fr/function.yaml-parse-file.php> il n'y est pas fait mention d'une option spécifiant l'encodage...
La doc est assez sommaire, du coup je n'arrive pas à deviner ce que sont censés faire les différents choix d'encodage.
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
dans le fichier setup.yml d'origine, M"dical
Médical je suppose.
est codé ainsi : MxC3xA9dical
Ah. Et xC3 est censé représenter un octet ou un caractère ? Est-ce que ça ne fonctionnerait pas mieux en écrivant « Médical » plutôt que « MxC3xA9dical » ? Tu as une doc de la syntaxe de ce setup.yml ou setup.yaml (tu parles des deux) ?
Soit dit en passant, si le setup.yml est la même chose que le setup.yaml dont tu parlais au début, et s'il est donc « encodé en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi s'embêter avec des xNN illisibles au lieu de mettre les vrais caractères ! En effet, je ne connaissais pas YAML, mais une recherche Google m'indique que la syntaxe YAML a été conçue spécifiquement pour être facilement lisible par les gens plutôt que par les machines.
Cordialement, -- Olivier Miakinen
Une Bévue
Le 16/02/2012 16:50, Olivier Miakinen a écrit :
Soit dit en passant, si le setup.yml est la même chose que le setup.yaml dont tu parlais au début, et s'il est donc « encodé en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi s'embêter avec des xNN illisibles au lieu de mettre les vrais caractères ! En effet, je ne connaissais pas YAML, mais une recherche Google m'indique que la syntaxe YAML a été conçue spécifiquement pour être facilement lisible par les gens plutôt que par les machines.
bonsoir,
oui, oui, il n'y a qu'un fichier "setup.yml" écrit par ruby 1.8.x sous Mac OS X et lu par php 5.3.6 sous Xubuntu 11.10.
le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose comme : "Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon côté php la doc n'est pas terrible effectivement. il y a même une fonction non implémentée : $res=yaml_emit_file ( 'yaml-write.yml', $data , YAML_UTF8_ENCODING);// line 39 // Warning: yaml_emit_file(): not yet implemented in /home/yt/Sites/php/yaml-write.php on line 39
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui : yaml.decode_binary boolean Off par défaut, si mis à on : permet le décodage des entités binaires base64 ayant le tag explicite "tag:yaml.org,2002:binary". cf. <http://php.net/manual/fr/yaml.configuration.php>
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais (devine) mieux d'où vient le problème...
Le 16/02/2012 16:50, Olivier Miakinen a écrit :
Soit dit en passant, si le setup.yml est la même chose que le
setup.yaml dont tu parlais au début, et s'il est donc « encodé
en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi
s'embêter avec des xNN illisibles au lieu de mettre les vrais
caractères ! En effet, je ne connaissais pas YAML, mais une
recherche Google m'indique que la syntaxe YAML a été conçue
spécifiquement pour être facilement lisible par les gens
plutôt que par les machines.
bonsoir,
oui, oui, il n'y a qu'un fichier "setup.yml" écrit par ruby 1.8.x sous
Mac OS X et lu par php 5.3.6 sous Xubuntu 11.10.
le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je
suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose
comme :
"Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml
comment transcoder en UTF-8 "ordinaire"...
bon côté php la doc n'est pas terrible effectivement.
il y a même une fonction non implémentée :
$res=yaml_emit_file ( 'yaml-write.yml', $data , YAML_UTF8_ENCODING);//
line 39
// Warning: yaml_emit_file(): not yet implemented in
/home/yt/Sites/php/yaml-write.php on line 39
Directive Local Value Master Value
yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui :
yaml.decode_binary boolean
Off par défaut, si mis à on : permet le décodage des entités binaires
base64 ayant le tag explicite "tag:yaml.org,2002:binary".
cf. <http://php.net/manual/fr/yaml.configuration.php>
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais
(devine) mieux d'où vient le problème...
Soit dit en passant, si le setup.yml est la même chose que le setup.yaml dont tu parlais au début, et s'il est donc « encodé en UTF-8 NO BOM » (je te cite), alors je ne vois pas pourquoi s'embêter avec des xNN illisibles au lieu de mettre les vrais caractères ! En effet, je ne connaissais pas YAML, mais une recherche Google m'indique que la syntaxe YAML a été conçue spécifiquement pour être facilement lisible par les gens plutôt que par les machines.
bonsoir,
oui, oui, il n'y a qu'un fichier "setup.yml" écrit par ruby 1.8.x sous Mac OS X et lu par php 5.3.6 sous Xubuntu 11.10.
le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose comme : "Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon côté php la doc n'est pas terrible effectivement. il y a même une fonction non implémentée : $res=yaml_emit_file ( 'yaml-write.yml', $data , YAML_UTF8_ENCODING);// line 39 // Warning: yaml_emit_file(): not yet implemented in /home/yt/Sites/php/yaml-write.php on line 39
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui : yaml.decode_binary boolean Off par défaut, si mis à on : permet le décodage des entités binaires base64 ayant le tag explicite "tag:yaml.org,2002:binary". cf. <http://php.net/manual/fr/yaml.configuration.php>
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais (devine) mieux d'où vient le problème...
unbewusst.sein
Une Bévue wrote:
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande : $ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml pas de chance, ça me donne tjs : MxC3xA9dical pour Médical
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Une Bévue <unbewusstsein@fai.invalid> wrote:
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml
comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande :
$ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml
pas de chance, ça me donne tjs :
MxC3xA9dical
pour Médical
--
« Les conneries c'est comme les impôts,
on finit toujours par les payer. »
(Michel Audiard)
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande : $ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml pas de chance, ça me donne tjs : MxC3xA9dical pour Médical
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Olivier Miakinen
Le 16/02/2012 18:24, Une Bévue m'a répondu :
oui, oui, il n'y a qu'un fichier "setup.yml" écrit par ruby 1.8.x sous Mac OS X et lu par php 5.3.6 sous Xubuntu 11.10.
Ok.
le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose comme : "Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML, tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui : yaml.decode_binary boolean Off par défaut, si mis à on : permet le décodage des entités binaires base64 ayant le tag explicite "tag:yaml.org,2002:binary". cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre problème, donc.
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais (devine) mieux d'où vient le problème...
Permets-moi d'en douter... (désolé)
Le 16/02/2012 18:24, Une Bévue m'a répondu :
oui, oui, il n'y a qu'un fichier "setup.yml" écrit par ruby 1.8.x sous
Mac OS X et lu par php 5.3.6 sous Xubuntu 11.10.
Ok.
le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP
pour la seconde, ce qui expliquerait qu'ils ne puissent pas
s'entendre.
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je
n'ai pas réussi à trouver une doc que je sache lire.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je
suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose
comme :
"Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml
comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML,
tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
Directive Local Value Master Value
yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui :
yaml.decode_binary boolean
Off par défaut, si mis à on : permet le décodage des entités binaires
base64 ayant le tag explicite "tag:yaml.org,2002:binary".
cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre
problème, donc.
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais
(devine) mieux d'où vient le problème...
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
mais bon, je commence à piger ce qui se passe.
en fait "Médical" est une string provenant du carnet d'adresse, je suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose comme : "Me'dical", l'accent du é étant placé à côté du e.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML, tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
Directive Local Value Master Value yaml.decode_binary 0 0
Et ça, tu sais ce que ça veut dire ?
oui : yaml.decode_binary boolean Off par défaut, si mis à on : permet le décodage des entités binaires base64 ayant le tag explicite "tag:yaml.org,2002:binary". cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre problème, donc.
en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais (devine) mieux d'où vient le problème...
Permets-moi d'en douter... (désolé)
Olivier Miakinen
Le 16/02/2012 19:18, Une Bévue a écrit :
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande : $ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml pas de chance, ça me donne tjs : MxC3xA9dical
Haha... ça tu aurais dû t'en douter. Parce que, jusqu'à preuve du contraire, les caractères « », « x », « C », « 3 », « A » et « 9 » qui sont dans ton fichier setup.yaml, c'est de l'ASCII 7 bits, et ils n'ont qu'une seule représentation possible en UTF-8 !
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
Le 16/02/2012 19:18, Une Bévue a écrit :
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml
comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande :
$ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml
pas de chance, ça me donne tjs :
MxC3xA9dical
Haha... ça tu aurais dû t'en douter. Parce que, jusqu'à preuve du
contraire, les caractères « », « x », « C », « 3 », « A » et « 9 »
qui sont dans ton fichier setup.yaml, c'est de l'ASCII 7 bits, et
ils n'ont qu'une seule représentation possible en UTF-8 !
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer
d'éditer ton fichier avec un éditeur de texte, y rajouter un simple
« é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner
en pâture à PHP.
plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml comment transcoder en UTF-8 "ordinaire"...
bon, je viens d'essayer en ligne de commande : $ iconv -f UTF-8-MAC -t UTF-8 setup.yaml > setup-utf8.yaml pas de chance, ça me donne tjs : MxC3xA9dical
Haha... ça tu aurais dû t'en douter. Parce que, jusqu'à preuve du contraire, les caractères « », « x », « C », « 3 », « A » et « 9 » qui sont dans ton fichier setup.yaml, c'est de l'ASCII 7 bits, et ils n'ont qu'une seule représentation possible en UTF-8 !
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
unbewusst.sein
Olivier Miakinen <om+ wrote:
> le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
ben en fait comme je sais par ailleurs que ça représente un é, ce sont deux octets.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM ou UTF-16 AVEC BOM
> mais bon, je commence à piger ce qui se passe. > > en fait "Médical" est une string provenant du carnet d'adresse, je > suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose > comme : > "Me'dical", l'accent du é étant placé à côté du e.
> plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml > comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML, tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
oui, me reste à trouver comment. Je ne peux pas changer de version de yaml côté ruby car c'est builtin.
>>> Directive Local Value Master Value >>> yaml.decode_binary 0 0 >> Et ça, tu sais ce que ça veut dire ? > > oui : > yaml.decode_binary boolean > Off par défaut, si mis à on : permet le décodage des entités binaires > base64 ayant le tag explicite "tag:yaml.org,2002:binary". > cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre problème, donc.
non, rien à voir.
> en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais > (devine) mieux d'où vient le problème...
Permets-moi d'en douter... (désolé)
C'est vrai )))
En fait entretemps je me suis assuré que le problème vient de yaml/ruby... -- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Olivier Miakinen <om+news@miakinen.net> wrote:
> le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
ben en fait comme je sais par ailleurs que ça représente un é, ce sont
deux octets.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP
pour la seconde, ce qui expliquerait qu'ils ne puissent pas
s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction
utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je
n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM
ou UTF-16 AVEC BOM
> mais bon, je commence à piger ce qui se passe.
>
> en fait "Médical" est une string provenant du carnet d'adresse, je
> suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose
> comme :
> "Me'dical", l'accent du é étant placé à côté du e.
> plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml
> comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML,
tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
oui, me reste à trouver comment. Je ne peux pas changer de version de
yaml côté ruby car c'est builtin.
>>> Directive Local Value Master Value
>>> yaml.decode_binary 0 0
>> Et ça, tu sais ce que ça veut dire ?
>
> oui :
> yaml.decode_binary boolean
> Off par défaut, si mis à on : permet le décodage des entités binaires
> base64 ayant le tag explicite "tag:yaml.org,2002:binary".
> cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre
problème, donc.
non, rien à voir.
> en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais
> (devine) mieux d'où vient le problème...
Permets-moi d'en douter... (désolé)
C'est vrai )))
En fait entretemps je me suis assuré que le problème vient de
yaml/ruby...
--
« Les conneries c'est comme les impôts,
on finit toujours par les payer. »
(Michel Audiard)
ben en fait comme je sais par ailleurs que ça représente un é, ce sont deux octets.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM ou UTF-16 AVEC BOM
> mais bon, je commence à piger ce qui se passe. > > en fait "Médical" est une string provenant du carnet d'adresse, je > suppose qu'elle est en UTF-8 "à la mac OS X" c'est-à-dire quelque chose > comme : > "Me'dical", l'accent du é étant placé à côté du e.
> plutôt que "bidouiller" côté php, je devrais regarder, côté ruby/yaml > comment transcoder en UTF-8 "ordinaire"...
Là, je suis entièrement d'accord. Si j'en crois la philosophie de YAML, tu *dois* pouvoir obtenir un é lisible directement dans setup.y[a]ml.
oui, me reste à trouver comment. Je ne peux pas changer de version de yaml côté ruby car c'est builtin.
>>> Directive Local Value Master Value >>> yaml.decode_binary 0 0 >> Et ça, tu sais ce que ça veut dire ? > > oui : > yaml.decode_binary boolean > Off par défaut, si mis à on : permet le décodage des entités binaires > base64 ayant le tag explicite "tag:yaml.org,2002:binary". > cf. <http://php.net/manual/fr/yaml.configuration.php>
Ah, d'accord, c'est pour du Base64. Strictement rien à voir avec notre problème, donc.
non, rien à voir.
> en tout cas, merci bien d'avoir répondu, sans avoir la solution, je sais > (devine) mieux d'où vient le problème...
Permets-moi d'en douter... (désolé)
C'est vrai )))
En fait entretemps je me suis assuré que le problème vient de yaml/ruby... -- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
unbewusst.sein
Olivier Miakinen <om+ wrote:
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
mouais, mais bon, ça ne me plait pas parce que ce fichier est généré automatiquement. je viens de vérifier, ça se passe du côté de yaml/ruby. si je fais un print-out des données avant yaml, c'est bon...
pourtant je lis : <http://stackoverflow.com/questions/488694/how-to-set-the-character-enco ding-in-a-yaml-file>
The YAML 1.1 spec (which you link to) says that UTF-8 is implied if there is no BOM, and that BOM's should be output only on UTF-16 docs. So the presence of a BOM, and the BOM if it exists, are the only ways to define the encoding.
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Olivier Miakinen <om+news@miakinen.net> wrote:
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer
d'éditer ton fichier avec un éditeur de texte, y rajouter un simple
« é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner
en pâture à PHP.
mouais, mais bon, ça ne me plait pas parce que ce fichier est généré
automatiquement.
je viens de vérifier, ça se passe du côté de yaml/ruby.
si je fais un print-out des données avant yaml, c'est bon...
pourtant je lis :
<http://stackoverflow.com/questions/488694/how-to-set-the-character-enco
ding-in-a-yaml-file>
The YAML 1.1 spec (which you link to) says that UTF-8 is implied if
there is no BOM, and that BOM's should be output only on UTF-16 docs. So
the presence of a BOM, and the BOM if it exists, are the only ways to
define the encoding.
--
« Les conneries c'est comme les impôts,
on finit toujours par les payer. »
(Michel Audiard)
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
mouais, mais bon, ça ne me plait pas parce que ce fichier est généré automatiquement. je viens de vérifier, ça se passe du côté de yaml/ruby. si je fais un print-out des données avant yaml, c'est bon...
pourtant je lis : <http://stackoverflow.com/questions/488694/how-to-set-the-character-enco ding-in-a-yaml-file>
The YAML 1.1 spec (which you link to) says that UTF-8 is implied if there is no BOM, and that BOM's should be output only on UTF-16 docs. So the presence of a BOM, and the BOM if it exists, are the only ways to define the encoding.
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
unbewusst.sein
Une Bévue wrote:
je viens de vérifier, ça se passe du côté de yaml/ruby. si je fais un print-out des données avant yaml, c'est bon...
si je fais un aller/retour yaml : yaml_obj = YAML::dump( @choosen_groups_a )
# -> "MxC3xA9dical"
ruby_obj = YAML::load( yaml_obj )
# -> Médical
yaml/ruby retrouve ses petits...
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Une Bévue <unbewusst.sein@fai.invalid> wrote:
je viens de vérifier, ça se passe du côté de yaml/ruby.
si je fais un print-out des données avant yaml, c'est bon...
si je fais un aller/retour yaml :
yaml_obj = YAML::dump( @choosen_groups_a )
# -> "MxC3xA9dical"
ruby_obj = YAML::load( yaml_obj )
# -> Médical
yaml/ruby retrouve ses petits...
--
« Les conneries c'est comme les impôts,
on finit toujours par les payer. »
(Michel Audiard)
je viens de vérifier, ça se passe du côté de yaml/ruby. si je fais un print-out des données avant yaml, c'est bon...
si je fais un aller/retour yaml : yaml_obj = YAML::dump( @choosen_groups_a )
# -> "MxC3xA9dical"
ruby_obj = YAML::load( yaml_obj )
# -> Médical
yaml/ruby retrouve ses petits...
-- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
unbewusst.sein
Olivier Miakinen <om+ wrote:
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
À force de googler, j'ai trouvé une solution côté rub... certains prétendent que yaml (du core ruby) utilise base64 ???
m'enfin, il y a un module externe "ya2yaml" (yet another yaml) qui marche en utf-8.
je viens de vérifier, c'est bon côté mac/ruby et Ubuntu/php...
OUF )))
PS : des japonais ont eu des pbs d'encodage avec yaml... -- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Olivier Miakinen <om+news@miakinen.net> wrote:
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer
d'éditer ton fichier avec un éditeur de texte, y rajouter un simple
« é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner
en pâture à PHP.
À force de googler, j'ai trouvé une solution côté rub...
certains prétendent que yaml (du core ruby) utilise base64 ???
m'enfin, il y a un module externe "ya2yaml" (yet another yaml) qui
marche en utf-8.
je viens de vérifier, c'est bon côté mac/ruby et Ubuntu/php...
OUF )))
PS : des japonais ont eu des pbs d'encodage avec yaml...
--
« Les conneries c'est comme les impôts,
on finit toujours par les payer. »
(Michel Audiard)
Mais plutôt que de lancer un outil tel que iconv, tu devrais essayer d'éditer ton fichier avec un éditeur de texte, y rajouter un simple « é », et sauver le résultat (en UTF-8 sans BOM) avant de le donner en pâture à PHP.
À force de googler, j'ai trouvé une solution côté rub... certains prétendent que yaml (du core ruby) utilise base64 ???
m'enfin, il y a un module externe "ya2yaml" (yet another yaml) qui marche en utf-8.
je viens de vérifier, c'est bon côté mac/ruby et Ubuntu/php...
OUF )))
PS : des japonais ont eu des pbs d'encodage avec yaml... -- « Les conneries c'est comme les impôts, on finit toujours par les payer. » (Michel Audiard)
Olivier Miakinen
Le 16/02/2012 23:56, Une Bévue a écrit :
> le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
ben en fait comme je sais par ailleurs que ça représente un é, ce sont deux octets.
C'est ce que tu aimerais, mais visiblement PHP n'est pas d'accord ! Sache que le caractère U+00C3 et le caractère U+00A9 existent tous les deux dans Unicode, qu'ils se codent chacun en deux octets en UTF-8 (donc quatre octets au total), et que visiblement c'est comme ça que PHP les voit.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM ou UTF-16 AVEC BOM
Ce n'est pas ma question. Que dit la norme YAML à propos des séquences d'échappement constituées d'un antislash , d'un x minuscule, et de deux (ou plus ?) chiffres hexadécimaux ? Merci de trouver cette partie de la doc si tu le peux. Tant qu'on n'aura pas cette info, il sera impossible de savoir si le bug (car il y a visiblement un bug) se trouve du côté de Ruby ou du côté de PHP.
Je vais continuer à chercher de mon côté, mais merci de le faire aussi. Tu peux regarder aussi dans la doc de Ruby (je l'ai fait pour PHP, sans résultat).
Le 16/02/2012 23:56, Une Bévue a écrit :
> le é de "Médical" est codé xC3xA9 par le module yaml de ruby.
ben en fait comme je sais par ailleurs que ça représente un é, ce sont
deux octets.
C'est ce que tu aimerais, mais visiblement PHP n'est pas d'accord !
Sache que le caractère U+00C3 et le caractère U+00A9 existent tous
les deux dans Unicode, qu'ils se codent chacun en deux octets en
UTF-8 (donc quatre octets au total), et que visiblement c'est comme
ça que PHP les voit.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP
pour la seconde, ce qui expliquerait qu'ils ne puissent pas
s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction
utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je
n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM
ou UTF-16 AVEC BOM
Ce n'est pas ma question. Que dit la norme YAML à propos des séquences
d'échappement constituées d'un antislash , d'un x minuscule, et de
deux (ou plus ?) chiffres hexadécimaux ? Merci de trouver cette partie
de la doc si tu le peux. Tant qu'on n'aura pas cette info, il sera
impossible de savoir si le bug (car il y a visiblement un bug) se
trouve du côté de Ruby ou du côté de PHP.
Je vais continuer à chercher de mon côté, mais merci de le faire aussi.
Tu peux regarder aussi dans la doc de Ruby (je l'ai fait pour PHP, sans
résultat).
ben en fait comme je sais par ailleurs que ça représente un é, ce sont deux octets.
C'est ce que tu aimerais, mais visiblement PHP n'est pas d'accord ! Sache que le caractère U+00C3 et le caractère U+00A9 existent tous les deux dans Unicode, qu'ils se codent chacun en deux octets en UTF-8 (donc quatre octets au total), et que visiblement c'est comme ça que PHP les voit.
Si ça se trouve, Ruby penche pour la première hypothèse et PHP pour la seconde, ce qui expliquerait qu'ils ne puissent pas s'entendre.
ouais et, ce qui est encore plus curieux, c'est que la fonction utf8_decode/php renvoie de l'utf-8 dans ce cas et pas de l'iso 8859-1...
Que dit la norme YAML ? J'ai essayé de trouver l'info, mais je n'ai pas réussi à trouver une doc que je sache lire.
UTF-8 NO BOM ou UTF-16 AVEC BOM
Ce n'est pas ma question. Que dit la norme YAML à propos des séquences d'échappement constituées d'un antislash , d'un x minuscule, et de deux (ou plus ?) chiffres hexadécimaux ? Merci de trouver cette partie de la doc si tu le peux. Tant qu'on n'aura pas cette info, il sera impossible de savoir si le bug (car il y a visiblement un bug) se trouve du côté de Ruby ou du côté de PHP.
Je vais continuer à chercher de mon côté, mais merci de le faire aussi. Tu peux regarder aussi dans la doc de Ruby (je l'ai fait pour PHP, sans résultat).