|
>>3347 pranky ファイアウォールがHTTP/1.1のCONNECTメソッドの使用を許可している環境で あればそれを使用すれば解決しますね。 CONNECTの使用ができない場合にはHTTPトンネルと呼ばれるソフトウェアを使用すれば 良いと思います。 私が以前作成したHTTPトンネルが http://www.jumperz.net/index.php?i=2&a=0&b=0 にあります。 68userさんのおっしゃる >2 も HTTP ではサーバプッシュができないので、純粋な意味での > 双方向通信は無理ではないでしょうか (サーバから不定期に > クライアントにデータを送るのは不可能だが、クライアントが > 定期的にサーバに接続し、そのレスポンスにサーバからのデータを > 載せるなら可能)。 を実装したものとなっています。 その他上記URLからリンクしていますが、C言語で書かれたGNU Httptunnelなど同じ種類の ソフトウェアがいくつか存在します。 |
|
名づけのページを作っています。 漢字の組み合わせで名前を作るため 例えば 亜xあyあい 井xい のようなデーターを作り while(<FILE>){ chomp; $key=$_; ($key,$values)= split(/x/, $_); $t3{$key}=$values; } のような連想配列に入れていました。 （色々と考えて漢字のデータはeuc,cgiスクリプトはsjisです） これを使って名づけのCGIをホームページで公開しているのですがある人から「治」という字が使えないとメールがありなぜかなと考えてみました。 ローカル（windowsXP）な環境ではキチンと表示されます。がプロバイダにアップロードすると使えなくなります。（wakwakとNETAGEどちらも） そこでアップロードして実験してみました。 @rkey= values %t3; @rkey2= keys %t3; これでキチンと配列が作られているか---連想配列は出来ていました。 次に $nnn='治'; &jcode'convert(*nnn,"euc"); $us=$t3{$nnn}; とやってみたのですがこれだと$usの値が見つかりませんでした。 そこで コードのせいかと思い単純に $nnn='治';#これはsjis &jcode'convert(*nnn,"euc"); として$nnnをHTML(euc)で表示したらコードの変換がうまくいかないようで文字化けします。 そこで $nnn='治'; &jcode'convert(*nnn,"euc"); $code=&jcode'getcode(*nnn); としてコードのチェックをしてみたのですが何もコードの判別ができないのです。 ちなみに違う漢字では上の実験はキチンと反応しました。 結果どうも治の文字コードの変換がうまくいかないように思うのですがどうしたらいいのかわからないのです。何かいい方法はありませんか？教えてください。お願いします。 |
|
>>3351 金床 金床さま、はじめまして pranky です。 ありがとうございます！ http tunnel で調べてみたところ CPAN に http-tunnel を実装した モジュールがありましたので、簡単なソフトを作成して AnHTTPD と 一緒に使用してみたところ、TCP が接続できました！ この方法で試してみます！ |
|
>>3350 セルゲイ > (1) 100M Full-Duplex > (2) 1000M Full-Duplex > が混在（共存）している環境を設定するには、どうしたらいいでしょうか。 100M な NIC と 1000M な NIC の 2枚差しではダメでしょうか。 って、まわりにギガビットな環境が全くないのでわからない んですけどね。 >>3352 落合 Shift_JIS の「治」は 0x8e 0xa1 ですが、EUC-JP の半角カナの 句点「。」も 0x8e 0xa1 だからです。 > $nnn='治'; > &jcode'convert(*nnn,"euc"); > $code=&jcode'getcode(*nnn); > としてコードのチェックをしてみたのですが何もコードの > 判別ができないのです。 jcode.pl を読めばわかりますが、理論的にエンコーディングの 正確な自動判断は不可能なので、 - EUC-JP として解釈できるバイト数 - Shift_JIS として解釈できるバイト数 を比べ、バイト数が大きい方を getcode の結果としています。 しかし 0x8e 0xa1 の場合はどちらも 2バイトなので判断がつかず getcode は undef を返します。 > 色々と考えて漢字のデータはeuc,cgiスクリプトはsjisです であれば、jcode.pl にエンコーディングを教えてやればよいです。 &jcode'convert(*nnn, 'euc', 'sjis'); # perl4 的な書き方 jcode::convert(\nnn, 'euc', 'sjis'); # perl5 的な書き方 と書けば、きっちりと Shift_JIS から EUC-JP に変換してくれます。 |
|
>>3344 Tsun > 共通鍵暗号のページで3DESでの鍵長が56*3にならない訳ですが せっかく教えていただいたので、勉強してみました。といっても 暗号技術大全 http://www.amazon.co.jp/exec/obidos/ASIN/4797319119/ref%3Db%5Fbb%5F1%5F25/249-2894126-9073950 を読んだだけですが。 「鍵Aで暗号化 → 鍵Bで復号化 → 鍵Aで暗号化」という方法を EDE (Encrypt-Decrypt-Encrypt) と言う。DES なら DES-EDE などと書く。 Encrypt-Decrypt-Encrypt が特に解読しづらいわけではないので、 Encrypt-Encrypt-Encrypt でも別に構わない。 ただ、EDE の利点は、鍵A と 鍵B を同じにすれば一度だけ暗号化 したのと同じ結果が得られること (DES-EDE に対応しておけば、 DES にも対応したことになる)。 なぜ 3回必要なのか、2回の暗号化 (つまり 2DES) ではダメな 理由はというと、2回の暗号化では中間値探索 (meet-in-the-middle) 攻撃に弱いため。56bit の DES で 2回暗号化した場合、総当たり 攻撃に限ると 112bit の強さを持つが、中間値探索には 57bit の 強さしかない。 3DES には鍵を 2つ使う方法と、3つ使う方法がある。 鍵を 3つ使う 3DES は総当たりに対しては 56*3=168bit の強度が あるが、中間値探索に対しては 112bit の相当の強度になる。 一方、鍵を 2つ使う 3DES は中間値探索の弱点はないため、総当たりと 中間値探索のいずれに対しても 112bit の強度になる。 よって、現実的な強さとしては鍵 3つの方が優秀である。 OpenSSL で実装されている暗号で言うと、 鍵2つの 3DES: des-ede-cbc(=des-ede), des-ede-cfb, des-ede-ofb 鍵3つの 3DES: des-ede3-cbc(=des-ede3=des3), des-ede3-cfb, des-ede3-ofb となる。 ただ、 > 鍵長と演算量の比は対数的ですから、112ビットの鍵を使って > １回演算するより、56ビットの鍵を使って、３回演算するほうが > 有利となります。 ここはよくわかりませんでした。DES の鍵は結局は 16ラウンド それぞれの 48bit 内部鍵の元となるだけなので、対数的ではない のではないかと思いました。 |
|
ども。おひさしぶりです。 これまでときどき私のlinux環境からDNSの名前解決ができない という件でいろいろと相談させて戴いていましたが、今回たまたま Redhat 9 publisher editionをインストールし試してみたところ、 なぜか無事名前解決できるようになりました。 もしかしたらこれまでインストール時に何かのチェックボックスに チェックを入れなかったなど、気づいていなかったミスがあったかも しれませんが、とにかく使えるようになりましたのでまずはご報告 します(もうしないかもしれませんが…^^;)。 というわけでこれまでいろいろアドバイスいただきまして、どうも ありがとうございました。これで晴れて開発環境を手に入れ、無事 プログラミングにいそしむことができます。今後もどうぞよろしく お願いします。 |