◀Unicode版開発トップへ
  • 65 提案:ソースコードの文字コード
    • 66 RE: 提案:ソースコードの文字コード
      • 67 Re2: 提案:ソースコードの文字コード
  • [65] 提案:ソースコードの文字コード kobake 2007年11月27日 20:49

    もしヤルとしたら今のうち…なのですが、
    パッチ適用時の文字化けを防ぐために、全てのソースをUTF-8にしてしまう、というのはどうでしょうか。
    http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=dev&ol=200604&tree=s4396
    http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=dev&ol=200604&tree=s4406

    UTF-8で書かれたソースコード、というのがどれほど浸透しているのか分かりませんけど。。
    デメリットもありそうではあります。
    • [66] RE: 提案:ソースコードの文字コード げんた 2007年11月27日 22:53

      >パッチ適用時の文字化けを防ぐために、全てのソースをUTF-8にしてしまう、というのはどうでしょうか。
      >UTF-8で書かれたソースコード、というのがどれほど浸透しているのか分かりませんけど。。
      経験がないのでわかりませんが,埋め込まれた文字列がUTF-8だと,UTF-16でもSJISでもなくUTF-8出力されてしまうということにはなりませんか?

      文法上はSJISで問題となる文字列中のbackslash(YEN記号)が出ないので問題なさそうですけど...
      • [67] Re2: 提案:ソースコードの文字コード kobake 2007年11月27日 23:23

        ▼ げんたさん
        > >パッチ適用時の文字化けを防ぐために、全てのソースをUTF-8にしてしまう、というのはどうでしょうか。
        > >UTF-8で書かれたソースコード、というのがどれほど浸透しているのか分かりませんけど。。
        > 経験がないのでわかりませんが,埋め込まれた文字列がUTF-8だと,UTF-16でもSJISでもなくUTF-8出力されてしまうということにはなりませんか?

        なるほど、たしかにその辺りはちょっと不安ですね。

        Visual Studio 2005 で試してみた限りでは、文字列リテラルは
        内部的(コンパイラ的)には
        charリテラルなら Shift_JIS に、wchar_tリテラルなら UTF-16LE に、
        それぞれ変換した上で保持されているようでした。

        たとえば日本語環境で、以下のようなコードを書いて、
        void f()
        {
         char* s1 = "ABC日本(ニーハオ)"; //(※1)
         wchar_t* s2 = L"ABC日本(ニーハオ)"; //(※2)
        }
        これをステップ実行で追って s1 の中身を見てみると、
        s1 は Shift_JIS 形式で "ABC日本?好" と保持されていました。
        (「ニー」の部分が日本語環境のコードページでは現せないので「?」に変換されている)

        ちなみに、コンパイルの時点で(※1)の行で
        「warning C4566: ユニバーサル文字名 '\u4F60' によって表示されている文字は、現在のコード ページ (932) で表示できません」
        という警告が発せられていました。

        s2 では警告も無くデータも壊れず UTF-16LE 形式で格納されていました。


        規格は調べていませんが、実際の動作として、「Visual Studio 2005 に関して試した限りでは」、
        問題が無さそうでした。
        ・この挙動が一般的であるか
        ・他のコンパイラでも同じ挙動になるのか
        等の普遍的で太鼓判を押すに値する情報は、まだ見つけてないです。