BBSご自由に書き込んでください。17:33:36Link:ご連絡ありがとうございます。正誤表を確認しました。ご対応、ありがとうございました。15:18:41Link:はじめまして。遅くなりましてすみません。*shape)>だと思います。これはこの本のテーマにもろに重なっているという点でかなりまずいミスでした。「わからない人は3章を読み返しましょう」って書いてあるのが我ながら余計に痛いです。正誤表に載せておきます。ご指摘ありがとうございました。C言語ポインタ完全制覇を読んだものです。非常にためになる本で、常日頃参考にさせて頂いております。今回は、この本に誤植らしきものがあるので、ご連絡致しました。*shape)だと思います。前者だとコンパイルが通りませんでした。以上、確認をお願い致します。01:56:14Link:>ぱさんの本で自分がポインターの何が解っていないか初めて解り>大変良い物だとありがたい限りですはじめまして。読んでいただきありがとうございます。>ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ>https://cdecl.org/紹介ありがとうございます。ポインタ完全制覇でも取り上げた、K&Rに載っているdclのWeb版ですね。思うのですが、自分で作れと言われそう。時間があれば、作ってみたい気はするのですが。20:00:11Link:>レスが付かないまま1週間以上たってしまったため、自己レスします。すみません、最近どたばたしておりまして、ちょっと気力がたまりませんでした。;でアクセスすると、>サーバからレスポンスコード301が返ってきており、>そこで指定されている移動先URLが文字化けしています。これはさすがに気付いてしかるべきでしたね。パケットキャプチャやFiddlerどころか、F12開発者ツールでわかるレベルの話です。言い訳しますと、>SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。...という確認をしていたのにリクエストは1回ずつしか来なかったので、リダイレクトは想定しませんでした。最初の1回はちゃんと飛んでたはずですが(過去投稿を見るとIEではそうだったとの記載もある)、今F12を入れて見てみると、2回目以後はキャッシュされてますね。「F12開発者ツール」とか、「変な動きがあればキャッシュを消せ」あたりはWebアプリ開発の基本ですが、どうもぼけてたようです。23:53:22Link:削除パスワードを設定していなかったため修正も削除もできないため返信します。前回の発言、一部間違っていました。ダウンロードしたのは再現テストの前、一番最初です。23:30:27Link:レスが付かないまま1週間以上たってしまったため、自己レスします。どっかで化けているとしたらブラウザだと思うのですが思い込みの罠にはまっています。いうか傍から見ると自分でフラグ立てていますよ。fidderをプロキシとしてブラウザとサーバの間に挟むと若干動きが変わりますが、パケット解析には問題ないです。]でアクセスすると、サーバからレスポンスコード301が返ってきており、そこで指定されている移動先URLが文字化けしています。;で、(サポートページから勝手にソースをダウンロードして)問題箇所を見ると、ServerThread.javaのpathの扱いが不注意なところがありました。25行目で、urldecodeプラスアルファ的なことをしていて、url文字列からPCで扱う文字列にしています。その後、54行目で、移動先ページの組み立てで、PCで扱う文字列となっているpathを(url文字列形式にせずに)そのまま使っています。urlデコードしてもしなくても変わらない文字列であれば問題が起きなかったのですが、今回はそのケースではないためエラーが見つかっちゃったんだと思います。23:47:50Link:なるほど。確かに自分で実装したTcpClientなら余計な補正は働きませんね。ありがとうございました。20:17:34Link:最初からガッツリ調べなくても最初はfiddlerでいいんじゃない?appgoatの学習でも使っているツールだし。02:39:34Link:ごぶさたしてます。>なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の>下位1バイト分に相当します。あ、気付いていませんでしたが確かにそうですね。しても、なぜ「日本語」の場合だけそうなるのは謎ですが......本件、Modoki/0.2はただソケットでデータを受け取るだけなので、さすがにどっかで化けているとしたらブラウザだと思うのですが、パケットフィルタリングもちょっと考えてみます。02:26:13Link:>過去の例にあったような「http://localhost:8001/../conf/httpd.conf」>をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような>動きをしてしまいました。HTTP/1.1」となっていましたので、というように(勝手に)変換しているのでしょう。{側の処理に流れ込むことが確認できます。20:11:03Link:本を持っていないため、推測となってしまいますし、外しているかもしれませんが。日本語のそれぞれの文字のUnicode符合位置は、[日]=U+65E5、[本]=U+672C、[語]=U+8A9Eです。「,」は、Unicode符合位置がU+002Cです。問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の下位1バイト分に相当します。この辺を手がかりに、パケットキャプチャすればどのタイミングまでは文字コードが意図通りとなっているかがのあたりがつくかもです。23:20:50Link:こんばんは。早々にご確認・ご回答頂きまして、まことにありがとうございます。当方でも様々な文字で確認してみましたが、やはり上手くいくときといかないときがあり、よくわからない結果となってしまいました。ブラウザ等の仕様に起因するところもあるかと思うので厳密には分からないかとは思いますが、もともとの目的である動き・仕様は理解できたので先に進もうかと思います。するには、どのようなGETリクエストを飛ばすと実現できるものでしょうか?過去の例にあったような「http://localhost:8001/../conf/httpd.conf」をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような動きをしてしまいました。HTTP/1.1」となっていましたので、サーバがGETリクエストを受け取った時には、pathが/conf/httpd.confとなっているようです。確かに、NoSuchFileExceptionが発生することが自然な動きのようにも思えます。以上、よろしくお願いいたします。19:53:57Link:はじめまして。ご質問いただきありがとうございます。OK(日本語配下のindex.htmlが表示)私も試してみましたが、正直、わけがわからない結果となっています。Edgeでは、/日本語の場合だけ、リクエストラインが以下のようになっています。HTTP/1.1これをデコードしても該当のフォルダは存在しないので、私が試した範囲では、404が返りました。;が正しいか確かめてください」のエラーになっています。HTTP/1.1になったり、リクエストが投げられなかったりしていることです。SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。11:45:33Link:はじめまして。基礎からのWebアプリケーション開発入門」にて実装したModoki/0.2の挙動について質問となります。Modoki/0.2では、'/'なしでディレクトリを指定するとリダイレクトさせる仕様となっております。そのため、「C:\Apache24\htdocs\」の配下にテストディレクトリ「test」と「日本語」を作成し、それぞれのディレクトリ配下にindex.htmlを配置して動かしてみました。実行結果は以下の通りです。OK(日本語配下のindex.htmlが表示)ブラウザはIEでもFireFoxでも同じ結果でした。デバッグモードで戻り値を確認してみましたが、MyURLDecoderは「/日本語」を返してくれていますし、realPathの取得時もNoSuchFileExceptionは発生していません。20:21:16Link:>webサーバを作ってみようページの以下リンクが切れております。ありえないほど遅くなりましたが、ご指摘ありがとうございます。Machineの存在を思い出したのでそちらに張りなおしておきました。10:16:34Link:webサーバを作ってみようページの以下リンクが切れております。23:00:12Link:>p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、>ここでcheck_nameという同一のパラメタが複数回登場しています。>つまり、チェックボックスを複数選択すると、この状況が発生します。>p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。>>テスト掲示板だけでなく、前の入力フォームにも対応できるよう書かれていたのですね。サーブレットコンテナを作っているのだから、こういう場合も想定しなければならないのに、どうも頭が固かったみたいです。お答えいただき、ありがとうございました。何かありましたら、よろしくお願いいたします。messageのことですよね。>1回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、ここでcheck_nameという同一のパラメタが複数回登場しています。チェックボックスを複数選択すると、この状況が発生します。p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。00:53:01Link:ご回答いただき、ありがとうございます。すればよいかと思います。>試してみたところ、これでうまくいきました。投稿内容の取得については、教えていただいた流れを追っていき、やっとわかりました。messageのことですよね。1回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。教えていただければ幸いです。01:51:19Link:はじめまして。>Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名>・メッセージの内のどこかが>未入力のままで送信を押すと、リスト3-17のServletServiceの28行目で>java.lang.ArrayIndexOutOfBoundsExceptionが発生します。・戻り値の配列の要素数は1で、[0]にだけ「a」が入るという仕様になっているためですね。すればよいかと思います。Henacatはあくまでサンプル実装なので、こういうエラーケース的なものの対処が甘いのはご容赦ください、と言いたいところですが、これはちょっと実用上問題がありすぎるので、後ほど正誤表に上げさせていただきます。ご指摘ありがとうございました。>あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も>保持しているという認識で合っているでしょうか?>しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は>保持できませんよね?parameterMapは毎回メソッドが呼ばれるたびにnewしていて、1回のリクエストごとに使い捨てです。resp);としてサーブレットのservice()メソッドを呼んでいますが、この呼び出しが、リスト3-26のHttpServlet.javaの13行目のservice()メソッドを呼び出すことになり、この中で、メソッドがPOSTの場合は(サブクラスの)doPost()メソッドを呼んでいますから(19行目)、これはつまりリスト3-6のPostBBS.javaのdoPost()メソッドを呼び出しています。ここで、新たにMessageクラスのインスタンスをnewして、staticフィールドのmessageListにメッセージをつないでいます。19:43:53Link:Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名・メッセージの内のどこかが未入力のままで送信を押すと、リスト3-17のServletServiceの28行目でjava.lang.ArrayIndexOutOfBoundsExceptionが発生します。keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、これはどこかコードを写し間違えているでしょうか?あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も保持しているという認識で合っているでしょうか?しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は保持できませんよね?基本的なところかもしれませんが、どなたかわかる方、教えていただけますでしょうか。文字列を返す様にカスタマイズされています。その経緯は、過去の開発>プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為>の策が、そのまま生き残ったもの、と聞き及んでいます。NullPointerExceptionは避けられるかもしれませんが、アプリの要件として絶対に値を入れなければいけないところを空文字にしてしまったら、バグの発覚が遅れるだけですよね。(この手のことは、拙著「センス・オブ・プログラミング!」で「バグのあるプログラムには生きる価値はない」として書かせていただきました)要件として、デフォルト空文字列でよいところは、コンストラクタ等で空文字列で初期化するのは正しいと思いますが。>「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には>妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い>ます(デバッグ鍛錬)。早合点なら、それでよいのですけれど。実際にメモリをバカ食いしている以上、どこかに何かの原因があるのかとは思いますが。進化したものと思いますが、>貴殿がもし、同書の改定新版を上梓したとき、「謎+落とし穴」は果たして減って>いるのか増えているのかが、気になるところでございます、Hi。JavaのGenericsはあれはあれで落とし穴が多いのですが、本1冊書くのはそれはそれは大変なので、当面おとなしくしていたいと思います。21:04:39Link:前橋様お返事有難うございます。お返事を頂けると思っておりませんでしたので、ホントに嬉しい限りです。熱心な貴殿の1ファンの応援メールと受けって頂ければ幸いです。文字列を返す様にカスタマイズされています。その経緯は、過去の開発プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為の策が、そのまま生き残ったもの、と聞き及んでいます。育ったプログラマーの資質の低下です。やらしても、モレや矛盾といったバグを仕込むことが少ないと思います。「ユーザーをバカにするシステムは、良いシステム」という、妙な格言紛いよろしく、「プログラマーをバカにするプログラミング言語は、良い言語」では困りモノです。「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思います(デバッグ鍛錬)。貴殿がもし、同書の改定新版を上梓したとき、「謎+落とし穴」は果たして減っているのか増えているのかが、気になるところでございます、Hi。15:25:27Link:はじめまして。閑古鳥な掲示板ですが、投稿ありがとうございます。>貴殿の「Java謎+落とし穴」は私の愛読書で、もう、10年以上も手許に置き、>休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き>です。プログラミング言語を作る」を読み込>んでみたいと思ってます(プログラミング工学の楽しい部分なのですが、>私にはチとハードルが高い)。ありがとうございます。「Java謎+落とし穴」は、さすがに今となっては内容が古いのですが、Tiger以前の本としては良く書けた本であったと自分でも自賛しております。80MB、>これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。『某社標準の「フレームワーク」』が問題なのでしょうか。ものを見ていないので何も言えませんけれども。>これに対する、若者の回答が問題なのだ。Exceptionが怖くて、それはできません。」NullPointerExceptionはバグがあるから起きるので、それ自体を避けたからといって問題の解決にはなりませんよね(『某社標準の「フレームワーク」』を使うと、どうNullPointerExceptionを避けられるのかはわかりませんが)。休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好きです。私にはチとハードルが高い)。UNIXサーバーの巨大システムを、Javaにコンバートする仕事をしております。仕事と言いましても、もはや定年までカウントダウンの身、第一線から引き、「相談役」みたいな立場で食い繋がせて頂いております。Javaプログラマとしての経験は浅いことを申し添えておきます。昨日、若者から以下の様な相談をされました。JVMが起動することができなくなる恐れがあります。なってしまうでしょう。20GBに達する、とのこと。80MB、これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。保安性、利便性?でガチガチに固められた、某社標準の「フレームワーク」準拠のスーパークラスをスーパークラスに、このシステムオリジナルの利便性をプラスしたもので、純粋なデータ部分のオーバーヘッドが酷いものと思われる。