◀ANSI版開発トップへ
  • 4575 今後のアイディア1
    • 4595 Re:今後のアイディア1
      • 4669 Re2:今後のアイディア1
        • 4715 Unicode の対応について
          • 4716 RE: Unicode の対応について
            • 4717 Re2: Unicode の対応について
              • 4719 Re3: Unicode の対応について
                • 4722 Re4: Unicode の対応について
                  • 4726 Re5: Unicode の対応について
                    • 4727 Re6: Unicode の対応について
                      • 4729 Re7: Unicode の対応について
                        • 4737 Re8: Unicode の対応について
                        • 4738 Re8: Unicode の対応について
                          • 4744 Re9: Unicode の対応について
                        • 4742 Re8: Unicode の対応について
            • 4718 Re2: Unicode の対応について
              • 4723 Re3: Unicode の対応について
                • 4724 Re4: Unicode の対応について
                  • 4725 Re5: Unicode の対応について
                    • 4728 Re6: Unicode の対応について
                      • 4731 Re7: Unicode の対応について
                        • 4734 Re8: Unicode の対応について
          • 4758 RE: Unicode の対応について
  • [4575] 今後のアイディア1 げんた 2006年09月09日 21:23

    基本部分について今後どう持っていったらよいのかチラシの裏(笑)で整理.

    現在1行1データの構造なので,改段のない文章を折り返しで書くと激しく遅くなる.
    1行の制限を取っ払ってほしいとの意見があったが,そんなわけで実際上取っ払ったところでまともに動かない.
    ↓
    1行を複数ブロックに分割する場合,検索が問題になる.
    通常検索: 境界をまたぐ文字列比較の導入が必要
    bregex: サポートされていない
    メモリ上で不連続でも検索できるのは(全略)さんのJRegexとboost::regexくらいか?
    JRegexを本体に取り込んでしまう(90KB程度?)案はどうか.(DFA/BMサポート版が未評価)
    正規表現がオプションでなく内蔵だと,他の機能で正規表現が使えるので楽.

    複数ブロック管理を考えたらラスティブさんのCMemをうまく使っていけるのかな?
    逆に今の構造は,1行が短いときにオーバーヘッドが大きすぎる気がする.
    すぐに表示してバックグラウンドで読み込み継続できるようにするには
    画面表示の折りたたみ(部分非表示)もしたい.
    折り返しをウィンドウ幅に追従させても速度低下しないようにしたい→レイアウトの部分再構築ができるように.

    Unicodeサポートするには
    * 内部UTF-8で表示時に変換というアイディアは速度的に不利だろうか.今もSJIS→UnicodeってWindowsが変換してるんでしょ?
    * 設定ファイル等はUTF-8の方が良さそうな気がする.
    • [4595] Re:今後のアイディア1 ラスティブ 2006年09月26日 01:03

      ▼ げんたさん
      > 複数ブロック管理を考えたらラスティブさんの
      > CMemをうまく使っていけるのかな?

       しかし1行10万桁を超えるようなクレイジィなぶつを
      扱うことより,1行200桁未満のテキスト文書を
      扱うことのほうが圧倒的に多く,
      1行を複数ブロックで管理させると,
      短い行を多く扱う場合のメモリ使用量の損失が
      大きくなるのです….
      分割管理するなら1行の制限を取っ払って
      ギャップベクタ方式を導入するするくらいしないと,
      もとが取れないなぁと気づいてしまいまして,
      放置気味です.

      > 内部UTF-8で表示時に変換というアイディアは
      > 速度的に不利だろうか.

       一筋縄じゃ失敗する予感がします.
      複数ブロック管理をするにしてもそうですが,
      LineColmnToIndex と LineIndexToColmn が
      もっと高速に処理できるよう作り変える必要が
      あるような気が.
      • [4669] Re2:今後のアイディア1 ラスティブ 2007年01月29日 00:23

        なんか自分が書いたレスを見てフォローしたくなりました(汗

        “Unicode をサポートするには” のところについてですが、
        設定ファイル等を UTF-8 にするのは、データ落ちに
        強くなるので賛成です。内部コードを UTF-8 に
        するのは、もうすでに一部 TCHAR 化されてる現状を鑑みると、
        なんか、TCHAR になってるところをまた char に直して
        いかないといけないので躊躇してしまいますけれど、
        正規表現との相性はいいのかもしれません。
        Migemo の dll の方も、UTF-8 に対応予定のようでした。

        UTF-8 で書かれた文字列 “あい”の連続を検索。
        (?:(?:\xE3\x81\x82)|(?:\xE3\x81\x84))+

        ただ、このまんまじゃマッチしないです…(がっかり)
        間違っていたらご指摘ください。

        “行の複数ブロック管理”については、
        正規表現ライブラリとの互換性を保つために、
        入力された正規表現を解釈しながら各ブロック
        ごとに内部的な正規表現(←これは従来の
        正規表現ライブラリ用)を随時生成して実行させる・・・
        みたいなことをやってくれるコードを書き加えるか、
        思い切って boost::regex で実装しなおすかする
        必要がありそうで、大変難しそうです。

        とりあえずは、SJIS → Unicode → SJIS 変換で
        データが元に戻る仕組みを作り始めることと、
        各種 SJIS 依存コードを、UTF-8(?)で
        実行できるように作り変えること、
        あたりからでしょうか (^^

        UTF-16 ⇔ (UTF-32 ⇔) UTF-8 変換が
        ボトルネックになりそうです。
        • [4715] Unicode の対応について ラスティブ 2007年03月10日 00:01

           Unicode についていろいろ調べていると、
          なんだか長く重い芋づるを抜いてるような感覚に陥ります…(x_x)

          > とりあえずは、SJIS → Unicode → SJIS 変換で
          > データが元に戻る仕組み

           これについては、API関数 ::WideCharToMultiByte の
          特殊な変換(相互変換できない変換)を抑制することとで
          達成できることを前提に、一文字変換ルーチン集を作成中です。
          SJIS-2004 の変換表を組み込むことも考えましたけれど、
          Windows Vista が持ってる変換表と一致しているかどうかを
          確認する環境が無いので、やっぱ手が出せませんでした…(しょぼーん)。

           一方で、変換の際に必要となる Unicode 版の一文字認識ルーチンを、
          どこまで実装すればいいのか…、躊躇しています。
          「内部 Unicode 化」と謳うなら、このルーチンで
          合成文字をすべて捕らえる必要があるんですけれど、
          下は Win95 まで対応しているエディタのことを考えると、
          API関数 ::TextOut を完全 Unicode 化しない限り、
          あんまり意義が見出せませんし、そこまでできる自信ナシ・・・。
           そこで、(もかさん作のワイドキャラクタ版で検証されていた
          ことなのかも知れません…)Unicode の表現方法のうち、
          サロゲートペアと、JIS X 0213:2004 で導入された合成文字だけ
          認識できるところまで実装(ISO 10646-1 Level1)するのがいいかと
          思うのですけれど…、それでも、::TextOut は
          ISO-10646-1 Level1 未満なのが気にはなりますが…。
          それとも、::TextOut で出力できる範囲に狭めるのがいいんでしょうか。

          参考 URL: http://www.linux.or.jp/JM/html/LDP_man-pages/man7/unicode.7.html
          ISO-10646-1 のレベルについて記述がありました。
          • [4716] RE: Unicode の対応について げんた 2007年03月10日 01:20

            >API関数 ::TextOut を完全 Unicode 化しない限り、あんまり意義が見出せません
            やっぱり,UNICODE対応ですかねぇ...UnicodeとSJISの2本立てで両方メンテナンスできるとは思えず,かといってWindows 95/98/MEを切り捨てるのもはばかられます.せっかくのワイドキャラクタ版も無視するような形になってしまっています.(Unicodeで動く正規表現ライブラリがその当時は無かったこともありますけど...)
            個人的には文字列の最初から読まないと2バイト文字判定ができないSJISとはおさらばしたいですが...

            あとふぁんくらぶで指摘されていたようにノンリグレッション試験を効率よく行えないので大規模修正に踏み切れず保守的な対応になりがちです.(そういえば,CMemもすっかり忘れていました.)

            この辺も含めてアイディアがあればよろしくお願いします.
            • [4717] Re2: Unicode の対応について ラスティブ 2007年03月10日 14:01

              > UnicodeとSJISの2本立てで両方メンテナンスできるとは思えず,
              > かといってWindows 95/98/MEを切り捨てるのもはばかられます.
              > せっかくのワイドキャラクタ版も無視するような形になってしまっています.

              ワイドキャラクタ版については、>>data:2969 で
              みくさんが提案された手順が堅実じゃないかと感じることがあって、
              手を出してません(汗)
              既存コードを最大限に利用できる Unicode 系文字コードは、
              UTF-8 かなと感じるのも、理由の一つです。
              正規表現ライブラリ(.dll)と、C/Migemo ライブラリ(.dll)は、
              どの道すげ替えないといけないようで…。


              > ノンリグレッション試験を効率よく行えないので
              > 大規模修正に踏み切れず保守的な対応になりがち

              外部ライブラリや表示系などの、
              UNICODE対応が遅くなりそうな部位のために、
              UTF-8 か SJIS かを動的に選択できるようにするよう、
              ぼちぼち実装しています。
              エンバグ率が高まるのは根気強く何とかするとして。
              不便そうなところがあれば、早めにご指摘下さい。

              ところで、サクラエディタの方針としては、
              Unicode(UCS)の実装水準は、サロゲートペアと、
              JIS X 0213:2004 で導入された合成文字だけとするのでよろしいでしょうか。
              • [4719] Re3: Unicode の対応について maru 2007年03月10日 15:55

                >ところで、サクラエディタの方針としては、
                >Unicode(UCS)の実装水準は、サロゲートペアと、
                >JIS X 0213:2004 で導入された合成文字だけとするのでよろしいでしょうか。

                あまり細かいところは良く分かっていないのですが、大枠としてはVistaとの受け渡しを可能な限り確保できるレベルがひとつの目安でしょうか。

                合成文字というのは、ここの図14のことでよろしいでしょうか。
                http://itpro.nikkeibp.co.jp/article/COLUMN/20061221/257533/
                複数の表示方法をもつ図18の文字群は、往復変換時にWaveDashと同じ問題になりますね。

                >大規模修正に踏み切れず保守的な対応になりがちです.
                皆の合意がとれるような大規模修正のときは、例えば「内部Unicode化移行期間」などとして、バグフィックス以外の修正を完全停止してしまうとか(笑)
                • [4722] Re4: Unicode の対応について ラスティブ 2007年03月10日 19:41

                  >>data:2969 じゃなくて、>>dev::2969 でした。
                  すみませんでした。

                  > 大枠としてはVistaとの受け渡しを可能な限り確保できるレベルがひとつの目安でしょうか。

                  てことは、サロゲートペアと、JIS X 0213:2004 で導入された
                  合成文字だけとするのが妥当なところですね。


                  > 合成文字というのは、ここの図14のことでよろしいでしょうか。
                  > http://itpro.nikkeibp.co.jp/article/COLUMN/20061221/257533/
                  > 複数の表示方法をもつ図18の文字群は、往復変換時にWaveDashと同じ問題になりますね。

                  図14と図18のことです。
                  想定する文字コードの変換経路は以下のようです:

                   1.Unicode系列 以外の文字コードS -> Unicode系列 -> Unicode系列 以外の文字コードS
                   2.Unicode系列 -> Unicode系列 以外の文字コードS -> Unicode系列

                  1 については、WaveDash 問題を除くと、問題ない・・・ですよね。
                  合成文字による表現の揺らぎからくる影響が出るのは 2の変換経路をたどるときだけですけれど、
                  エディタ内部が Unicode系列の文字コードであれば 2の変換経路をたどることは、
                  ありません・・・よね?(おろおろ)
                  • [4726] Re5: Unicode の対応について maru 2007年03月11日 01:30

                    >> 複数の表示方法をもつ図18の文字群は、往復変換時にWaveDashと同じ問題になりますね。
                    >エディタ内部が Unicode系列の文字コードであれば 2の変換経路をたどることは、
                    >ありません・・・よね?(おろおろ)

                    あっそうか、大丈夫ですね。余計なこと書いてすいません。
                    • [4727] Re6: Unicode の対応について もか 2007年03月11日 05:57


                      Re: Unicode の対応について
                      >SJIS-2004 の変換表を組み込むことも考えましたけれど、
                      >Windows Vista が持ってる変換表と一致しているかどうかを
                      >確認する環境が無いので、やっぱ手が出せませんでした…(しょぼーん)。
                      Vista は「JIS2004(JIS X 0213:2004の文字集合に入ってる漢字等の表示)」に対応しているだけで、
                      Shift_JIS-2004 には未対応らしいです。

                      このあたりで触れています。
                      http://itpro.nikkeibp.co.jp/article/COLUMN/20061222/257650/
                      MSDNのコードページ一覧にも無いようです。(一覧だけでは信頼に置けないのが難点)
                      http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_81rn.asp
                      ということで、JIS 2004系エンコードは実装しないほうがいいと思います。

                      >1.Unicode系列 以外の文字コードS -> Unicode系列 -> Unicode系列 以外の文字コードS
                      CP932 の NEC/IBM 拡張の重複による Unicode との双方向でない変換などが多少あります。
                      あとは、サクラエディタ特有のバイナリデータ編集時です。

                      >2.Unicode系列 -> Unicode系列 以外の文字コードS -> Unicode系列
                      3.Unicode系列同士の変換
                      めったに使わないUTF-7同士による変換方法の差異とか
                      UTF-8の禁止シーケンスをUTF-16にすると失われる(禁止だからテキストエディタ的にはOK)などの問題
                      がないわけでは無いです。

                      あとは、「ファイルからコピー」のようなときにファイルの途中にBOMが付いたりするかもしれないなど、
                      細かいことを考えると切りが無いです。

                      #某ワイドキャラクタ版は、やっつけ仕事すぎることもあって、
                      #あまり気にせずに自由に作業してくだされば幸いです。
                      • [4729] Re7: Unicode の対応について ラスティブ 2007年03月11日 19:40

                        > Vista は「JIS2004(JIS X 0213:2004の文字集合に入ってる漢字等の表示)」に対応しているだけで、
                        > Shift_JIS-2004 には未対応らしいです。
                        >
                        > このあたりで触れています。
                        > http://itpro.nikkeibp.co.jp/article/COLUMN/20061222/257650/
                        > MSDNのコードページ一覧にも無いようです。(一覧だけでは信頼に置けないのが難点)
                        > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_81rn.asp

                         そうでしたか(恥ずかしいー)、それでは、サクラエディタの方針としては、
                        SJIS_JIS-2004 には対応しない方向でよろしいでしょうか。

                        > CP932 の NEC/IBM 拡張の重複による Unicode との双方向でない変換などが多少あります。
                        > あとは、サクラエディタ特有のバイナリデータ編集時です。

                         Unicode との双方向変換でない変換というのは、下のサイトで取り上げられていることでしょうか。
                        http://support.microsoft.com/default.aspx?scid=kb;en-us;Q170559
                        内部をUnicode化するには、
                        こういった差異を吸収できる構造を作る必要があるわけですね・・・。

                         サクラエディタ特有のバイナリデータ(任意値)は、内部的に

                        任意値/内部フォーマット
                        0x00/0xFFFF 0x0000
                        0x01/0xFFFF 0x0001
                         . / .  .
                         . / .  .
                        0xFF/0xFFFF 0x00FF

                        と表現して処理できるんじゃないかな…と、以前から思っていたので、
                        CMemText クラスの一部出来上がってる部分に組み込んでるんですけれど、
                        どんな影響が出るのか不明で…、不安です(汗)
                        致命的な欠陥にはならないと思いますけれど。

                        > 3.Unicode系列同士の変換
                        > めったに使わないUTF-7同士による変換方法の差異とか
                        > UTF-8の禁止シーケンスをUTF-16にすると失われる(禁止だからテキストエディタ的にはOK)などの問題
                        > がないわけでは無いです。

                         UTF-7 と JIS を 他の文字コードに単純に変換するだけでは、
                        元の UTF-7 や JIS のバイナリイメージを復元できないので、
                        その2つだけは、勘弁して頂くことにします・・・。

                        > あとは、「ファイルからコピー」のようなときにファイルの途中にBOMが付いたりするかもしれないなど、
                        > 細かいことを考えると切りが無いです。

                         “「ファイルからコピー」のようなとき”って、どんなときかを、
                        もう少し、詳しく説明していただけませんか。

                         すみません m(__)m
                        • [4737] Re8: Unicode の対応について もか 2007年03月13日 21:23

                          各種方針は、それで私はOKだと思います。

                          >> あとは、「ファイルからコピー」のようなとき
                          これはちょっと方向性が違う話しなので、あまり気にしないでください。
                          すみません。
                           いちよう説明すると、今はまだ無い「ファイルからカーソル位置に挿入」みたいなものがあるときに、
                          挿入するファイルにBOMなどが付いていたらどうしよう。保存すべきか削除するものなのか。
                          内部がUnicodeになると制御コードが増えるので悩ましいという話です。
                        • [4738] Re8: Unicode の対応について wakura 2007年03月13日 21:34


                          >任意値/内部フォーマット
                          ...
                          >と表現して処理できるんじゃないかな…と、

                          私もバイナリデータをどう表現するか悩んでいたんですが、なるほど(メモメモ
                          ただ、これって1バイト系の任意文字ですよね。
                          UTF-16のファイルを読んだときに0xffffなコードが含まれていたら0xffff,0xffff
                          とエスケープしないといけないです。それとも0xffff,0x00ff,0xffff,0x00ffに展
                          開するのでしょうか。不正なサロゲートペアやUTF-32でも、以下同様。
                          UTF-16やUTF-32の途中バイトでファイルが終わっている場合もあるだろうから、
                          1バイト単位に分割してエスケープするんだろうなと思う。

                          で、独自にエスケープするとTextOut、キャレット位置の取得なんかのときにデー
                          タをごっそりとAPIに直接渡せなくなるので、結局1文字ずつ切り出して計算する
                          ことに。orz
                          • [4744] Re9: Unicode の対応について wakura 2007年03月14日 22:46


                            文字列を後ろ向きに読むときのために

                            0xffff+0xdf??

                            でエスケープすればよさげ。

                            サロゲートペアの2ワード目かどうかは確認する必要があるので
                            そのチェックで自動的にもう1ワード戻れる。

                            と妄想してみました。
                        • [4742] Re8: Unicode の対応について ラスティブ 2007年03月14日 09:53

                          ▼ もかさん

                          > 各種方針は、それで私はOKだと思います。

                           某ワイドキャラクタ版 配布元のご意見は、重要です(^^;)

                          > 内部がUnicodeになると制御コードが増えるので悩ましいという話です。

                           そこまでよく調べてないので、ちょっと分かりませんけれど、
                          それについては、叩き台が出来上がったところで、
                          また話し合う必要がありそうですね。


                          ▼ wakura さん

                          > これって1バイト系の任意文字ですよね。

                          はい。パソコンが持つ最小単位が1バイトなので、必然的にそうなっちゃいます。
                          ちなみにこれは UTF-16 用ですけれど、UTF-8 にするなら・・・

                          任意値/内部形式
                          0x00/0xFE 0x00
                          0x01/0xFE 0x01
                          .  .  .
                          .  .  .
                          0xFD/0xFE 0xFC
                          0xFE/0xFF 0x00
                          0xFF/0xFF 0x01

                          こんな感じになるんです。
                          (内部的に使う文字コードをハッキリできないと、
                          こちらのほうも決められない罠。)

                          > 独自にエスケープするとTextOut、キャレット位置の取得なんかのときに
                          > データをごっそりとAPIに直接渡せなくなるので、
                          > 結局1文字ずつ切り出して計算することに。orz

                          文字列の走査…もとい、
                          合成文字を考慮しない文字のサイズを取得するルーチンは単純化できます。
                          でもやっぱり、合成文字を考慮しないといけないから遅くなることに orz
            • [4718] Re2: Unicode の対応について ラスティブ 2007年03月10日 14:02

              > 不便そうなところがあれば、早めにご指摘下さい。

              class SAKURA_CORE_API CMemText{
              CMemory *m_pcmemData; // UTF-8
              CMemory *m_pcmemData_sjis; // SJIS 互換用バッファ
              public:
              CMemText() : m_pcmemData(NULL) {};
              ~CMemText() {};

              void DetatchBuf( CMemory * );
              void DetatchBuf_sjis( CMemory * );

              char* GetPtr() const{ m_pcmemData.GetPtr(); }
              char* GetPtr_sjis() const{ m_pcmemData_sjis.GetPtr(); }

              static int GetSizeOfChar( const char *, const int, const int );
              static int GetSizeOfChar_sjis( const char *, const int, const int );

              bool IsValid() { return (m_pcmemData != NULL) }
              int LoadText( enumCodeType, const CMemory & );
              int LoadText_sjis( const char *, const int );
              int LoadText_jis( const char *, const int );
              int LoadText_eucjp( const char *, const int );
              int LoadText_uni( const char *, const int );
              int LoadText_utf8( const char *, const int );
              int LoadText_utf7( const char *, const int );
              int LoadText_unibe( const char *, const int );

              int ToAuto( enumCodeType, CMemory * ); /* 指定された文字コードで書き出し */
              int ToSJis( CMemory * ); /* Windows版 SJIS(CP-932) で書き出し */
              int ToJis( CMemory * ); /* Windows版 ISO-2022-JP(CP-5022x) で書き出し */
              int ToEuc( CMemory * ); /* Windows版 EUC-JP(CP-51932) で書き出し */
              int ToUnicode( CMemory * ); /* UTF-16 で書き出し */
              int ToUtf8( CMemory * ); /* UTF-8 で書き出し */
              int ToUtf7( CMemory * ); /* UTF-7 で書き出し */
              int ToUnicodeBe( CMemory * ); /* UTF-16 Big-Endian で書き出し */

              void ToZenkaku( int, int ); /* 半角→全角 */
              void ToHankaku( int nMode ); /* 全角→半角 */
              void ToLower( void ); /* 小文字 */
              void ToUpper( void ); /* 大文字 */
              };
              • [4723] Re3: Unicode の対応について げんた 2007年03月10日 20:24

                > CMemory *m_pcmemData_sjis; // SJIS 互換用バッファ
                をどのように使用するのかちょっと見えないのですけど,2つのバッファをどう使っていくのかもう少し説明していただけませんか.
                • [4724] Re4: Unicode の対応について ラスティブ 2007年03月10日 21:09

                  すみません、説明不足でしたー。
                  こんな感じです(f^^;)

                  class SAKURA_CORE_API CMemText
                  {
                  CMemory *m_pcmemData; // 内部 UTF-8
                  CMemory *m_pcmemData_out;
                  int m_nCodeType;
                  bool m_bChanged;

                  /*
                  説明:
                  m_pcmemData .......  内部データ (UTF-8)
                  m_pcmemData_out ...  出力用一時バッファ
                  m_nCodeType .......  出力用一時バッファに保持されているデータの文字コード
                  CODE_SJIS: SJIS, CODE_UNICODE: Unicode, -1: 出力用一時バッファにデータ無し
                  m_bChanged ........  内部データが出力用一時バッファ *m_pcmemData_out に転送された後に、
                  内部データに変更があったかどうか。
                  */

                  public:

                  CMemText() : m_pcmemData(NULL) {};
                  ~CMemText() {};

                  bool IsValid() { return (m_pcmemData != NULL) }

                  // 内部データのポインタを取得
                  char *GetPtr() const;
                  // SJIS に変換されたデータ(出力用一時バッファに格納)のポインタを取得
                  char *GetPtr_sjis() const;
                  // UTF-16 に変換されたデータ(出力用一時バッファに格納)のポインタを取得
                  wchar_t *GetPtr_utf16() const;

                  ....
                  • [4725] Re5: Unicode の対応について げんた 2007年03月11日 01:01

                    いろいろ突っ込んじゃいます.

                    > m_pcmemData .......  内部データ (UTF-8)
                    UTF-8? 表示の都度変換する覚悟なのですね.

                    > m_pcmemData_out ...  出力用一時バッファ
                    > m_nCodeType .......  出力用一時バッファに保持されているデータの文字コード
                    > CODE_SJIS: SJIS, CODE_UNICODE: Unicode, -1: 出力用一時バッファにデータ無し
                    > m_bChanged ........  内部データが出力用一時バッファ *m_pcmemData_out に転送された後に、
                    > 内部データに変更があったかどうか。
                    テキストごとにバッファが必要か?と思いましたが,キャッシュなのですね.
                    実質的にメモリ消費が倍になってしまいません?
                    それでも変換結果を保存する必要があるのでしょうか.
                    • [4728] Re6: Unicode の対応について ラスティブ 2007年03月11日 19:37

                      ビシバシ突っ込んで下さい。

                      > > m_pcmemData .......  内部データ (UTF-8)
                      >UTF-8? 表示の都度変換する覚悟なのですね.

                       えーと。Winアプリを一度も作ったことがない程の者なので(汗)
                      正直言って、それでいいのかどうか分かりかねます…。
                      また、自分で出来るところは、せいぜい文字列変換クラスと、
                      それにまつわる文字列走査関数くらいじゃないかなぁと・・・。
                      けれど、とにかく変換その他ライブラリをそろえることと、
                      サクラエディタのUNICODE化に対する方針を固めることくらいは
                      やっておかないと、誰も手をつけなられないと思うので…。

                       API関数 ::TextOutW() は UTF-16 もどきを必要としているそうなので、
                      UTF-16 を内部データとするのが効率的なんでしょうか…。
                      それとも、各関数のインターフェースをあまり変更しなくてもよい、
                      比較的滑らかに UNICODE化できそうな(気がする)UTF-8 を
                      用いるほうがいいでのしょうか。
                       こう書いてみると、理想は UTF-16 ですけれど・・・。
                      このあたりの、なんかこう…、説得力のある解説をどなたか、
                      よろしくお願いします。

                      > テキストごとにバッファが必要か?と思いましたが,キャッシュなのですね.
                      > 実質的にメモリ消費が倍になってしまいません?
                      > それでも変換結果を保存する必要があるのでしょうか.

                       SJIS 用の出力用一時バッファについてですが、本来、
                      それは必要なさげですけれど、UNICODEに対応し切れないコードに
                      対して、SJIS に変換してからポインタを取得するというような
                      コードが散在する状況が目に見えているので、あると便利かなーと…。

                       ところで、CMemText クラスが使われる場面は、主に、
                      以下のようなものを想定してます。

                       1.単に文字コード・文字種を変換するとき。
                       2.単に文字列を走査するとき。
                       3.SJIS 対応関数に CDocLineMgr 管轄の CMemory オブジェクトを参照させるとき。
                       4.その他。

                       上記のメモリ消費量の問題は、現状の、エディタに読み込んだ
                      テキストを CMemory クラスを使って保持する構造を維持するように
                      努めることで、文字コードの違った同じ内容のテキストを
                      2つ持つような状況は、UNICODE化が進むにつれて減っていく・・・うぅ(--;)
                      というか・・・
                      そういう状況にならないよう、気をつける必要がありますね…(^^;)
                      • [4731] Re7: Unicode の対応について げんた 2007年03月13日 00:23

                        > API関数 ::TextOutW() は UTF-16 もどき
                        あれっ,"もどき"なんですか.知らなかった...というのは本題ではなくて,
                        表示する度に変換が必要で,それをキャッシュしたらデータを二重に持つことになるのでは?
                        つまり,2つめのバッファにSJISと名付けていますけど,そこは表示の時には使わないのか?という疑問です.
                        • [4734] Re8: Unicode の対応について ラスティブ 2007年03月13日 15:00

                          > >  API関数 ::TextOutW() は UTF-16 もどき
                          > あれっ,"もどき"なんですか.知らなかった...というのは本題ではなくて,
                          > 表示する度に変換が必要で,それをキャッシュしたらデータを二重に持つことになるのでは?
                          > つまり,2つめのバッファにSJISと名付けていますけど,そこは表示の時には使わないのか?という疑問です.

                          はい。二重に持つことになります。
                          表示のときにキャッシュするテキストの桁数は、
                          現状の CEditView::DispLineNew だと、
                          最大で編集領域の折り返し長分となります。

                          内部コードを UTF-16 にすれば、
                          表示データをキャッシュする頻度が減りますね…たしかに。

                          SJIS と名づけられた2つ目のバッファは、最終的には、
                          Win9x 系で動作させるときのためだけに使われることに
                          なりそうです。
          • [4758] RE: Unicode の対応について wakura 2007年03月20日 22:07


            とりあえずリンク集

            Vistaフォント関係のMSのリンク
            http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353
            http://support.microsoft.com/kb/927488/ja
            http://www.microsoft.com/japan/windows/products/windowsvista/jp_font/default.mspx
            ここの「Windows Vista における JIS2004 対応に関する詳細資料」のPDFに、
            追加された合成文字のイメージがあります。


            あとWikipediaにもコード表が!
            http://ja.wikipedia.org/wiki/Unicode#WAVE_DASH_-_FULLWIDTH_TILDE.E5.95.8F.E9.A1.8C

            本家
            http://www.unicode.org/