|
> その本は捨てましょう。 う〜ん、ここは68userのボードなので構わないのですが、 なんか、2ch化しているようでちょぴりショックだなぁ(^^ゞ 多分typeでしょう、本当にその様に書くことを勧めているのであれば 68userさんと同じ意見ですが… だけど、椎さんがコマンドの本来の項を読まずに、理解しようとしないで コピーしているだけであれば、椎さんの手抜きでしょうけど(^^ゞ まあ、自分もはじめはそうだったので人の事を言えませんが(笑) ちなみに、テストの為にコンバートした短い文字列を表示していませ んか？昔のネスケでの挙動ですが、短い文字列の場合はブラウザで文字 コードの判別がつかずに化ける場合があります。 その場合はそこそこの長文を表示すると、うそのように表示される場合 が有りました。 原因はSJISとEUCの文字コードが一部かぶる為です。(自分のスクリプ トはSJISで記述の為) あと、よくやるのがEUCでコンバートして出力していながら、CGIの他の 表示部分で違うコードを出力していたり(結構気付かなかったりします) プログラマーな人は、この様な無駄なトラブルを減らす為にALL EUCで 作る人が多いようですね。 >プログラミングのアイデアというかミソというか 自分の場合は、他人のスクリプトを解析することでいろいろ覚えました。 リファレンス以外はこの手法が一番お勧めです。 無駄を省いたルーチンは誰が作っても大体同じようなものになるはずです。 この掲示板のソースだってかなり勉強になるはずですよ(^^ゞ >>2166 かな 「使い方」を読むどころか、コピー文章ですね(^^ゞ ここまで典型的なのもはじめて見ました(笑) ところで、最近JAVAに嵌まっているようですが、JAVAはJavaScriptと perlとどちらに近い印象でしょうか？＞68userさん 敬遠していたJAVAも覚えた方がいいかなぁ、と思う今日この頃(^^ゞ |
|
>>2168 椎 > jcode::convert(\$str, 'euc'); > で化けていて，これを削除したら化けなくなりました。 > なぜでしょうか？ とりあえず, getcode 関数の戻り値を確認してみましょう。 http://www.mikeneko.ne.jp/~lab/kcode/jcode.html#h2-1 http://www.din.or.jp/~ohzaki/perl.htm#JP_Code >>2157 椎 >> スライス？ > すみませんが，意味がわかりませんでした。 ありゃ。すみません。 >>2158 68user > $file1[9] が正しい、ってことでしょう。 という意味でしたが, 断言する自信が無いのと もし, 意図的にやっている事ででしたら その理由が聞きたかったもので… ちなみにスライスについては http://www.context.co.jp/perlnews/bn/perl-newsletter-0010.html http://www.context.co.jp/perlnews/bn/perl-newsletter-0013.html が参考になると思います。 |
|
>68userさん 素早い回答と、明確のお答えありがとうございます。 使っている言語はperlで、秒数の設定により解決しました。ありがとうございました。 |
|
>>2170 68user > 一致しているなら jcode::convert は必要ありません。 必要ないということは，あってもいいのでしょうか。 つまりeucをeucにコンバートする処理をしても問題はないんですよね？ そうだとしたら，今回の問題はまだ解決できていないということですね。 >>2171 スナフキン > コピーしているだけであれば、椎さんの手抜きでしょうけど(^^ゞ ええ，その通りです。まだわからないことが多いので，とりあえず(^^; > そこそこの長文を表示すると、うそのように表示される場合 > が有りました。 そうかもしれません。ただ，短い文字列を入力するようにしていますので， 根本的に解決しないとダメですね。 > CGIの他の表示部分で違うコードを出力していたり イメージできないんですが，具体的にどんな場合でしょうか。 エディタでeucで保存するようにしているのですが， これだけではeucにならないものでしょうか。 > この掲示板のソースだってかなり勉強になるはずですよ(^^ゞ 機種依存文字の検出のところなど，参考にしたいなと思っていました。 とはいえ，今日初めてソースを見たのですが， 理解するのに，かなり時間がかかりそうです。 >>2172 /tk > とりあえず, getcode 関数の戻り値を確認してみましょう。 おお，これは使えそうですね。やってみます。 > ちなみにスライスについては なるほど〜。よくわかりました。 必要がないのにスライスを使っていたことになるわけですね。 意図的でなくて申し訳ない感じです。 |
|
こんにちは、はじめましてTOMです。 初級アマチュアプログラマーです。 ちょっと自分で解決できなかったので質問を聞いてください。 ・モジュールＡに、ライブラリlib30.soをリンクしています。 ・モジュールＢに、ライブラリlib40.soをリンクしています。 ・さらに、ライブラリlib40.soの中で、ライブラリlib30.soの中の関数Func09が 使用されています。 ライブラリlib30.soの中の関数Func09が修正されました。 再コンパイル、再リンクは、 全て（モジュールＡ・モジュールＢ・lib30.so・lib40.so） 行わなければならないのでしょうか？ よろしくおねがいします。 |
|
>>2175 TOM Func09 の引数の数や、引数の型、戻り値の型を変更しましたか? また、Func09 から他の部分のグローバル変数を参照するところ を変更しましたか? いずれの変更もしてないなら、ライブラリ利用側の再コンパイル・ 再リンクは不要です。 引数や戻り値を変えた (＝インタフェースを変えた) なら、 再コンパイル・再リンクのし忘れを防ぐため、メジャー番号を lib30.so.1 -> lib30.so.2 などと上げた方がよいでしょう。 >2174 >> 一致しているなら jcode::convert は必要ありません。 > 必要ないということは，あってもいいのでしょうか。 あってもよいです。僕は必ず jcode::convert は付けます。 > つまりeucをeucにコンバートする処理をしても問題はないんですよね？ 本来問題ないのですが、Shift_JIS の半角カナと EUC-JP を正確に 判別することはできないので、EUC-JP な半角カナを Shift_JIS の 文字列だと誤認してしまい、EUC-JP に変換しようとする、ということは あります。 一応 jcode.pl がエンコーディングを自動判別する際は、「Shift_JIS と して解釈できる部分の長さ」と「EUC-JP として解釈できる部分の長さ」を 比較して長さが長い方を採用しますが、もちろんこれでも完璧では ありません。 # たしか両方の長さが一致したら、EUC-JP とみなされたと思う。 > 必要がないのにスライスを使っていたことになるわけですね。 いいえ、@a[0] はスライスを使っているわけではありません (よね?)。 perl がおせっかいなので @a[0] -> $a[0] という読み替えをしている だけです。 % perl -we '@a=(100,200);print "@a[0]\n"' Scalar value @a[0] better written as $a[0] at -e line 1. 100 >>2171 スナフキン > ところで、最近JAVAに嵌まっているようですが、JAVAはJavaScriptと > perlとどちらに近い印象でしょうか？＞68userさん うーん、どっちも遠いですねぇ…。でもまぁ僕がやってるのは サーバサイドの方なので、どちらかと言えば perl ですか。 でも、perl とは似てないですね。 とにかくクラス設計が楽しいです。 |
|
すいませんでした。 以後気を付けます。。 |
|
はじめまして。 ネットワーク関係の関数でちょっと質問なのですが。 inet_aton(hostname)になっていますがこれをinet_aton (ipaddres) にしても問題はないのでしょうか？ hostnameが解決されていない場合、IPアドレスをそのまま 使用してみたのですが表面上問題はでていませんが、 内部的にどうかまで分からなかったので。 どなたか教えて下さい。 分かり難い内容の書き込みになってすみません。 |
|
>>2176 68user > # たしか両方の長さが一致したら、EUC-JP とみなされたと思う。 一致した場合は undef では？ > いいえ、@a[0] はスライスを使っているわけではありません (よね?)。 > perl がおせっかいなので @a[0] -> $a[0] という読み替えをしている > だけです。 http://www.ascii.co.jp/books/detail/4-7561/4-7561-3057-7.html を読んだうえでの僕の解釈は @a[0] はスライスです。 但し, 要素数が 1 のリストであり, スカラー値ではありません。 たまたま @a[0] をスカラーで評価したときに, その最後の要素である $a[0] が返されただけです。 となるのですが 例によって勘違いしている可能性大です。 |
|
>>217668user 68userさん インターフェイスの変更は、ありませんので ライブラリ利用側を再コンパイル・再リンクせずに利用できました。 回答ありがとうございました。 |
|
/tkさんが教えてくれた↓のページを読むと， > http://www.mikeneko.ne.jp/~lab/kcode/jcode.html#h2-1 ・convert()は内部ではgetcode()を自動的に呼び出し文字コードを判断する ・getcode()では，半角カナは文字コードの自動認識の判断対象からはずされる とあります。また，スナフキンさんが > そこそこの長文を表示すると、うそのように表示される場合が有りました。 と言われたように，私の場合も半角カナ以外の文字をある程度以上追加すると 文字化けしないことがあります。 例）アイウエオ（半角） →竺軸宍雫七（全角） アイウエオ（半角）あいうえお（全角）→アイウエオ（半角）あいうえお（全角） これらのことから，今回の文字化け現象の原因は，convert()が （正確にはgetcode()が）半角カナの文字コードを 正確に判別できていないことのようです。 これを調べるためにコンバートの前後でgetcode()をかけてみました。 $code1 = &jcode::getcode(\$str); jcode::convert(\$str, 'euc'); $code2 = &jcode::getcode(\$str); その結果，次のようになりました。 $str = 'あいうえお' → $code1 = 'euc'，$code2 = 'euc' $str = 'アイウエオ（半角）' → $code1 = 'sjis'，$code2 = 'euc' つまり，getcode()は半角カナの「アイウエオ」をsjisと判定して sjisをeucに変換する処理をしていたのです。 長々と書きましたが，68userさんが書かれたように， > Shift_JIS の半角カナと EUC-JP を正確に > 判別することはできないので、EUC-JP な半角カナを Shift_JIS の > 文字列だと誤認してしまい、EUC-JP に変換しようとする、ということは > あります。 ということのようです。 で，ここでどうするかというプログラム上のアイデアが問われるのですが， （残念ながら例の本には載っていません・笑） 今は，「$strに全角文字を数個追加して，コンバート後にそれを除く」ということを 考えています。 ただ，自分でもかっこ悪いなぁと思うので，他にアイデアがあれば教えて下さい。 >>2176 68user > いいえ、@a[0] はスライスを使っているわけではありません (よね?)。 私は/tkさんが教えてくれたページを読んでスライスを覚えたので No.2179の/tkさんと同じ解釈をしたのですが， この解釈の違いによって，使い方とその結果が変わるということが ないのであれば，あまり本質的な問題ではないような気がします。 68userさんが正しい知識を教えようとしてくれる気持ちはとてもありがたいです。 |