K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]


新規投稿 | 開設者ホームページへ戻る | ヘルプ


[1457] DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:青餓鬼
2009/10/31 16:43:49

Link:
私が問題にしているのは、Test.dkmの726行目
    if (str[i] == '本') {
の解釈で、WindowのCYGWINのGCCが作成した実行部は2バイト文字として文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が複数あるとしてエラーとしていることです。
文字リテラルに関しては、ほかの手段を執るか制限を設けるのか検討が必要だと思います。

以上
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1458] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:(ぱ)こと管理人
2009/11/01 16:07:52

Link:http://kmaebashi.com
>私が問題にしているのは、Test.dkmの726行目
>    if (str[i] == '本') {
>の解釈で、WindowのCYGWINのGCCが作成した実行部は2バイト文字として
>文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が
>複数あるとしてエラーとしていることです。

まず、Diksamでは、"あいうえお".length()は5を返しますし、"あいうえお"[3]の
値は'え'である、というのが仕様です。つまり、Diksamでは、文字列は「バイトの
並び」ではなく「文字の並び」です。この「文字」は、日本語であっても、
1文字は1文字として解釈されなければなりません。

よって、実行に成功していれば、test.dkmにおける以下のコードの実行結果は、

string str = "日本語";
for (i = 0; i < str.length(); i++) {
    println("str[" + i + "].." + str[i]);
    if (str[i] == '本') {
        println("本");
    }
}

以下のようになるのが正解です。

str[0]..26085
str[1]..26412

str[2]..35486

ところが、青餓鬼さんの環境では、str.length()がEUCではが6, UTF-8では9に
なっています。これはマルチバイト文字からUNICODEへの変換が行われておらず、
単にバイト列として読み込まれているように見えます。

マルチバイト文字からUNICODEへの変換処理はロケールに依存するので、
環境変数LANGの値はどうなっているのかが気になっているわけです。
とはいえ私はMacは持っておりませんしOS-Xを使ったこともないので、
見当はずれのことを書いている可能性はあります。詳しい方ご指摘ください。

過去MacOSで動かした人はいたはずだったよな、と思い掲示板の過去ログを
探したところ、以下の投稿が見つかりました。
http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1196&range=1

なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。
この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように
見えますが、いくらなんでもそんなはずは……
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1461] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:yuya
2009/11/03 00:47:46

Link:
Mac持ってませんが探究中です。

>なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。
>この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように
>見えますが、いくらなんでもそんなはずは……

出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。

つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。
青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。

引き続き調査しまーす。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1462] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:(ぱ)こと管理人
2009/11/04 02:19:50

Link:http://kmaebashi.com
>出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。

出力結果:
> str[0]..50940 

16進数に直すとC6FC

文字コード表を見ると…すみません、確かにEUCでした。ご指摘ありがとうございます。
同じ手順で確認したはずが、なぜShift-JISだと思ってしまったんだろう。

>つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。
>青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。

ということですよね。つよしさんの実験がEUC環境下で行われたなら、実質無変換で、
ただしマルチバイトの1文字として変換されたということでしょうか。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1493] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:青餓鬼
2010/01/23 15:03:36

Link:
Macで実行する際、UTF-8の場合exportコマンドで環境変数を指定すると、正常に実行することがわかりました。

>export LANG=ja_JP.UTF-8

このコマンドを実行した後に DIKSAM を実行すると、サンプルと同じ結果を得ることができます。
Macの技術解説書にこのあたりを体系的に記述したものが見あたらず、たまたま読んだコマンドリファレンスの、別のコマンドの実行例に、上に掲げた一文があり、早速実行すると、エラーなく実行できました。
なお、EUCの場合は、ターミナル上の日本語表示が文字化けしますので、別の環境変数があるのかもしれません。これ以上、深入りは当面控えておきます。

以上

[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1494] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:yuya
2010/01/24 17:04:03

Link:
export LANG=ja_JP.UTF-8

で正常動作するということは、もとのLANGはUTFじゃなかったということですね。
ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか?
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1495] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:青餓鬼
2010/01/31 16:05:29

Link:
>export LANG=ja_JP.UTF-8
>
>で正常動作するということは、もとのLANGはUTFじゃなかったということですね。
>ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか?

私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。
ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。
環境変数LANGに何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。

以上
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1496] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:yuya
2010/02/03 18:05:11

Link:
>私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。
>ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。

返信ありがとうございます。

(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか?

(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。
差し支えなければ echo $LC_ALL も試してみてください。

MacOS X のことは全然分かんないや……。FreeBSDベースらしいということと、
http://homepage3.nifty.com/toshi3/osx2t.html
の最後に

>Mac OS Xではファイル名はUTF-8、Unixに由来する部分では日本語EUC、
>従来のMac OSに由来する部分ではShift-JISと、複数の文字コードが混
>在して使用されている。

と書かれていて、とにかく複雑なことになってる、ってことは分かりました。

あと、Unicode正規化の方式も違うようで、
http://labs.unoh.net/2007/09/unicode-on-mac.html
手元で実験できない私としては混沌とするばかりです。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1499] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:青餓鬼
2010/02/11 16:04:04

Link:
>(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか?
Mac OSX 10.5の方はコマンドの追加もなく、ちゃんと動きました。

>(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。
>差し支えなければ echo $LC_ALL も試してみてください。
echo $LC_ALL の実行結果は、Mac OSXの10.4、10.5共に(空文)でした。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1500] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:yuya
2010/02/11 22:20:01

Link:
青餓鬼さん、試していただいてありがとうございます。

とりあえず、Macの人に対しては
「とりあえずUTF-8版を試してください。
駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」
って指針で、多くの人に使ってもらえそうですね。
私のほうも、ここらで追究を一段落させていただきます。
ありがとうございました。
[ この投稿を含むスレッドを表示] [ この投稿を削除]



[1501] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
返信


投稿者:(ぱ)こと管理人
2010/02/14 00:08:06

Link:http://kmaebashi.com
青餓鬼さん、yuyaさん、ありがとうございます。

管理人が放置してしまいましてすみません。

この結論を関連ページに追記しました。ありがとうございました。

>とりあえず、Macの人に対しては
>「とりあえずUTF-8版を試してください。
>駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」
>って指針で、多くの人に使ってもらえそうですね。
[ この投稿を含むスレッドを表示] [ この投稿を削除]