[
▲前のスレッド
]
▼
2007/11/27 (火) 20:49:03
kobake
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
[65]
提案：ソースコードの文字コード
もしヤルとしたら今のうち…なのですが、
パッチ適用時の文字化けを防ぐために、全てのソースをUTF-8にしてしまう、というのはどうでしょうか。
http://
sakura-
editor.
sourcefo
rge.
net/
cgi-
bin/
cyclamen
/
cyclamen
.
cgi?
log=
dev&
ol=
200604&
tree=
s4396
http://
sakura-
editor.
sourcefo
rge.
net/
cgi-
bin/
cyclamen
/
cyclamen
.
cgi?
log=
dev&
ol=
200604&
tree=
s4406
UTF-8で書かれたソースコード、というのがどれほど浸透しているのか分かりませんけど。。
デメリットもありそうではあります。
▼
2007/11/27 (火) 22:53:55
げんた
INCM1.23c
[66]
RE: 提案：ソースコードの文字コード
>パッチ適用時の文字化けを防ぐために、全てのソースをUTF-8にしてしまう、というのはどうでしょうか。
>UTF-8で書かれたソースコード、というのがどれほど浸透しているのか分かりませんけど。。
経験がないのでわかりませんが，埋め込まれた文字列がUTF-8だと，UTF-16でもSJISでもなくUTF-8出力されてしまうということにはなりませんか？
文法上はSJISで問題となる文字列中のbackslash(YEN記号)が出ないので問題なさそうですけど...
▼
2007/11/27 (火) 23:23:05
kobake
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
[67]
Re2: 提案：ソースコードの文字コード
▼ げんたさん
> >パッチ適用時の文字化けを防ぐために、全てのソースを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 に関して試した限りでは」、
問題が無さそうでした。
・この挙動が一般的であるか
・他のコンパイラでも同じ挙動になるのか
等の普遍的で太鼓判を押すに値する情報は、まだ見つけてないです。
[
▼次のスレッド
]
INCM/CMT
Cyclamen v3.81
[ut:0.010][st:0.000]