マンガ短評

コメントを残す

「ビッグコミック」2009.1.10号

  • 『かむろば村へ』の連載が終了した上に、今号では『ゴルゴ13』『総務部総務課山口六平太』『築地魚河岸三代目』の長期連載三本柱が揃って不振。かなりの危機的状況で、早急なテコ入れが必要と思われ。
山本治作『そばもん』
  • ファミレスで知らない人同士が知り合うというのはやや不自然で、理解しにくい。
  • ファミレスという業態の内情からして、味を盗むとか盗まないとかという今回の展開は不自然。
阿部潤作『じいじい』
  • 最近流行の子育てモノ…の斜め上を行く感じ?
  • 絵が結構可愛く描けてるので、悪くはないんじゃないでしょうか。

「ビックコミックスペリオール」2009.1.9号

小山ゆう作『AZUMI』
  • なんだか紛らわしい題名。
  • 現段階では、駿介とあずみのどちらが語り手なのかちょっとよくわからない。視点がフラつくとあまりロクなことになりそうもないが…しかしまあ、ベテランの小山ゆうですから。様子を見ましょう。
森田崇漫画・北原雅紀脚本『ジキルとハイドと裁判員』
  • あれれ? 急にリアル路線に転換したぞ。
  • 『12人の優しい日本人』を思い出すが、一人一人の人物描写は遙かに及ばない。
倉科遼原作・玉置一平作画『空を泳ぐ女』
  • ここまで３回分を読んでの感想。仕事か結婚かという問題設定は身近で分かり易く、その意味では悪くなかったが、客観的に見れば、どちらに転んでもそう深刻な事態には陥りそうもないので、物語に切実さが不足したかも知れない。
  • 主人公の言っていることが妙に青臭く聞こえる。これは、主人公の動機に関する描写が不足していることを意味する。例えば、難民の子どもたち(だっけ?)がかわいそうだというのを、結論だけセリフで説明して終わりではなく、読者にも感じさせないとダメ。

マンガ短評

コメントを残す

「漫画アクション」2009年1月6日号

押見修三作『漂流ネットカフェ』
  • 『漂流教室』に似すぎていて正直如何なものかと思う。
川上弘美原作・谷口ジロー作画『センセイの鞄』「キノコ狩」
  • 現時点では『孤独のグルメ』後継作の最右翼。悪くない。
福満しげゆき作『うちの妻ってどうでしょう?』
  • 相変わらず可愛らしい奥様ですね。
森下裕美作『大阪ハムレット』「あいの探偵」
  • 前後編を通して読んでの感想だが、今回は視点のブレもなく完成度の高い出来。
  • あいの探偵を愛すべきキャラクターとしてきちんと描けたことが最大の勝因。
  • 欲を言えば、アリサと母親との対立構造を用いて、もっと話を盛り上げられたのではないかとも思われるが、短編という縛りの中ではこんなものか。
ドストエフスキー原作・落合尚之作『罪と罰』
  • 原作通りの展開なのだけれど、現代日本で検事が警察署に来て何かするというのはちょっと変では。
  • この人の描くキャラクターの演技はちょっとケレン味が強すぎる。もっと自然に。
はたのさとし作『セカイがもえた日』
  • もう少し分かり易く願います。

「ビッグコミック スペリオール」2009年1月1日号

森田崇漫画・北原雅紀脚本『ジキルとハイドと裁判員』
  • 訊かれもしないのに親切に設定を説明してくれる不自然な説明セリフが多い。説明も一つの行動なので、一応の動機・必然性は必要。…いや、それよりも、読者が求めていない情報を押しつけるのがつまらない説明ゼリフになる最大の原因か。
  • 定石だと、こういう話の場合は、本題に入る前に、「トントン」(パンダの名前みたいだな)が真実を述べる存在なのだということを説明し印象づけるためのエピソードが先行するのが普通。これを導入部と言う。本作のように「必要になった時点で」設定を導入するというやり方だと、作者の都合がミエミエになってしまう。
  • 青年誌なのだから、ハイドや「トントン」たちの設定にもう少しリアリティを感じさせる工夫が欲しい。外見も含めて。
  • 誤判をすると具体的に主人公がどう困るのかがきちんと描写されていないので、読者は誤判がまずいと理屈ではわかっていても、どうも気分的に今ひとつ盛り上がらない。そのわりに主人公は熱く悩むので、読者は置いてけぼりを喰ったような気になる。その辺をちゃんと描写するか、それともここは一旦そのまま有罪判決を出させてから、悲惨な被告人の姿を描写して改心させるか。何か工夫が必要。
  • 脇役のキャラクターの性格がきわめてステロタイプ的で、ありふれた行動しかしていない。
  • そのことも関係しているのだろうが、この人のキャラクターの演技も芝居がかり過ぎている。
  • なんだかボロクソにけなす形になってしまったが、まあ、まだ第１回なので。。。

wireshark 1.0.4

コメントを残す

今までOS標準の古いEtherealをだましだまし使ってきたものの、バッファオーバーフローの脆弱性などもあり、いい加減新しいバージョンに変えないとまずかろうと、重い腰を上げてWireshark 1.0.4にバージョンアップすることにしました。

OS環境が古いので、そのまま動くバイナリなどどこにもあるはずもなく、ソースのコンパイルからです。例によって、コンパイルするのに必要なライブラリ類の中に現環境に入っていないものが沢山あったのですが、そこはまあなんとか調達。

コンパイルを始めましたが、かなりソースの分量が多いようで、非力なうちのサーバマシン(Celeron 2GHz)では10分や20分では終わりません。そして随分待たせた挙げ句、

epan/.libs/libwireshark.so: undefined reference to `protm_item_add_subtree'

というエラーで止まってしまいました。

はて、何かライブラリが足りなかったかなと、とりあえず「protm_item_add_subtree」でGoogle検索したところ、ヒット0件。そんな馬鹿なと思い、ソース全体に対してgrepで「protm_item_add_subtree」を検索してみたところ、これまた該当なし。

ウームこれはまた面倒くさそうなトラブルだこと。と思いつつ、念のため「item_add_subtree」でソースを検索したところ、これは沢山ヒットします。で、それらの箇所を見ると「proto_item_add_subtree」と書いてありました。ゲゲッ。これはひょっとして…

コンパイルしているうちにメモリ(ひょっとするとHDDかも)上のビットに異常が生じてoがmに文字化けしたようです。案の定、make cleanしてから再度makeしたら今度はすんなり行きました。

うちのサーバマシンは静音をウリにしたASUS Terminator P4 ID1というのをベースにしたショップブランドPCで、これは確かに静かではあったのですが、昔から長時間CPU負荷を掛けたときの動作が怪しいのですよねえ。いい加減なハードウェアだなあ。

『大阪ハムレット』

コメントを残す

「アクション」2008/11/18号掲載分の森下裕美作『大阪ハムレット』第14回「テレパシー」、結構いい出来でしたが、視点(語り手)がフラフラしすぎではないでしょうか。一般論としては、別に視点を一人に固定しないと物語が成り立たないというわけでもないのではありますが、この話の内容では社長の視点に固定して話を進めていった方がよかったと思うのですが。その問題が顕著に表れているのが前編の最後で、ここは読者が社長と一緒にゾッとしないといけないところですが、物語冒頭が妻の視点で語られていて、妻があきらめの境地にあることが明らかになってしまっているために、そのようになっていません。

『かむろば村へ』

コメントを残す

『かむろば村へ』(いがらしみきお作)がついに完結しましたが、みなさんの感想はどうだったでしょうか。

私の感想を言えば、あの終わり方はちょっと不満ですね。カタルシスがないというか、メインプロットだったはずの「金恐怖症でもこの主人公は自立して生活していけるか」という点にはっきりケリがついた感じがしませんので。「なんとかなる」では物語の結末としては中途半端すぎないでしょうか。選挙やホームレスの話も、メインプロットにどう関わらせるつもりだったのか、わかりそうでわかりません。

qmailのReceivedヘッダがRFC違反に?

2件の返信

qmailの付けるReceivedヘッダが奇妙であることは、受け取ったメールのヘッダをじっくりと眺めたことのある方ならご存じと思います。しかしながら、これがRFC違反かという点については、以下の記事で説明されているように、一応そうではないということになっていたようです。

The myth about qmail-queue’s Received: headers being non-standard

ところが、このたびSMTPの規格がRFC 2821・2822からRFC 5321・5322へと改正されました。なにぶん長大な規格ですので斜め読みですが、どうもこの改正後の規格では、Receivedヘッダの規則が厳しくなったようで、例えば次のような(おそらくqmail特有の)ReceivedヘッダはRFC違反(非準拠)となったように見えます。

Received: (qmail 42078 invoked by uid 1004); 4 Nov 2008 21:10:19 +0900

参考までに、RFC 5321・5322記載のReceivedヘッダ関連のBNFを引用しておきます。

   Time-stamp-line  = "Received:" FWS Stamp 

   Stamp          = From-domain By-domain Opt-info [CFWS] ";"
                  FWS date-time
                  ; where "date-time" is as defined in RFC 5322 [4]
                  ; but the "obs-" forms, especially two-digit
                  ; years, are prohibited in SMTP and MUST NOT be used.

   From-domain    = "FROM" FWS Extended-Domain

   By-domain      = CFWS "BY" FWS Extended-Domain

   Extended-Domain  = Domain /
                    ( Domain FWS "(" TCP-info ")" ) /
                    ( address-literal FWS "(" TCP-info ")" )

   TCP-info       = address-literal / ( Domain FWS address-literal )
                  ; Information derived by server from TCP connection
                  ; not client EHLO.
   FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
                                          ; Folding white space

   ctext           =   %d33-39 /          ; Printable US-ASCII
                       %d42-91 /          ;  characters not including
                       %d93-126 /         ;  "(", ")", or "\"
                       obs-ctext

   ccontent        =   ctext / quoted-pair / comment

   comment         =   "(" *([FWS] ccontent) [FWS] ")"

   CFWS            =   (1*([FWS] comment) [FWS]) / FWS
   obs-FWS         =   1*WSP *(CRLF 1*WSP)
   domain          =   dot-atom / domain-literal / obs-domain

   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

   dtext           =   %d33-90 /          ; Printable US-ASCII
                       %d94-126 /         ;  characters not including
                       obs-dtext          ;  "[", "]", or "\"
   address-literal  = "[" ( IPv4-address-literal /
                    IPv6-address-literal /
                    General-address-literal ) "]"
   IPv4-address-literal  = Snum 3("."  Snum)

   IPv6-address-literal  = "IPv6:" IPv6-addr

   General-address-literal  = Standardized-tag ":" 1*dcontent

   Standardized-tag  = Ldh-str
                     ; Standardized-tag MUST be specified in a
                     ; Standards-Track RFC and registered with IANA

   dcontent       = %d33-90 / ; Printable US-ASCII
                  %d94-126 ; excl. "[", "\", "]"

   Snum           = 1*3DIGIT
                  ; representing a decimal integer
                  ; value in the range 0 through 255

   IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp

   IPv6-hex       = 1*4HEXDIG

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.
   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

   dot-atom-text   =   1*atext *("." 1*atext)

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

つまり、Received: のあとの「FROM ～」「BY ～」の記述はすべて必須になったわけです。

また、このような記述もあります(RFC 5322 4.)。

One important difference between the obsolete (interpreting) and the
current (generating) syntax is that in structured header field bodies
(i.e., between the colon and the CRLF of any structured header
field), white space characters, including folding white space, and
comments could be freely inserted between any syntactic tokens. This
allowed many complex forms that have proven difficult for some
implementations to parse.

つまり、改正後はスペースやコメントの入れ方が制限的になったということで、これにより、CFWSと書かれていない場所(例えばReceived: の直後)に、カッコで括って任意の文字列(例えば「(qmail 42078 invoked by uid 1004)」を挿入することもできなくなったわけです。

追記: qmail の RFC 違反
今回の話と直接の関係はないけれど。

追記2:
qmailに見られる

Received: from unknown (HELO vc3.example.jp) (210.233.64.45)
by mail.example.jp with SMTP; 4 Nov 2008 21:10:18 +0900

のようなヘッダは、新しいRFCの推奨事項に従うならば

Received: from vc3.example.jp ([210.233.64.45])
by mail.example.jp with SMTP; 4 Nov 2008 21:10:18 +0900

と表わすことになりますが、by～の前にはコメントが認められているため、前者もRFC違反とまでは言えません。

NNIPF 0.10のバグ修正

コメントを残す

私の愛用しているNNIPF 0.10に、Received: の行のfromに現れるアドレスが次のようにカッコにIPアドレスのみが記される形式になっていると認識されないというバグがあるようです。

Received: from p11014-ipadfx01hon.saitama.ocn.ne.jp (220.96.189.14)

Webインタフェースでは認識されているような表示になりますが、複数あるfrom行のアドレスのどれを選択するかの処理において無視されています。

PERL/NNIPF.pmのサブルーチンofficialIPを以下のように修正してみましたところ、一応正常に動くようになったようです(無保証)。

######################## from string returned by ReceivedFrom() to official IP
sub officialIP{
  my ($str)=@_;
  my $OIP="";
  if ($str =~ /.*\[([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\].*/) {
    $OIP =$1;
  } else {
    ($OIP) = $str =~ /\((?:[^@]+@)?([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\)/;
  }
#  my @h=split(/ /,$str);
#  if  ((defined $h[3])&&($h[3] =~ /[^0-9]*([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)[^0-9]*/)) {
#    $OIP = $1;
#  }
  return $OIP;
}

それにしても、一年ほど開発の動きが止まってしまっているのは残念ですね。

追記: IPアドレスが@付きの形式になっていた場合に認識できないというバグがあったので修正しました(2008.12.14)

ヤンダはよつばの兄

コメントを残す

8巻でヤンダ(安田)が「よつばの兄みたいなもんで」と自己紹介してましたけど、なるほどと思いましたね。位置づけとしてはヤンダはよつばの兄なんだ。

そうすると姉は誰なんでしょう。順当には恵那でしょうけれど、あんな良く出来た姉は現実にはそうそういないんじゃないかと。兄弟げんかの一つもしてこその姉妹、恵那は姉らしくない感じがします。かといって風香は母親っぽいし、あさぎはさらに年が離れすぎだし(ヤンダも同じくらいですな)