Xavier Roche
2006-01-17 08:50:43 UTC
(Xpost avec fr.lettres.langue.chinoise, FU2 fr.comp.normes.unicode)
Je Xposte avec fllc, au cas où des spécialistes peuvent me dire si "交换
" et "交換" sont équivalents (et si le second a seulement une
signification) ?
L'ISO-2022-CN normalise comme vous le savez peut être un encodage des
caractères chinois ; et fait l'objet d'une RFC (RFC 1922 ;
<http://www.ietf.org/rfc/rfc1922.txt>)
J'ai quelques difficultés à comprendre l'exemple donné dans cette RFC,
donné au point 1.2.
Je cite: "Example: the hex sequence
1b 24 29 41 0e 3d 3b 3b 3b 1b 24 29 47 47 28 5f 50 0f
represents the Chinese word for "Interchange" (jiao huan) twice"
De mon côté je trouve les deux paires:
4ea4 6362 4ea4 63db
Soit ce qu'on attent pour la première paire ("交换", "exchange" selon
babelfish :p), mais "交換" pour la seconde (ce qui ne semble rien dire
du tout ? - le 2e caractère est légèrement différent)
Pourtant la séquence est: 4728 5f50, et on est bien placé après un
changement en CNS 11643-plane-1 (ESC $ ) G, "indicates the bytes
following SO are as defined in CNS 11643-plane-1, until another
SOdesignation appears") et 5f50 en CNS 11643-1986 correspond bien au
codepoint 63DB
(<http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/CNS11643.TXT>):
0x15F50 0x63DB # <CJK>
Bref, si quelqun pouvait éclairer ma lanterne :p
[ Note: J'ai bien essayé avec iconv, mais je me demande si il n'a pas un
bug dans le jeu ISO-2022-CN ; en tout cas en version 2.3.5
$ echo -e \
"\x1b\x24\x29\x41\x0e\x3d\x3b\x3b\x3b\x1b\x24\x29\x47\x47\x28\x5f\x50\x0f"
\
| iconv -f iso-2022-cn -t ucs2 | hexdump
4ea4 6362 8fc1 549d
On retrouve bien 4ea4-6362 ; mais pour le second 8fc1-549d (soit "迁咝",
qui semble ne rien vouloir dire du tout) ]
Je Xposte avec fllc, au cas où des spécialistes peuvent me dire si "交换
" et "交換" sont équivalents (et si le second a seulement une
signification) ?
L'ISO-2022-CN normalise comme vous le savez peut être un encodage des
caractères chinois ; et fait l'objet d'une RFC (RFC 1922 ;
<http://www.ietf.org/rfc/rfc1922.txt>)
J'ai quelques difficultés à comprendre l'exemple donné dans cette RFC,
donné au point 1.2.
Je cite: "Example: the hex sequence
1b 24 29 41 0e 3d 3b 3b 3b 1b 24 29 47 47 28 5f 50 0f
represents the Chinese word for "Interchange" (jiao huan) twice"
De mon côté je trouve les deux paires:
4ea4 6362 4ea4 63db
Soit ce qu'on attent pour la première paire ("交换", "exchange" selon
babelfish :p), mais "交換" pour la seconde (ce qui ne semble rien dire
du tout ? - le 2e caractère est légèrement différent)
Pourtant la séquence est: 4728 5f50, et on est bien placé après un
changement en CNS 11643-plane-1 (ESC $ ) G, "indicates the bytes
following SO are as defined in CNS 11643-plane-1, until another
SOdesignation appears") et 5f50 en CNS 11643-1986 correspond bien au
codepoint 63DB
(<http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/CNS11643.TXT>):
0x15F50 0x63DB # <CJK>
Bref, si quelqun pouvait éclairer ma lanterne :p
[ Note: J'ai bien essayé avec iconv, mais je me demande si il n'a pas un
bug dans le jeu ISO-2022-CN ; en tout cas en version 2.3.5
$ echo -e \
"\x1b\x24\x29\x41\x0e\x3d\x3b\x3b\x3b\x1b\x24\x29\x47\x47\x28\x5f\x50\x0f"
\
| iconv -f iso-2022-cn -t ucs2 | hexdump
4ea4 6362 8fc1 549d
On retrouve bien 4ea4-6362 ; mais pour le second 8fc1-549d (soit "迁咝",
qui semble ne rien vouloir dire du tout) ]