◀Unicode版開発トップへ
  • 786 PatchUnicode#2478365no
    • 787 Re:PatchUnicode#2478365の是非
    • 788 Re:PatchUnicode#2478365no
      • 789 Re2:PatchUnicode#2478365no
        • 790 Re3:PatchUnicode#2478365no
          • 791 Re4:PatchUnicode#2478365no
            • 792 Re5:PatchUnicode#2478365no
              • 793 Re6:PatchUnicode#2478365no
                • 794 Re7:PatchUnicode#2478365no
                  • 795 Re8:PatchUnicode#2478365no
                    • 796 Re9:PatchUnicode#2478365no
                      • 800 Re10:PatchUnicode#2478365no
                        • 801 Re11:PatchUnicode#2478365no
                          • 808 Re12:PatchUnicode#2478365no
                            • 813 Re13:PatchUnicode#2478365no
                              • 815 Re14:PatchUnicode#2478365no
                                • 829 Re15:PatchUnicode#2478365no
                                  • 830 Re16:PatchUnicode#2478365no
                                    • 832 Re17:PatchUnicode#2478365no
                                      • 833 Re18:PatchUnicode#2478365no
                                        • 834 Re19:PatchUnicode#2478365no
                                        • 835 Re19:PatchUnicode#2478365no
                                          • 836 Re20:PatchUnicode#2478365no
                                  • 831 Re16:PatchUnicode#2478365no
  • [786] PatchUnicode#2478365no ラスティブ 2009年01月23日 17:25

     (文字コード変換)文字として読めないデータを
     テキストで表現するように  PatchUnicode#2478365

    すみません、上記のパッチをどうしようかと迷っています。
    テキストでない何かを読み込んだ時に、
    半角英数字 "FF"とか、/[0-9A-F]{2}/にマッチするものが
    正しく検索できなくなる事などで反対意見があれば、
    却下(DELETE)したいと思っています。

    どうでしょうか、コメントよろしくお願いします。。。
    • [787] Re:PatchUnicode#2478365の是非 ラスティブ 2009年01月23日 17:26

      タイトル打ち込み中に
      えんたーキーで投稿してしまいましたすみません。

      タイトル:
      PatchUnicode#2478365の是非
    • [788] Re:PatchUnicode#2478365no ryoji 2009年01月24日 22:21

      ▼ ラスティブさん
      >  (文字コード変換)文字として読めないデータを
      >  テキストで表現するように  PatchUnicode#2478365

      え、と。自分はこのパッチを適用したときの利点がよくわかってません、すみません。(^^;;;
      • [789] Re2:PatchUnicode#2478365no げんた 2009年01月25日 02:08

        変換できない文字が混入したファイルを開いて保存すると,内容が変わってしまう問題を解決したいと言うことでしょうか.
        それともバイナリ部分も編集できるようにしたいのかな?

        文字コードとして不正なバイト列が混入していることを分かるようにするというのであれば"ffff" + 16進で表現するのではなくてUnicodeの空いている部分にマップするなりして通常の文字とは異なるコードとして扱い,表示時に特殊文字として扱うようなアプローチの方が良いと思います.

        UNICODE上あり得ないコードと言うことでffffなのでしょうけど,外字領域を255文字使ってマップして,表示用のフォントを登録するとか(動的にできるのかな?やり方がちょっと分かりませんが...) 外字領域を避けて全然使っていないところを使おうとするとサロゲートペアになるのかな.(これこそフォントで何とかできるのか不明ですが...)
        • [790] Re3:PatchUnicode#2478365no ラスティブ 2009年01月26日 17:21

          とりあえず。

          U+D800からU+D8FFまでに不正なバイト列
          をマップするようにしてみました。
          使用領域(U+E000からU+F800)のU+F000からU+F0FFまでに
          対応付けるようにもしてみましたが、U+F000からU+F0FF
          までを不正バイト列扱いにするのが惜しまれたので、
          上位サロゲート片で表現するようにしました。

          > え、と。自分はこのパッチを適用したときの利点が
          > よくわかってません、すみません。(^^;;;

          げんたさん方の書き込みあるもので、
          変換できない文字が混入したファイルを開いて保存すると,
          内容が変わってしまう問題をできる範囲(JISとUTF-7以外)
          で解決したいです。それの利点は、UNICODE版では誤って
          読み込むと必ず文字化けするので、
          あんまりないですね・・・。

          情けないことに、
          描画処理の方を変更する自信がないので、
          このまんまではペンディングでしょうか。
          • [791] Re4:PatchUnicode#2478365no ryoji 2009年01月27日 18:31

            ▼ ラスティブさん
            > 変換できない文字が混入したファイルを開いて保存すると,
            > 内容が変わってしまう問題をできる範囲(JISとUTF-7以外)
            > で解決したいです。

            そういう要望もあった(>>dev:5040)ので、できるならそうするのがいいんじゃないでしょうか。
            今回のパッチを適用したsakuraで、とあるzipファイルをSJISで開いて中のファイル名を変更して保存、解凍してみたらちゃんと変更後のファイル名で抽出されました。(^^;;;
            #確か前回のパッチではうまくいかなかった

            > 情けないことに、
            > 描画処理の方を変更する自信がないので、
            > このまんまではペンディングでしょうか。

            不正文字を'〓'で表示する(色はコントロールコード指定色)ようにしたパッチを作ってみました。(PatchUnicode#2478365に追加)
            こんなイメージでしょうか?
            • [792] Re5:PatchUnicode#2478365no ryoji 2009年01月27日 19:03

              バイナリ絡みで気づいたんですが、
              奇数サイズのファイルをUnicodeで開くと末尾1バイトを捨ててしまうようです。
              情報が消えるよりはダミーで1バイト(0x00?)追加して読むほうがいいんでしょうかね?
              • [793] Re6:PatchUnicode#2478365no ラスティブ 2009年01月28日 14:13

                ▼ ryoji さん
                > 不正文字を'〓'で表示する
                > (色はコントロールコード指定色)ようにしたパッチを
                > 作ってみました。(PatchUnicode#2478365に追加)
                > こんなイメージでしょうか?

                フォローありがとうございます。
                良い感じじゃないですかー(嬉)
                イメージはそんな感じでO.K.です。

                > 奇数サイズのファイルをUnicodeで開くと
                > 末尾1バイトを捨ててしまうようです。
                > 情報が消えるよりはダミーで1バイト(0x00?)
                > 追加して読むほうがいいんでしょうかね?

                いま、CUnicode.cpp を変更しているのですが、
                読み込みソースを const char* 型に指定して、
                最後の半端な一バイトは一応、
                U+D800からU+D8FFまでに保存するようにしています。
                (いまは苦手なバグとり中です)

                File -> CNativeW -> CMemory と型変換されている
                場合のこと考えると、読みこんだファイルのでーたを
                CMemoryに保管させる作業をするよりは、
                ダミーで1バイト追加のほうがめんどくなさそうなので、
                とりあえずその方向でどうでしょう。
                • [794] Re7:PatchUnicode#2478365no ryoji 2009年01月29日 16:46

                  ▼ ラスティブさん
                  > いま、CUnicode.cpp を変更しているのですが、
                  > 読み込みソースを const char* 型に指定して、
                  > 最後の半端な一バイトは一応、
                  > U+D800からU+D8FFまでに保存するようにしています。

                  あれれ?
                  別の文字コードからの読み書きで内部Unicodeに格納する際に変換不可文字をサロゲート片にマップするのは良いとして、Unicodeの読み書きでまで未定義文字をサロゲート片にマップしてます?
                  Unicode未定義文字は未定義文字として、無変換のまま内部Unicodeメモリに置くほうがいいんじゃないでしょうか。
                  例えば、現サクラでは未定義扱いだけどUnicode 5.1では定義済みの麻雀牌(U+1F000-U+1F02F)1文字が4個の不正文字に分離してエディタ画面に表示されるのは不自然だし(*1)、いろいろ扱いにくくなるんじゃないですか(*2)?なんか、こういう特殊扱いはバグの温床になりそうな、やな予感がするデス。(^^;;;

                  (*1) メモ帳で開いたら1文字なのにサクラで開くと4文字、とか。
                  (*2) クリップボードへのコピーでは4個の不正文字を1文字の麻雀牌に戻しておかないと正しいコードでメモ帳に貼り付かない、など、さまざまな処理でいちいち変換が必要になるかも。

                  ひょっとして、無変換だと奇数バイトサイズのファイルを同じサイズで保存できないから、という理由でそういう処理にしたのでしょうか?。でも、付加的な1バイトが増加するだけで、もともとのデータが保持されるなら、それは目を瞑ってもいいかなと思うんですけど。ANSI版だったらUnicode読み書きではバイナリは保持されなかったわけで、それと比べれば...、テキストの操作性に違和感が現われるまでのことをしてバイナリサイズ保持にこだわることはないと思います。

                  あと、'〓'表示にするのはせいぜい「非文字(Noncharacters)」として定義された66文字(*3)とサロゲート片だけにしておいて、未定義文字は従来どおり、あるがままの文字描画に任せたほうがいいかな、と思いました。麻雀牌がちゃんと麻雀牌として表示されるかどうかは別として。他エディタでもそうしてるような気がします。

                  (*3) 第00面から第16面までの各面の最後の2ポイント(U+nFFFE,U+nFFFF)およびU+FDD0-U+FDEF。
                  http://unicode.org/versions/Unicode4.0.0/ch15.pdf
                  • [795] Re8:PatchUnicode#2478365no ラスティブ 2009年01月30日 13:15

                    ▼ ryojiさん
                    > あれれ?
                    > 別の文字コードからの読み書きで内部Unicodeに格納する際に変換不可文字を
                    > サロゲート片にマップするのは良いとして、Unicodeの読み書きでまで
                    > 未定義文字をサロゲート片にマップしてます?

                    > Unicode未定義文字は未定義文字として、無変換のまま
                    > 内部Unicodeメモリに置くほうがいいんじゃないでしょうか。

                    たとえば、以下のような文字列がUTF-7と判別されないために
                    _CheckUtf16Charで、未定義コードポイントをCHARSET_BINARYにしていました。。。

                    「d+hG5ugj9r46NRQqEZMyppcHgFCNCjOO9VCdsCM
                    s6tjoJ6mkE66befz58aqNKRHQ」

                    (これは単なる BASE64文字列で、ASCII7 と判定されることを
                     期待してます。)

                    Blocks.txt は頻繁に変わらないものと頭で思い込んでいたのですが、
                    実際はちょくちょく変るんですね^^;
                    Unicode のバージョンが上がるたびに Block.txt の情報を反映させる
                    必要があるのも、一応それ用のプログラムは用意してあるのですが、
                    うっかり反映し忘れたときのことを考えると「・・・」ですね。

                    http://sakura.qp.land.to/?Develop%2F9

                    どうしよう。。。
                    • [796] Re9:PatchUnicode#2478365no ryoji 2009年01月30日 16:41

                      ▼ ラスティブさん
                      > たとえば、以下のような文字列がUTF-7と判別されないために
                      > _CheckUtf16Charで、未定義コードポイントをCHARSET_BINARYにしていました。。。

                      ■文字コード判別
                      今の_CheckUtf16Char関数をそのまま継続して利用すればいいと思います。

                      ■不正コード表示
                      不正コード判定関数(非文字コードポイント&サロゲート片)を新たに作るなりしてそれを利用すればいいと思います。

                      ■内部保持コード
                      他コード指定のファイル読み書きでは変換不可文字(ファイル)はサロゲート片(メモリ)に変換して出し入れすればいいと思います。
                      Unicode指定のファイル読み書きでは未定義文字でも何でも無変換で出し入れすればいいと思います。

                      それで何か問題ありますか?

                      【追記】
                      現状パッチ(ChgCodeConv20090128__r1520_uni.patch)だと、CUnicode::_UnicodeToUnicode_in()がUniToUni_in()を呼び出したときにバッファオーバーラン(nDstLen >= nSrcLen)でクラッシュする危険がありそうです。
                      • [800] Re10:PatchUnicode#2478365no ラスティブ 2009年02月03日 16:46

                        > ■不正コード表示
                        > 不正コード判定関数(非文字コードポイント&サロゲート片)を新たに作るなりして
                        > それを利用すればいいと思います。
                        >
                        > ■内部保持コード
                        > 他コード指定のファイル読み書きでは変換不可文字(ファイル)は
                        > サロゲート片(メモリ)に変換して出し入れすればいいと思います。
                        > Unicode指定のファイル読み書きでは未定義文字でも何でも無変換で
                        > 出し入れすればいいと思います。

                        ・_CheckUtf16,CheckUtf8,CheckUtf7BPartに引数を追加して、変換のときは、予約文字を通常の文字として扱うように変更しました(^^
                        ・Unicode で1バイトかける問題で、ダミー1バイトを追加するだけでは不十分(データが変化してしまう)なので、CFileLoad::GetNextLineCharCode を書き直して修正しました(^^

                        PatchUnicode #2478365
                        • [801] Re11:PatchUnicode#2478365no ryoji 2009年02月04日 01:45

                          ちょっと今はじっくり考える余力が無いので、ちらっと見て思った点だけ書いておきます。
                          #思い違いがあったらその点はご容赦ください(^^;

                          ■Unicode(BE/LE)指定でのファイル読み込み時の内部保持コード
                          ファイル内の非文字とサロゲート片(それと奇数バイトファイルの末尾1バイト)については相変わらずバイト単位に分離して別のサロゲート片(U+D800-D8FF)へと変換保持しているようですが、これも無変換で持つという別の選択肢があると思います。どっちがより良いのかちょっと判断がつきません。どちらでも良いとも言えますけど。(^^;;;
                          自分が独断で決めてしまっていいのなら、下記理由でえいや、と無変換で保持の方式にしてしまうと思いますが...

                          ・クリップボード、ウィンドウメッセージ、パイプなど他アプリやDLLとのやりとりでも余計な心配をせず無変換のUTF-16のまま相互にやりとりできる(現パッチの方式でデータ交換時に変換が必須になってしまうケースが本当にあるかというと特には思いつかないけれど、無変換保持の方式のほうが後顧の憂いは無い)

                          ・上記変換を実施する利点はUnicode読み書きでもサイズ増加を伴わないバイナリ非破壊ファイル保存ができることだけだと思われるが、サイズが変わらないことにさほどこだわる必要はない気がする(無変換保持方式では1バイト増えるにしても元のバイナリ部分は保持されるわけでANSI版よりは良好な結果が得られる)

                          この件については、他の人の意見も考慮して決めたほうがいいんじゃないかと思います。
                          皆さん、いかがでしょう?
                          げんたさんは、いかが?

                          ■キャレット位置の文字コード表示
                          現状、U+D800-D8FFの内部コードをu0000-00FFとしてステータスバーに表示してますね(これも上記の内部保持コード変換を採用することが前提になってますが)。
                          u0000-00FFには別の文字割り当てがあるので、別の表記を考えたほうがいいと思います。

                          【前回追記したバッファオーバーランの懸念について】
                          nSrcLenがバイトサイズで、nDstLenがwchar_t単位の文字数だったら既に安全なサイズ(2倍)を確保してたことになるのかな?
                          すみません、どうだったかよく覚えてませんが、ここは「オーバーランが発生しない範囲の最少サイズ」に抑えておいてください。
                          • [808] Re12:PatchUnicode#2478365no ラスティブ 2009年02月07日 17:07

                            コメントが付きにくそうなので、以下の修正をしたパッチを
                            PatchUnicode #2478365 にアップしました

                            1. Unicodeの場合は、codecheckerを使わず、そのまま無変換のデータを
                             保管するようにしました。半端な1バイトが見つかった場合は、
                             ダミー文字'\0'を追加して、U+0000 から U+00FFにマップするように
                             変更しました(ここはちょっと不安)
                            2. U+D800からU+D8FFに乗せられたバイナリ値は、ステータスバーに?XXと表示する
                             ように変更しました。
                            • [813] Re13:PatchUnicode#2478365no uchi 2009年02月10日 00:29

                              ▼ ラスティブさん
                              > コメントが付きにくそうなので、以下の修正をしたパッチを
                              > PatchUnicode #2478365 にアップしました
                              >
                              > 1. Unicodeの場合は、codecheckerを使わず、そのまま無変換のデータを
                              >  保管するようにしました。半端な1バイトが見つかった場合は、
                              >  ダミー文字'\0'を追加して、U+0000 から U+00FFにマップするように
                              >  変更しました(ここはちょっと不安)
                              > 2. U+D800からU+D8FFに乗せられたバイナリ値は、ステータスバーに?XXと表示する
                              >  ように変更しました。

                              要望を出したuchiです。
                              パッチを使ってみました。
                              気付いた点(気になった点)を以下に記します。
                              1. UnicodeBEでの読み書きで、2バイトワードのhigh byte と low byte の入れ替えが行われていない。
                              2. NEC選定IBM拡張文字(Sjisでed40~eeec)等が未定義文字となっている。(1対多対応だから仕方がない?)
                              3. Unicodeの時 U+2FFFEが2文字に分解されて表示されている。
                              4. Unicodeの時 単独のU+D800~U+D8FFがコード表示で?xxで表示される。(書き込みでファイルは壊れませんでした)
                              5. 1バイト文字なので全角幅ではなく半角幅で表示してほしい。(要望)

                              1.2.以外は気にはなるがそんな物かというレベルです。
                              これがうまく動作すれば、メインエディタをunicode版に移行できそうです。

                              よろしくお願いします。
                              • [815] Re14:PatchUnicode#2478365no Uchi 2009年02月10日 21:07

                                ラスティブさんの
                                ChgCodeConv20090209__r1524_uni
                                を試して見ました。
                                UncodeBE ですが、読み込みはOkでした。
                                書き込みは、修正されていませんでした。
                                U+D800~U+D8FFはちゃんと表示されていました。

                                以上報告だけさせていただきます。
                                • [829] Re15:PatchUnicode#2478365no ラスティブ 2009年02月13日 11:31

                                  以下の理由で、パッチをロールバックしました(汗

                                  ・NICODEとUNICODEBEだけ無変換で保持しても、SJISやEUC、UTF8は変換して保持するため、内部から外部へコードを持ち出すときや外部から内部へコードを持ち込むときの変換処理は欠かせない。UNICODEとUNICODEBEを特別扱いしてもそれは同じなので、いっそのこと特別扱いしない方がやりやすい。(バイナリ文字を半角で表示させるために、CNativeW::GetKetaOfCharで現在の文字コードを取得するという操作などが、特別扱いしない場合はなくてもよい。)


                                  前回(20090203版)からの変更:

                                  1. Clipboard::GetText, Clipboard::SetText, Command_INSTEXT,
                                   マクロの F_GETSELECTED, F_GETLINESTR に
                                   内部コード(U+D800からU+D8FFまでにバイナリを乗せて表現する形式)
                                   <->外部コード(普通のUTF-16LE)の変換処理を施しました。

                                  2. 1バイトのバイナリを表現するときに?XXという表記を使用するように
                                   変更しました。

                                  3. U+D800からU+D8FFまでに乗せられている1バイトデータを、
                                   半角で表示するようにしました。


                                  気になる点:

                                   GetSelectedString で取得したバイナリ混在テキストを
                                  InsText でエディタ側に戻したら、データは変わらないけど
                                  バイナリ扱いだった隣り合った2バイトが結合されて、
                                  文字として表示されたりする。
                                  データの内容は変わらないから良しとしましょうか、
                                  どうでしょうか。


                                  -----
                                  ▼ Uchi さん
                                  1. UnicodeBEでの読み書きで、2バイトワードのhigh byte と low byte の入れ替えが行われていない。
                                  直しました ^^

                                  2. NEC選定IBM拡張文字(Sjisでed40~eeec)等が未定義文字となっている。(1対多対応だから仕方がない?)
                                  1対1対応を維持するため、ここは直していません。^^;;;

                                  3. Unicodeの時 U+2FFFEが2文字に分解されて表示されている。
                                  U+2FFFE が Noncharacter のため、バイナリとして扱っています。
                                  (で、あっていますよね。。。少し不安です。)

                                  4. Unicodeの時 単独のU+D800~U+D8FFがコード表示で?xxで表示される。(書き込みでファイルは壊れませんでした)
                                  直しました ^^

                                  5. 1バイト文字なので全角幅ではなく半角幅で表示してほしい。(要望)
                                  CNativeW::GetKetaOfChar をいじって、半角で表示するようにしました。
                                  • [830] Re16:PatchUnicode#2478365no ryoji 2009年02月13日 19:21

                                    ▼ ラスティブさん
                                    > SJISやEUC、UTF8は変換して保持するため、内部から外部へコードを持ち出すときや外部から内部へコードを持ち込むときの変換処理は欠かせない。

                                    すみませんが、この部分がどういう意味か、具体例で教えてください。

                                    プログラム間の文字のやりとりは基本的にUNICODEを用いることになるはずで、元のコードへ逆変換して渡す、というようなことはほとんど不要と思うのですが。
                                    ANSI版アプリとのやりとりでSJISが壊れる程度なら気にしなくていいと思います。というか、その程度のことを実現するために影響範囲が爆発的に増えるのならやめたほうがいいんじゃないですか?
                                    • [832] Re17:PatchUnicode#2478365no ラスティブ 2009年02月14日 13:00

                                      > > ▼ ラスティブさん
                                      > > SJISやEUC、UTF8は変換して保持するため、
                                      > > 内部から外部へコードを持ち出すときや
                                      > > 外部から内部へコードを持ち込むときの
                                      > > 変換処理は欠かせない。
                                      >
                                      > すみませんが、この部分がどういう意味か、具体例で教えてください。

                                      バイナリデータが混在したテキストにおいて、
                                      内部では、バイナリの部分をU+D800からU+D8FFにエンコードしています。
                                      それを外へ持ち出すときは、U+D800からU+D8FFを0x00から0xFFに
                                      戻す処理が要るんじゃないかなと思います。
                                      たとえば、ビュー内では、ステータスバーに"?00","?01","?02"と
                                      表示されるバイト列(データとしてはU+D800,U+D801,U+D802)を、
                                      クリップボードに保管するときは、データを0x00,0x01,0x02に
                                      戻しておく、他には、マクロでGetSelectedString,GetLineStrで
                                      ビューの文字列が外部へ持ち出される時も、0x01,0x02,0x03に
                                      戻しておく処理が必要です。その逆で、マクロでInsTextを
                                      実行するときは、UNICODEとして読めない文字をU+D800からU+D8FFに
                                      エンコードしておく処理が必要になる(文字コードがSJIS,EUC,UTF8の場合)
                                      と思うので、その処理をCommand_INSTEXTに記述しておきました。

                                      その変換の過程で、隣り合ったバイトデータが結合されて
                                      UNICODE文字になるという問題が。。。

                                      こんな説明でよろしいでしょうか。。。
                                      • [833] Re18:PatchUnicode#2478365no ryoji 2009年02月14日 16:01

                                        ファイル/メモリどっちの入出力でも
                                        ・UTF-16は無変換
                                        ・他コードはバイナリ部をUTF-16のU+D800-D8FFに変換
                                        でいいと思います。

                                        ■UNICODE無変換方式(僕の案です)

                                        ●ファイル入出力
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        ファイル(SJIS): 82 A0 EC FD 82 A0
                                        ※中央2バイトがバイナリで左右2バイトは'あ'

                                        ●ステータスバー表示
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        Unicode表示: u3042 ud8ec ud8fd u3042
                                        SJIS表示: 82a0 ?ec ?fd 82a0

                                        ●クリップボードのデータ入出力
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        CF-UNICODETEXT: 42 30 EC D8 FD D8 42 30
                                        CF-TEXT: 82 A0 EC FD 82 A0


                                        ■現状のパッチ(ChgCodeConv20090212b__r1524_uni)
                                        上記と同じファイルで以下のようになります。

                                        ●ファイル入出力
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        ファイル(SJIS): 82 A0 EC FD 82 A0

                                        ●ステータスバー表示
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        Unicode表示: u3042 ?ec ?fd u3042 ★
                                        SJIS表示: 82a0 ?ec ?fd 82a0

                                        ●クリップボードのデータ入出力
                                        内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                        CF-UNICODETEXT: 42 30 EC FD 42 30 ★
                                        CF-TEXT: 82 A0 3F 82 A0 ★

                                        ★の部分がよくないです。
                                        内部メモリとCF-UNICODETEXTのコードが違っているのでビューからクリップボードにコピーして検索画面の検索条件に貼り付けた文字列はもとの文字列にヒットしません。
                                        (範囲選択して自動的に検索条件に入力された場合には同じコードになってヒットします)
                                        SJISファイルとCF-TEXTは同じSJISなのに別のコードに変化してしまいました。
                                        ※CF-TEXTが変化してしまうようでは、「外へ持ち出すときは変換処理は欠かせない」は、まるで意味が無いですね。
                                        • [834] Re19:PatchUnicode#2478365no ryoji 2009年02月14日 19:55

                                          すみません。m(__)m
                                          自己レスにしようとして、修正にしてしまいました。(>>unicode:833)

                                          以下は単なる修正後の文の引用です。orz.

                                          > ファイル/メモリどっちの入出力でも
                                          > ・UTF-16は無変換
                                          > ・他コードはバイナリ部をUTF-16のU+D800-D8FFに変換
                                          > でいいと思います。
                                          >
                                          > ■UNICODE無変換方式(僕の案です)
                                          >
                                          > ●ファイル入出力
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > ファイル(SJIS): 82 A0 EC FD 82 A0
                                          > ※中央2バイトがバイナリで左右2バイトは'あ'
                                          >
                                          > ●ステータスバー表示
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > Unicode表示: u3042 ud8ec ud8fd u3042
                                          > SJIS表示: 82a0 ?ec ?fd 82a0
                                          >
                                          > ●クリップボードのデータ入出力
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > CF-UNICODETEXT: 42 30 EC D8 FD D8 42 30
                                          > CF-TEXT: 82 A0 EC FD 82 A0
                                          >
                                          >
                                          > ■現状のパッチ(ChgCodeConv20090212b__r1524_uni)
                                          > 上記と同じファイルで以下のようになります。
                                          >
                                          > ●ファイル入出力
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > ファイル(SJIS): 82 A0 EC FD 82 A0
                                          >
                                          > ●ステータスバー表示
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > Unicode表示: u3042 ?ec ?fd u3042 ★
                                          > SJIS表示: 82a0 ?ec ?fd 82a0
                                          >
                                          > ●クリップボードのデータ入出力
                                          > 内部メモリ(UTF-16): 42 30 EC D8 FD D8 42 30
                                          > CF-UNICODETEXT: 42 30 EC FD 42 30 ★
                                          > CF-TEXT: 82 A0 3F 82 A0 ★
                                          >
                                          > ★の部分がよくないです。
                                          > 内部メモリとCF-UNICODETEXTのコードが違っているのでビューからクリップボードにコピーして検索画面の検索条件に貼り付けた文字列はもとの文字列にヒットしません。
                                          > (範囲選択して自動的に検索条件に入力された場合には同じコードになってヒットします)
                                          > SJISファイルとCF-TEXTは同じSJISなのに別のコードに変化してしまいました。
                                          > ※CF-TEXTが変化してしまうようでは、「外へ持ち出すときは変換処理は欠かせない」は、まるで意味が無いですね。
                                        • [835] Re19:PatchUnicode#2478365no ryoji 2009年02月14日 20:08

                                          > CF-TEXT: 82 A0 3F 82 A0 ★
                                          (snip)
                                          > SJISファイルとCF-TEXTは同じSJISなのに別のコードに変化してしまいました。

                                          理想はCF-TEXTもSJISファイルと同じになることですが、当面はSJISでのメモリ経由インターフェースでバイナリ部分は化けてもいいと思います。
                                          ※相手がCF-UNICODETEXTをサポートしていればCF-TEXTは無視されるだけだし、仮にCF-TEXTで受け取ってもバイナリ部は与えた通りに受け取られる保証もない。
                                          今回の、ファイルのバイナリ部が化けないようにするのと同じで、おいおい、やりたい人がやればいい(そういう人がいなければ放置していい)レベルのものだと思います。

                                          UTF-16でのファイル入出力を無変換にしていただければ(UTF-16でのメモリ経由も従来のまま手を加えずに使えるはずなので)、ラスティブさんには当初の目的であるファイル入出力でバイナリ保持する部分とステータスバー表示あたりまで作っていただくだけで、メモリ経由のインターフェースまで手出しする必要は無くなると思います。

                                          外部コード(通常UTF-16)⇔内部コード(変形UTF-16)などという小手先のごまかし変換を持ち込むからプログラム中に散在するあらゆる場所で「変換処理が欠かせない」になってしまうのであって、無変換なら「変換処理が必要になることは滅多にない」で済むのです。

                                          特殊なのは、他コード⇔UTF-16変換時にバイナリをU+D800-D8FFに変換する処理だけで、他コードから変換されたU+D800-D8FFは他コードに変換するとき以外は純粋なUTF-16値として扱ってしまえば良い、です。
                                          多くのアプリで、他コード⇒UTF-16変換時にバイナリ部を独自変換で'?'などの特定の文字に変換してそのまま'?'の文字として扱うのと同様、上記変換でUTF-16値(U+D800-D8FF)に変換してしまうことに決めているのですから。
                                          • [836] Re20:PatchUnicode#2478365no ラスティブ 2009年02月15日 12:10

                                            > 内部独自コード化(UTF-16相手にも変換が必要)には反対です。
                                            > 今の作りでは無謀と思います。

                                            ご尤もです。
                                            厳密には DLL にまで変換して参照させることになるので、
                                            自分ではできないですね・・・。
                                            今のままでは GetSelectedString で得た文字列を
                                            そのあとすぐに InsText で挿入したら、
                                            文字化けが起こりますし。。。これではいかんですね。

                                            > 多くのアプリで、他コード⇒UTF-16変換時にバイナリ部を
                                            > 独自変換で'?'などの特定の文字に変換してそのまま'?'の文字として
                                            > 扱うのと同様、上記変換でUTF-16値(U+D800-D8FF)に変換してしまう
                                            > ことに決めている

                                            単にバイナリを開いて不意に保存してしまった時の
                                            安全性確保のためのパッチだということで。

                                            パッチをアップしました。
                                            PatchUnicode #2478365
                                  • [831] Re16:PatchUnicode#2478365no ryoji 2009年02月13日 19:42

                                    ▼ ラスティブさん
                                    > 1. Clipboard::GetText, Clipboard::SetText, Command_INSTEXT,
                                    >  マクロの F_GETSELECTED, F_GETLINESTR に
                                    >  内部コード(U+D800からU+D8FFまでにバイナリを乗せて表現する形式)
                                    >  <->外部コード(普通のUTF-16LE)の変換処理を施しました。

                                    例えば、ビューからクリップボードにコピーして検索画面の検索条件に貼り付けた文字と、カーソル位置から自動的に拾って検索条件に入力された文字は同じになりますか?拾ったもとの場所にちゃんとヒットしますか?