NARUSE, Yui
narus****@airem*****
2006年 3月 10日 (金) 17:29:02 JST
成瀬です。 ＃送信者だけに間違って送っていたので再送（’’ Tadamasa Teranishi wrote: > # JVN#18282718 の話は、ANSI版のWin32 APIを使った場合、コード変換を > # アプリケーションでは行わないので、WC_NO_BEST_FIT_CHARS で回避する > # ことは不可能なんですが... あ、直接は使ってないのですか。 > なお、MultiByteToWideChar にはもともと WC_NO_BEST_FIT_CHARS がない > ので、-sW -eW は無条件でそうなっていないといけないのでは? と > 思いますが、どうなんでしょう。 > (C) が C に変換されることはあっても、C が (C) にはそもそも変換され > ませんよね。 > --no-best-fit-chars オプションの有無で、-sW -eW の結果が変わる > のでしたら、具体的な例を教えてください。 MultiByteToWideChar ですからー、-wS -wE ですよね？ --no-best-fit-chars は、現在の実装では、 Unicode から JIS系の文字コードへの変換でのみ効果があります。 ですので、-wS -wE では変わりません。 無条件で NO_BEST_FIT_CHARS になっていると言うよりも、 元々の規格自体が BEST_FIT_CHARS を行っているので、 Microsoft側では追加の定義を行っておらず、 MB_NO_BEST_FIT_CHARSを行える余地が無い、といった所でしょうか。 ＃eucJP-ms等のマッピングを見ればわかりますが、 ＃多対一の定義は行われています。 ＃（全て機種依存文字周りの重複符号化だったはずですが） ＃http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html ちなみに、-sW -eW の結果の違いは以下の通りです。 Unicode to SJIS-nkf Convertion U+00AC: 0x81CA # NOT SIGN/C2AC U+00AF: 0x8150 # MACRON/C2AF U+00B8: 0x8143 # CEDILLA/C2B8 U+2015: 0x815C # HORIZONTAL BAR/E28095 U+2225: 0x8161 # PARALLEL TO/E288A5 U+FF0D: 0x817C # FULLWIDTH HYPHEN-MINUS/EFBC8D U+FF5E: 0x8160 # FULLWIDTH TILDE/EFBD9E U+FFE0: 0x8191 # FULLWIDTH CENT SIGN/EFBFA0 U+FFE1: 0x8192 # FULLWIDTH POUND SIGN/EFBFA1 U+FFE2: 0x81CA # FULLWIDTH NOT SIGN/EFBFA2 U+FFE3: 0x8150 # FULLWIDTH MACRON/EFBFA3 U+FFE4: 0xFA55 # FULLWIDTH BROKEN BAR/EFBFA4 U+FFE5: 0x818F # FULLWIDTH YEN SIGN/EFBFA5 Unicode to eucJP-nkf Convertion U+00AC: 0xA2CC # NOT SIGN/C2AC U+00AF: 0xA1B1 # MACRON/C2AF U+00B8: 0xA1A4 # CEDILLA/C2B8 U+2015: 0xA1BD # HORIZONTAL BAR/E28095 U+2225: 0xA1C2 # PARALLEL TO/E288A5 U+FF0D: 0xA1DD # FULLWIDTH HYPHEN-MINUS/EFBC8D U+FF5E: 0xA1C1 # FULLWIDTH TILDE/EFBD9E U+FFE0: 0xA1F1 # FULLWIDTH CENT SIGN/EFBFA0 U+FFE1: 0xA1F2 # FULLWIDTH POUND SIGN/EFBFA1 U+FFE2: 0xA2CC # FULLWIDTH NOT SIGN/EFBFA2 U+FFE3: 0xA1B1 # FULLWIDTH MACRON/EFBFA3 U+FFE4: 0xFCFC # FULLWIDTH BROKEN BAR/EFBFA4 U+FFE5: 0xA1EF # FULLWIDTH YEN SIGN/EFBFA5 以上の変換が行われなくなります。 > MultiByteToWideChar には合成文字のためのオプション MB_PRECOMPOSED と > MB_COMPOSITE とがあります。 > どちらかと言えば、このオプションの動作の違いは nkf でも考慮して > おくと何かと便利なのかもしれません。 変換時にNFCをかけるかNFDをかけるか、なのですかね。 nkfでは現在基本的にはNFCもNFDも行っていないので、 MB_PRECOMPOSED も MB_COMPOSITE もセットされていない状態です。 ただ、唯一、--utf8mac-input を指定した時のみ、 MB_PRECOMPOSED相当の処理がある程度行われます。 ＃HFS plusにおける「分解された Unicode 文字」を、 ＃「合成済み Unicode 文字」に変換できる程度 ＃http://developer.apple.com/jp/qa/qa2001/qa1173.html ＃http://developer.apple.com/technotes/tn/tn1150table.html なお、NFC/NFD/NFKC/NFKDを全て実装したい気はありますし、 わたし自身Unicode正規化がほしいとも思っているのですが、 nkfがそれを持つとテーブルの規模が大きすぎるようにも思えて、 まだ実装はしていません。 ＃効率のよい実装方法に悩んでいるのもあります -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
Fork