◀Unicode版開発トップへ
  • 872 ラスティブ
    • 873 Re:PatchUnicode#2478365 の状況
      • 874 Re2:PatchUnicode#2478365 の状況
        • 876 Re3:PatchUnicode#2478365 の状況

  • [872] ラスティブ PatchUnicode#2478365 の状況 2009年03月07日 17:01

    前回からの変更：

    １．CNativeW::GetKetaOfCharとCTextMetrics::GenerateDxArrayに、
    　ファイル文字コードによって切り分ける処理を追加しました。
    　（UTF-16LE/BEのときに、0xDC00から0xDCFFまでを全角で表示するため。）

    ２．UTF-7読み込みで、バイナリを読み込むと無限ループになるバグを修正しました。

    • [873] Re:PatchUnicode#2478365 の状況 ラスティブ 2009年03月07日 17:03

      題名が逆になってしまいました。。。。。。。。。。。

      • [874] Re2:PatchUnicode#2478365 の状況 ラスティブ 2009年03月07日 20:15

        >>835
        > ▼ ryoji さん
        > 特殊なのは、他コード⇔UTF-16変換時にバイナリを
        > U+D800-D8FFに変換する処理だけで、
        > 他コードから変換されたU+D800-D8FFは他コードに
        > 変換するとき以外は純粋なUTF-16値として
        > 扱ってしまえば良い、です。
        > 多くのアプリで、他コード⇒UTF-16変換時に
        > バイナリ部を独自変換で'?'などの特定の文字に変換して
        > そのまま'?'の文字として扱うのと同様、上記変換で
        > UTF-16値（U+D800-D8FF）に変換してしまうことに
        > 決めているのですから。

        UTF-16で文字化けに気付かず保存してしまう人
        はいないと思いますが、上記の現在ではU+DC00からU+DCFFを
        純粋なUTF-16として扱ってしまえばよいという考え方を、
        UTF-16 に持ち込むのはだめですか？
        そうすると、CMemory::GetKetaOfChar と
        CTextMetrics::GenerateDxArray にある処理で、
        現在のファイル文字コードで切り分ける処理をしなくても
        良くなるのですが。。。

        • [876] Re3:PatchUnicode#2478365 の状況 ryoji 2009年03月08日 00:38

          ▼ ラスティブさん
          > そうすると、CMemory::GetKetaOfChar と
          > CTextMetrics::GenerateDxArray にある処理で、
          > 現在のファイル文字コードで切り分ける処理をしなくても
          > 良くなるのですが。。。

          U+DC00-DCFFは文字コードに関係なく一律に１桁（半角）表示でいいんじゃないでしょうか？
          UTF-16LE/BEで開いているときはU+D800-D8FFと同じ扱いにしてしまっていいと思うのですが。
          ＃コードも動作確認も未実施の浅い考えでしかコメントできてません... (^^;

          あと、別件ですが、このパッチが導入されるとメニューの[変換]-[文字変換]にある、現状では未実装の変換（SJISがらみ）も動くようにできるんでしょうかね？
          自分はこれらの変換の仕様をよく理解できていないです。特に使う機会も無かったし。これらの変換は今のところANSI版でファイルをSJIS読み込み（無変換読み込み）したときにだけ正しく機能する、と想像してるのですが、それであってるのかな？