NARUSE, Yui
narus****@airem*****
2006年 5月 19日 (金) 08:21:26 JST
成瀬です。
Tomoyuki Asakawa wrote:
> あさかわ
>
>>> そういう意味では、WindowsのAPIも酷い。
>> 標準なAPIを使った後、正規化のAPIを用いることになる
>> かと思います。
>
> 標準APIでカバーしてない文字は、捨てられてしまうので。その
> あとでは、正規化不能です。
CP932→Unicodeに関して言えば、カバーしていない文字は存在しないはずです。
>> Transform Rule をちょろちょろと書けば言いだけの話に感じます。
>> 極端な話、s/\x{301C}/\x{FF5E}/gすればいいことですしね。
>
> いや、そこへ来る前にすてられたらなにもできないのよ。
>
> euc-jp-ms -> CP932で、X0212文字は捨てられる。
> すてられたら、ルール書こうにもかけないでしょ。
euc-jp-ms -> CP932 という変換それ自体が行うべきでない変換ですが、
さておき、その変換は正確ではないです。
eucJP-ms -> Unicode -> CP932 のはずでしょう。
> ただし、Transform Ruleが、入力側に働けば別ですけどね。
> この手の実装って、出力しかかんがえてないのではありませんか？
> 入力したら、すでに内部はUNICODEでしょ。
>
> 入力に働けば
> euc-jp-ms上のX0212文字のうち、使用してるものだけ
> X0208エリアの未使用領域に振り分けて、読み込む
> 出力する時に、CP932上の外字領域に、再度変換する。
> なんてことができる。
Legacy Encoding -> Unicode では多対一変換は行われないので、
再変換は常に可能なはずです。
なお、legacy to legacyを一度に行うとfallbackができないというのは、
PerlのEncodeモジュールのfrom_to実装とかもそうですね。
Jcode.pmメーリングリストの
[Jcode5 786] Re: Encodeの CHECK関係について
も同じ問題だと思いますが、
UnicodeによるUCS正規化が行われている文字コード変換においては、
legacy to legacy は decode & encode なので。
--
NARUSE, Yui <narus****@airem*****>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA