K.Maebashi's BBS

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

>私が問題にしているのは、Test.dkmの726行目 > if (str[i] == '本') { >の解釈で、WindowのCYGWINのGCCが作成した実行部は２バイト文字として >文字リテラルを解釈しているのに、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になっているように 見えますが、いくらなんでもそんなはずは……

Mac持ってませんが探究中です。 >なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。 >この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように >見えますが、いくらなんでもそんなはずは…… 出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 引き続き調査しまーす。

>出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 出力結果： > str[0]..50940 16進数に直すとC6FC 文字コード表を見ると…すみません、確かにEUCでした。ご指摘ありがとうございます。 同じ手順で確認したはずが、なぜShift-JISだと思ってしまったんだろう。 >つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 >青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 ということですよね。つよしさんの実験がEUC環境下で行われたなら、実質無変換で、 ただしマルチバイトの1文字として変換されたということでしょうか。

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

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

>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に何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。 以上

>私の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 手元で実験できない私としては混沌とするばかりです。

>(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共に(空文)でした。

青餓鬼さん、試していただいてありがとうございます。 とりあえず、Macの人に対しては 「とりあえずUTF-8版を試してください。 駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 って指針で、多くの人に使ってもらえそうですね。 私のほうも、ここらで追究を一段落させていただきます。 ありがとうございました。

青餓鬼さん、yuyaさん、ありがとうございます。 管理人が放置してしまいましてすみません。 この結論を関連ページに追記しました。ありがとうございました。 >とりあえず、Macの人に対しては >「とりあえずUTF-8版を試してください。 >駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 >って指針で、多くの人に使ってもらえそうですね。