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.
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.
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.
À force de googler, j'ai trouvé une solution côté rub...
[...] 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...
PS : des japonais ont eu des pbs d'encodage avec yaml...
À force de googler, j'ai trouvé une solution côté rub...
[...] 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...
PS : des japonais ont eu des pbs d'encodage avec yaml...
À force de googler, j'ai trouvé une solution côté rub...
[...] 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...
PS : des japonais ont eu des pbs d'encodage avec yaml...
Tu n'as pas répondu à ma question, probablement parce que tu ne
connaissais pas la réponse. Est-ce que xC3 et xA9 sont censés
représenter des octets, auquel cas xC3xA9 serait le codage
d'un « é » en UTF-8, ou bien sont-ils censés représenter des
caractères, auquel cas xC3 serait un « Ã » et xA9 un « © » ?
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.
[...] 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).
Tu n'as pas répondu à ma question, probablement parce que tu ne
connaissais pas la réponse. Est-ce que xC3 et xA9 sont censés
représenter des octets, auquel cas xC3xA9 serait le codage
d'un « é » en UTF-8, ou bien sont-ils censés représenter des
caractères, auquel cas xC3 serait un « Ã » et xA9 un « © » ?
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.
[...] 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).
Tu n'as pas répondu à ma question, probablement parce que tu ne
connaissais pas la réponse. Est-ce que xC3 et xA9 sont censés
représenter des octets, auquel cas xC3xA9 serait le codage
d'un « é » en UTF-8, ou bien sont-ils censés représenter des
caractères, auquel cas xC3 serait un « Ã » et xA9 un « © » ?
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.
[...] 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).
Et alors ? Tu refuses de faire un test qui nous permettrait d'y voir
un peu plus clair, tant qu'on n'a pas une norme à se mettre sous la
dent ?
Et alors ? Tu refuses de faire un test qui nous permettrait d'y voir
un peu plus clair, tant qu'on n'a pas une norme à se mettre sous la
dent ?
Et alors ? Tu refuses de faire un test qui nous permettrait d'y voir
un peu plus clair, tant qu'on n'a pas une norme à se mettre sous la
dent ?
> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
>> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
>> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
>> 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 ça, je veux bien le croire, vu le problème que tu as eu avec un
simple « é » ! Bon, je suis ravi que ce soit résolu pour toi.
Ben ça, je veux bien le croire, vu le problème que tu as eu avec un
simple « é » ! Bon, je suis ravi que ce soit résolu pour toi.
Ben ça, je veux bien le croire, vu le problème que tu as eu avec un
simple « é » ! Bon, je suis ravi que ce soit résolu pour toi.
... et c'est PHP qui a raison, par rapport à ton premier outil Ruby.
> [...] 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).
En bref : <http://yaml.org/refcard.html>
<cit.>
Escape codes:
Numeric : { "x12": 8-bit, "u1234": 16-bit, "U00102030": 32-bit }
</cit.>
En plus détaillé : <http://yaml.org/spec/current.html#id2517668>.
Et donc, xC3xA9 représente *vraiment* la séquence de deux caractères
« é » et non le caractère « é ». Ce dernier peut s'écrire sous la
forme xE9, ou bien u00E9, ou encore U000000E9.
Mais surtout, comme « é » n'est pas un « non-printable character »
(caractère non imprimable), il faut surtout l'écrire tel quel et non
sous forme d'une séquence d'échappement.
... et c'est PHP qui a raison, par rapport à ton premier outil Ruby.
> [...] 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).
En bref : <http://yaml.org/refcard.html>
<cit.>
Escape codes:
Numeric : { "x12": 8-bit, "u1234": 16-bit, "U00102030": 32-bit }
</cit.>
En plus détaillé : <http://yaml.org/spec/current.html#id2517668>.
Et donc, xC3xA9 représente *vraiment* la séquence de deux caractères
« é » et non le caractère « é ». Ce dernier peut s'écrire sous la
forme xE9, ou bien u00E9, ou encore U000000E9.
Mais surtout, comme « é » n'est pas un « non-printable character »
(caractère non imprimable), il faut surtout l'écrire tel quel et non
sous forme d'une séquence d'échappement.
... et c'est PHP qui a raison, par rapport à ton premier outil Ruby.
> [...] 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).
En bref : <http://yaml.org/refcard.html>
<cit.>
Escape codes:
Numeric : { "x12": 8-bit, "u1234": 16-bit, "U00102030": 32-bit }
</cit.>
En plus détaillé : <http://yaml.org/spec/current.html#id2517668>.
Et donc, xC3xA9 représente *vraiment* la séquence de deux caractères
« é » et non le caractère « é ». Ce dernier peut s'écrire sous la
forme xE9, ou bien u00E9, ou encore U000000E9.
Mais surtout, comme « é » n'est pas un « non-printable character »
(caractère non imprimable), il faut surtout l'écrire tel quel et non
sous forme d'une séquence d'échappement.
> ben en fait comme je sais par ailleurs que ça représente un é, ce sont
> deux octets.
C'est ce que tu aimerais,
euh, comme ces strings correspondent à des noms de groupes dans mon
carnet d'adresse, j'en suis sûr...
> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
oui, mais ce que je ne pige pas est que visuellement, sur le butineur
(chrome et firefox) il n'y a pas d'artefact dans ce mélange UTF-8 et
iso-8859-1...
reconversion au vol ?
[...]
dans mon cas (yaml/ruby), j'ai :
"MxC3xA9dical"
c'est bien doubly quoted.
mais bon, il est dit "All non-printable characters must be presented as
escape sequences" le é est printable...
plus loin :
Escaped 8-bit Unicode character:
[62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
Escaped 16-bit Unicode character:
[63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
le é est bien sur 2 fois 8 bits,
si je comprends bien, il aurait du être codé : uC3A9
non ?
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.
oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
fichier yaml redonne les bonnes strings
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).
Ah, moins de doc côté php ?
> ben en fait comme je sais par ailleurs que ça représente un é, ce sont
> deux octets.
C'est ce que tu aimerais,
euh, comme ces strings correspondent à des noms de groupes dans mon
carnet d'adresse, j'en suis sûr...
> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
oui, mais ce que je ne pige pas est que visuellement, sur le butineur
(chrome et firefox) il n'y a pas d'artefact dans ce mélange UTF-8 et
iso-8859-1...
reconversion au vol ?
[...]
dans mon cas (yaml/ruby), j'ai :
"MxC3xA9dical"
c'est bien doubly quoted.
mais bon, il est dit "All non-printable characters must be presented as
escape sequences" le é est printable...
plus loin :
Escaped 8-bit Unicode character:
[62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
Escaped 16-bit Unicode character:
[63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
le é est bien sur 2 fois 8 bits,
si je comprends bien, il aurait du être codé : uC3A9
non ?
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.
oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
fichier yaml redonne les bonnes strings
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).
Ah, moins de doc côté php ?
> ben en fait comme je sais par ailleurs que ça représente un é, ce sont
> deux octets.
C'est ce que tu aimerais,
euh, comme ces strings correspondent à des noms de groupes dans mon
carnet d'adresse, j'en suis sûr...
> 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...
Non, pas du tout. À ce que je vois, tu passes à la fonction utf8_decode
un caractère à en UTF-8 qu'elle traduit en ISO-8859-1, puis un © en
UTF-8 qu'elle traduit de même en ISO-8859-1. Il se trouve que ces deux
caractères ISO-8859-1, l'un derrière l'autre, se codent de la même
façon que le caractère é en UTF-8, mais -- si je puis dire -- la
fonction utf8_encode s'en fout !
oui, mais ce que je ne pige pas est que visuellement, sur le butineur
(chrome et firefox) il n'y a pas d'artefact dans ce mélange UTF-8 et
iso-8859-1...
reconversion au vol ?
[...]
dans mon cas (yaml/ruby), j'ai :
"MxC3xA9dical"
c'est bien doubly quoted.
mais bon, il est dit "All non-printable characters must be presented as
escape sequences" le é est printable...
plus loin :
Escaped 8-bit Unicode character:
[62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
Escaped 16-bit Unicode character:
[63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
le é est bien sur 2 fois 8 bits,
si je comprends bien, il aurait du être codé : uC3A9
non ?
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.
oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
fichier yaml redonne les bonnes strings
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).
Ah, moins de doc côté php ?
Ah tiens, j'ai une idée. Au lieu d'UTF-8 que tu ne sembles pas bien
maîtriser supposons que l'encodage soit une simple traduction des
octets en hexadécimal. Au lieu de regarder le codage du é, regardons
celui du 'A'. Son code ASCII est 41 en hexadécimal. Dans un fichier,
tu auras donc un octet qui vaut 41 hexa pour représenter le A.
Supposons qu'un outil un peu neuneu, au lieu de mettre un code 41
dans le fichier, considère que le '4' vaut 34 en hexa et que le '1'
vaut 31 en hexa, et qu'il mette 34 31 au lieu de 41. Eh bien on
est dans le même cas : ton fichier setup.yaml contenait non pas
un codage pour le é, mais un codage pour des octets représentant
eux mêmes un codage pour le é.
Et donc, puisque tu avais un codage UTF-8 d'un codage UTF-8 du é,
au lieu d'un codage UTF-8 du é, il te fallait bien faire un
*décodage* UTF-8 (utf8_decode) pour obtenir quelque chose qui
était un simple codage UTF-8 du é.
> [...]
>
> dans mon cas (yaml/ruby), j'ai :
> "MxC3xA9dical"
> c'est bien doubly quoted.
Oui. En fait tu avais un codage par caractères d'échappement du
« surcodage » UTF-8 d'un caractère... Une fois décodées les séquences
d'échappement, cette chaîne vaut "Médical" et pas "Médical".
> mais bon, il est dit "All non-printable characters must be presented as
> escape sequences" le é est printable...
>
> plus loin :
> Escaped 8-bit Unicode character:
> [62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
> Escaped 16-bit Unicode character:
> [63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
>
> le é est bien sur 2 fois 8 bits,
Non. Tant qu'il n'est pas codé selon un encodage donné (ISO-8859-1,
UTF-8, UTF-16, UTF-7 ou autre chose), le 'é' n'est pas « sur n bits ».
Il possède un numéro qui vaut 233 en décimal, et que l'on peut noter
U+00E9 dans Unicode. Vu que ce numéro est inférieur à 256, selon la
syntaxe de caractères d'échappement de YAML, tu peux donc l'écrire
sous la forme xE9 (en hexa 5C 78 45 39) ou u00E9 (en hexa 5C 75 30
30 45 39) ou encore U000000E9 (en hexa 5C 55 30 30 30 30 30 30 45 39).
> si je comprends bien, il aurait du être codé : uC3A9
> non ?
Non. Le caractère uC3A9 (U+C3A9) fait partie des syllabes hangûl :
<http://www.unicode.org/fr/charts/PDF/UAC00.pdf>. Voir aussi
<http://www.fileformat.info/info/unicode/char/c3a9/index.htm>.
Son codage en UTF-8 est EC 8E A9.
Le é c'est u00E9 (U+00E9) :
<http://www.unicode.org/fr/charts/PDF/U0080.pdf>.
C'est son codage en UTF-8 qui vaut C3 A9.
>> 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.
>
> oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
> fichier yaml redonne les bonnes strings
Oui. Son interprétation de la norme était erronée, mais au moins il
avait la même en lecture qu'en écriture.
>> 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).
>
> Ah, moins de doc côté php ?
Ben oui, mais ça tu l'avais déjà remarqué toi-même :
<http://www.php.net/manual/fr/book.yaml.php>
<http://www.php.net/manual/fr/intro.yaml.php>.
Ah tiens, j'ai une idée. Au lieu d'UTF-8 que tu ne sembles pas bien
maîtriser supposons que l'encodage soit une simple traduction des
octets en hexadécimal. Au lieu de regarder le codage du é, regardons
celui du 'A'. Son code ASCII est 41 en hexadécimal. Dans un fichier,
tu auras donc un octet qui vaut 41 hexa pour représenter le A.
Supposons qu'un outil un peu neuneu, au lieu de mettre un code 41
dans le fichier, considère que le '4' vaut 34 en hexa et que le '1'
vaut 31 en hexa, et qu'il mette 34 31 au lieu de 41. Eh bien on
est dans le même cas : ton fichier setup.yaml contenait non pas
un codage pour le é, mais un codage pour des octets représentant
eux mêmes un codage pour le é.
Et donc, puisque tu avais un codage UTF-8 d'un codage UTF-8 du é,
au lieu d'un codage UTF-8 du é, il te fallait bien faire un
*décodage* UTF-8 (utf8_decode) pour obtenir quelque chose qui
était un simple codage UTF-8 du é.
> [...]
>
> dans mon cas (yaml/ruby), j'ai :
> "MxC3xA9dical"
> c'est bien doubly quoted.
Oui. En fait tu avais un codage par caractères d'échappement du
« surcodage » UTF-8 d'un caractère... Une fois décodées les séquences
d'échappement, cette chaîne vaut "Médical" et pas "Médical".
> mais bon, il est dit "All non-printable characters must be presented as
> escape sequences" le é est printable...
>
> plus loin :
> Escaped 8-bit Unicode character:
> [62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
> Escaped 16-bit Unicode character:
> [63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
>
> le é est bien sur 2 fois 8 bits,
Non. Tant qu'il n'est pas codé selon un encodage donné (ISO-8859-1,
UTF-8, UTF-16, UTF-7 ou autre chose), le 'é' n'est pas « sur n bits ».
Il possède un numéro qui vaut 233 en décimal, et que l'on peut noter
U+00E9 dans Unicode. Vu que ce numéro est inférieur à 256, selon la
syntaxe de caractères d'échappement de YAML, tu peux donc l'écrire
sous la forme xE9 (en hexa 5C 78 45 39) ou u00E9 (en hexa 5C 75 30
30 45 39) ou encore U000000E9 (en hexa 5C 55 30 30 30 30 30 30 45 39).
> si je comprends bien, il aurait du être codé : uC3A9
> non ?
Non. Le caractère uC3A9 (U+C3A9) fait partie des syllabes hangûl :
<http://www.unicode.org/fr/charts/PDF/UAC00.pdf>. Voir aussi
<http://www.fileformat.info/info/unicode/char/c3a9/index.htm>.
Son codage en UTF-8 est EC 8E A9.
Le é c'est u00E9 (U+00E9) :
<http://www.unicode.org/fr/charts/PDF/U0080.pdf>.
C'est son codage en UTF-8 qui vaut C3 A9.
>> 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.
>
> oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
> fichier yaml redonne les bonnes strings
Oui. Son interprétation de la norme était erronée, mais au moins il
avait la même en lecture qu'en écriture.
>> 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).
>
> Ah, moins de doc côté php ?
Ben oui, mais ça tu l'avais déjà remarqué toi-même :
<http://www.php.net/manual/fr/book.yaml.php>
<http://www.php.net/manual/fr/intro.yaml.php>.
Ah tiens, j'ai une idée. Au lieu d'UTF-8 que tu ne sembles pas bien
maîtriser supposons que l'encodage soit une simple traduction des
octets en hexadécimal. Au lieu de regarder le codage du é, regardons
celui du 'A'. Son code ASCII est 41 en hexadécimal. Dans un fichier,
tu auras donc un octet qui vaut 41 hexa pour représenter le A.
Supposons qu'un outil un peu neuneu, au lieu de mettre un code 41
dans le fichier, considère que le '4' vaut 34 en hexa et que le '1'
vaut 31 en hexa, et qu'il mette 34 31 au lieu de 41. Eh bien on
est dans le même cas : ton fichier setup.yaml contenait non pas
un codage pour le é, mais un codage pour des octets représentant
eux mêmes un codage pour le é.
Et donc, puisque tu avais un codage UTF-8 d'un codage UTF-8 du é,
au lieu d'un codage UTF-8 du é, il te fallait bien faire un
*décodage* UTF-8 (utf8_decode) pour obtenir quelque chose qui
était un simple codage UTF-8 du é.
> [...]
>
> dans mon cas (yaml/ruby), j'ai :
> "MxC3xA9dical"
> c'est bien doubly quoted.
Oui. En fait tu avais un codage par caractères d'échappement du
« surcodage » UTF-8 d'un caractère... Une fois décodées les séquences
d'échappement, cette chaîne vaut "Médical" et pas "Médical".
> mais bon, il est dit "All non-printable characters must be presented as
> escape sequences" le é est printable...
>
> plus loin :
> Escaped 8-bit Unicode character:
> [62] ns-esc-8-bit ::= "" "x" ( ns-hex-digit x 2 )
> Escaped 16-bit Unicode character:
> [63] ns-esc-16-bit ::= "" "u" ( ns-hex-digit x 4 )
>
> le é est bien sur 2 fois 8 bits,
Non. Tant qu'il n'est pas codé selon un encodage donné (ISO-8859-1,
UTF-8, UTF-16, UTF-7 ou autre chose), le 'é' n'est pas « sur n bits ».
Il possède un numéro qui vaut 233 en décimal, et que l'on peut noter
U+00E9 dans Unicode. Vu que ce numéro est inférieur à 256, selon la
syntaxe de caractères d'échappement de YAML, tu peux donc l'écrire
sous la forme xE9 (en hexa 5C 78 45 39) ou u00E9 (en hexa 5C 75 30
30 45 39) ou encore U000000E9 (en hexa 5C 55 30 30 30 30 30 30 45 39).
> si je comprends bien, il aurait du être codé : uC3A9
> non ?
Non. Le caractère uC3A9 (U+C3A9) fait partie des syllabes hangûl :
<http://www.unicode.org/fr/charts/PDF/UAC00.pdf>. Voir aussi
<http://www.fileformat.info/info/unicode/char/c3a9/index.htm>.
Son codage en UTF-8 est EC 8E A9.
Le é c'est u00E9 (U+00E9) :
<http://www.unicode.org/fr/charts/PDF/U0080.pdf>.
C'est son codage en UTF-8 qui vaut C3 A9.
>> 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.
>
> oui, au moins ruby est consistant avec lui-même ie. une lecture d'un
> fichier yaml redonne les bonnes strings
Oui. Son interprétation de la norme était erronée, mais au moins il
avait la même en lecture qu'en écriture.
>> 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).
>
> Ah, moins de doc côté php ?
Ben oui, mais ça tu l'avais déjà remarqué toi-même :
<http://www.php.net/manual/fr/book.yaml.php>
<http://www.php.net/manual/fr/intro.yaml.php>.
