◀ANSI版開発トップへ
  • 2511 sakura 2.x系(内部Unicode版)について
    • 2514 Re:sakura 2.x系(内部Unicode版)について
    • 2519 Re: sakura 2.x系(内部Unicode版)について
      • 2523 Re2: sakura 2.x系(内部Unicode版)について
        • 2526 Re3: sakura 2.x系(内部Unicode版)について
          • 2530 Re4: sakura 2.x系(内部Unicode版)について
      • 2535 Re2: sakura 2.x系(内部Unicode版)について
        • 2612 Re3: sakura 2.x系(内部Unicode版)について
          • 2969 Re4: sakura 2.x系(内部Unicode版)について
          • 2970 Re4: sakura 2.x系(内部Unicode版)について
            • 2971 Unicodeについて&拡張漢字対応希望
            • 2975 Re5: sakura 2.x系(内部Unicode版)について
              • 2977 Re6: sakura 2.x系(内部Unicode版)について
    • 2634 RE: sakura 2.x系(内部Unicode版)について
      • 2635 Re2: sakura 2.x系(内部Unicode版)について
        • 2911 Re3: sakura 2.x系(内部Unicode版)について
  • [2511] sakura 2.x系(内部Unicode版)について もか 2002年12月09日 19:56

    題名の通りUnicode版ですが,どこから手をつけていいものか...
    ということで,提案があります。

    今後関数を新規・修正などするときに,可能なときはMicrosoft式(?)に,TCHAR系で
    Unicode先行対応しておくようにするというのはどうでしょうか?

    #個人的には前面UTF-16サポートしたいが...
    • [2514] Re:sakura 2.x系(内部Unicode版)について かろと 2002年12月10日 00:17

      意義なしです。
    • [2519] Re: sakura 2.x系(内部Unicode版)について げんた 2002年12月11日 22:45

      >今後関数を新規・修正などするときに,可能なときはMicrosoft式(?)に,TCHAR系で
      >Unicode先行対応しておくようにするというのはどうでしょうか?
      内容には賛成ですが,具体的に使ってはいけない物と代わりに使うべき物の対応表と,使用時の注意点などを示していただけませんか?

      あと,これってVC以外のコンパイラでも大丈夫なのでしょうか.
      • [2523] Re2: sakura 2.x系(内部Unicode版)について あろか 2002年12月12日 00:53

        ▼ げんたさん
        > >今後関数を新規・修正などするときに,可能なときはMicrosoft式(?)に,TCHAR系で
        > >Unicode先行対応しておくようにするというのはどうでしょうか?
        > 内容には賛成ですが,具体的に使ってはいけない物と代わりに使うべき物の対応表と,使用時の注意点などを示していただけませんか?
        >
        > あと,これってVC以外のコンパイラでも大丈夫なのでしょうか.
        tchar.h をちゃんとincludeしておけば、BCCではOKです。
        • [2526] Re3: sakura 2.x系(内部Unicode版)について かろと 2002年12月12日 21:38

          ▼ あろかさん
          > > あと,これってVC以外のコンパイラでも大丈夫なのでしょうか.
          > tchar.h をちゃんとincludeしておけば、BCCではOKです。

          _T("文字") ってのも 使えるのでしょうか?
          • [2530] Re4: sakura 2.x系(内部Unicode版)について もか 2002年12月13日 13:13

            >_T("文字") ってのも 使えるのでしょうか?
            BCC5.5.1では使えることをいちおう確認しています。
            ちなみにBCCは\u0041とか\U00000041に対応しているようです。
            VC6では見事にエラーになった気が...

            コンパイルオプションで -D_UNICODE =DUNICODE が必要です。
            _UNICODEは TCHAR等に影響
            UNICODEは Win32APIに影響するのかな?

            いきなり話題が変わりますが、
            改行コード長は CEOL::GetLen()が現在でもTCHAR単位で値を返します。
            CMemoryクラスをどうUnicode対応するかについては大問題になりそうです。
            とりあえず、Unicode版ではバッファ末尾のNULL追加を1バイトから2バイトにしないと、アクセス違反で落ちる箇所が出てくるはずです。(バッファ末尾のNULLを明示的・暗黙的に期待する箇所)

            一番の問題は、長さ(Len,Lenth)、大きさ(size)というものがバイト単位なのか、TCHAR単位なのか
            をすべての関数で決めないといけないということだと思います。

            #先に白状しておきますが、Unicodeのアプリケーション開発に実績があるわけではないので、大変です。
      • [2535] Re2: sakura 2.x系(内部Unicode版)について もか 2002年12月26日 15:47

        >具体的に使ってはいけない物と代わりに使うべき物の対応表と,使用時の注意点などを示していただけませんか?
        *C/C++ランタイム関数の対応表
        については、全部並べるわけにも行かないので、MSDN(日本語)へリンクを張っておきます。

        http://www.microsoft.com/japan/developer/library/default.asp?URL=/japan/developer/library/vccore/_crt_generic.2d.text_mappings.htm

        tchar.hで、足りない部分はmy_tchar.hとかを作るほかなさそうです。
        _tmemcpyも VC6では未定義です。(メモリ操作に変数の型は関係ないからだとは思いますが)

        *使用時の注意
        ■長さの単位に気をつけてください。
        TCHAR szDes[100], szSrc[100];
        // 例えば、以下の使用方法は間違いです。
        _tcsncpy( szDes, szSrc, sizeof( szSrc ) );
        // 正しくは以下のどれかです。
        ・_tcsncpy( szDes, szSrc, 100 ); // szDes, szSrc は 100文字以上の配列だった場合
        ・_tcsncpy( szDes, szSrc, sizeof( szSrc ) / sizeof( TCHAR ) );

        ■上のに近いですが文字数をSJISで数えないでください。
        例:
        _tmemcpy( szDes, _T("(無題)"), 6 );
        _MBCS(SJIS) ではたしかに「6バイト/char[6]」ですが、
        _UNICODE/UNICODE では、「8バイト/wchar_t[4]」です。
        実際には、日本語特有の文字列はリソースかどこかに追い出すのでこの問題はなくなると思います。

        ■_tcs***は _MBCS定義時、 _mbs*** にマップされる
        str*** を用いていた部分を _tcs*** に書き換えると、実際に利用される関数が _mbs*** になるために動作が変わる(バグの元になる)ことがあるかもしれません。
        また、パフォーマンスが落ちるかも
        • [2612] Re3: sakura 2.x系(内部Unicode版)について あろか 2003年03月09日 20:14


          -DUNICODEでコンパイルすると、Win9x系で使えなくなると思います。
          そうすると、文字列を以下の3グループに分けて扱わないとだめかなと。
          1・API呼び出しに使う文字列(9x用にMBCSで残せるように)
          2・内部で扱う文字列(Unicodeで統一)
          3・デバッグ用文字列(charのままで充分)
          • [2969] Re4: sakura 2.x系(内部Unicode版)について みく 2003年07月22日 23:21


            ということは、9x系を切り捨てない限り
            UNICODE,_UNICODEの定義はできないってことですよね。
            結局、管理データは独自に定義・処理する必要が出てきてしまう。

            ・管理するデータ専用の型(例:MOJI)を新たに作成して、それで書き換える。
             (ただし、実態はwchar_tである)
            ・CMemoryとは別にCMojiみたいなクラスを(派生?)作って、それで書き換える。
             管理するデータは全部こちらを使う。
             必要な関数はこちらに移すなり作成するなりする。
            ・CMemoryはバイナリデータを扱うとき専用。
             (現状は混在している)
            ・同じコードを書けない場合は、#ifdef MOJIX とかで切り分ける。
             (これが一番問題なんだろう)

            コンパイルでの切り替え例:(MOJIXが管理データを切り替えるオプションとすると...)
            1._MBCS: 現状、すべてSJIS
            2._MBCS,MOJIX: 管理データはUNICODE,他はSJIS
            3.UNICODE,_UNICODE,MOJIX: すべてUNICODE(ただし9x系は動作せず)
             (_T(),TCHARはこのときのため?)

            UNICODEは全部1文字で済むので、処理は簡単になると思うが、
            文字の種類に関する処理では、複雑になると思われる。
          • [2970] Re4: sakura 2.x系(内部Unicode版)について げんた 2003年07月23日 01:43

            横からすいません.

            「内部Unicode版」の解釈にちょっと認識のずれがあるのではないかと思います.
            Unicode化と言ったときに
            1. エディタで管理するデータの内部表現のUnicode化
            2. APIのUnicode版使用

            TCHARやLPTSTRを使うことでUnicode/ANSIの両方でコンパイルできるという話は2のAPIでWとAのどちらを使うかという話であり,APIの呼び出し効率程度の話にしか感じられません.

            それに対して,内部管理をUnicodeにするというのは現在扱えない文字を扱えるようにするという話ですのである程度意味のあることだと思います.(もっともUnicodeも手放しで推進していいわけではないようですが)

            そういう面から見ると
            >1・API呼び出しに使う文字列(9x用にMBCSで残せるように)
            >2・内部で扱う文字列(Unicodeで統一)
            は内部で明確に区別する必要があるでしょう.Win95/98系を考えるとAPIはAnsiを使い続けるが,個人的にUnicode専用版を作ることは可能なようにしておく方針でいいんではないでしょうか.

            意図的に内部コード用の文字列型を定義してAPIに与えるときは必ず変換関数を挟むとか?
            型が同じならそのまま渡されて,異なったら変換されるとか.う~ん,面倒くさそう...

            >3・デバッグ用文字列(charのままで充分)
            こちらはどちらでも受け入れられるように作っておけばいいのでは?(と言ってしまったけどできるのかな?)
            • [2971] Unicodeについて&拡張漢字対応希望 wmlhq 2003年07月23日 14:56

              Unicode専用版を作ることについてですが、再配布可能なPlatform SDKの
              Microsoft Layer for Unicode on Windows 95/98/ME Systems (MSLU)
              を使えば、すぐにUnicodeに対応できます。

              http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

              ところで、サクラエディタは拡張漢字に対応してますか。
            • [2975] Re5: sakura 2.x系(内部Unicode版)について みく 2003年07月24日 21:11


              >意図的に内部コード用の文字列型を定義してAPIに与えるときは必ず変換関数を挟むとか?
              >型が同じならそのまま渡されて,異なったら変換されるとか.う~ん,面倒くさそう...

              UNICODE,_UNICODEの定義ができないとなれば、
              それに変わるものを独自に定義しないと駄目でしょう。
              (_MBCSを定義している限り、TCHAR,_T()はcharでしかないので)

              となると、記事2969になるわけです。


              Microsoft Layer for Unicode on Windows 95/98/ME Systems (MSLU)
              を使えば、完全にUNICODEにできるかもしれませんが、
              NT,9x両方で動作させるためには、どうするんでしょう?
              NT系は標準でAPIを持っているし(←競合しますよね)、
              GetProcAddressでAPIテーブルでも作るんでしょうか。
              • [2977] Re6: sakura 2.x系(内部Unicode版)について wmlhq 2003年07月25日 16:13

                http://go.microsoft.com/fwlink/?LinkId=14851
                http://communities.microsoft.com/newsgroups/default.asp?ICP=Platformsdk&sLCID=US&NewsGroup=microsoft.public.platformsdk.mslayerforunicode
                http://microsoft.com/globaldev/handson/dev/mslu_announce.mspx
                http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx
                http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm?p=/msdownload/platformsdk/sdkupdate/psdkredist.htm
    • [2634] RE: sakura 2.x系(内部Unicode版)について みく 2003年03月29日 19:30


      正規表現ライブラリは BREGEXP が使えなくなると思いますが、
      代替は php-mbregex あたりでしょうか。
      • [2635] Re2: sakura 2.x系(内部Unicode版)について げんた 2003年03月30日 03:06

        >代替は php-mbregex あたりでしょうか。
        以前boost::regexpが使えるという話が出ました。
        • [2911] Re3: sakura 2.x系(内部Unicode版)について みく 2003年06月30日 19:36


          知っている人は知っていると思いますが、

          http://www.freshports.org/devel/oniguruma/

          もあるみたいです。