yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/11 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
不ラチな戦略
2006/07/11(Tue)23:01:28
 W杯が終わっても、オリンピックは夏冬で2年に1度ですし、何かその他のイベントがあればあれこれと。はあ。ではなぜ、私はここで疲れきらなければならないのでしょう。
 私は「W杯」そのものが嫌いなのではなく、「それによって様々な弊害がある」(重要ニュース取り潰し、他のニュース見づらい、「国民全員が盛り上がっている」のような見方をされる、時には「応援しない奴は非国民」と言わんばかり)のが原因です。要するに、応援(必ずしも「応援者」にあらず)のマナー違反に怒りを覚え、日本敗退やW杯終了を望むわけです。
 ではどうするか。W杯も五輪もそうですが、まず情報の「分煙」化が必要です。喫煙と違って周囲に毒を撒き散らすことはありませんから、応援することは構わないにせよ、新聞などという旧メディアはいずれ消えてなくなるからともかく、インターネットでまでトップにサッカーの記事をでかでか載せた挙句、社会面にまで載せられては困るのです。
 これは要するに、例えばディレクトリ検索エンジンで「プログラミング」のカテゴリを読んだとして、なぜかそこに「住まいのメンテナンス」とか「栄養満点レシピ」、下手すると「18禁調教ゲーム攻略法」とか称するものがゴロゴロ置いてあるようなものです。この場合「サッカー」のカテゴリに多くのサッカー情報を置くことは構わないのですから、そのようにしてください。
 そして次、WBCの時には「国民が1つになった」と称する不見識な議員がいました。なるほど、私は国民ではないようで。それは私は、仮に日本が他国に戦争を仕掛けようものなら、兵などにはならず、周囲の友人なり親族なりを巻き込んで早いところ安全な場所に退避することは確実でしょうが(こうすると無益な戦争を続ける戦力が減り、無能な指導者の崩壊を早め、国益につながる)、とにかく「日本人なら誰でも応援する」という論調はいかがか。
 こうした問題が解決されれば、応援者は全力で応援することができますし、私もそれによって被害を被らないのなら、日本を応援する理由はないにせよ、応援しない理由もありませんから、そうした人に対して「勝って良かった」などと話をあわせる程度はできます。私が日本敗退を願っていたのは、つまりは応援者と利害が対立していたわけです。
 これは「非ゼロ和」に持っていくことができます。つまり、何らかのイベントによって他の情報を潰さず、暗黙に応援を求めるような不見識なコメントを政治家などが行わなければ、私にとって日本が勝った際の利益はゼロ、負けてもゼロです。逆に、応援者にとっては勝てばプラス、負ければゼロまたはマイナスですから、日本が勝つことが最も利益が大きくなります。
 現状では、私にとって日本が勝つと実害が生じてマイナス、負ければプラスまたはゼロです。応援者はこの反対であり、互いに望む勝敗として「私:日本の負け - 応援者:日本の勝ち」が飽和状態となります。これでは対立も起きるわけで。こういう状態が続くようでは困るのです。とはいえ、情報を流す側のゲスゴミっぷりは今に始まったことではありませんから、当面この図式は続くのでしょうが。頭が痛いです。

 北朝鮮決議。正直言ってガッカリです。実は私、政府が決議を強硬に推し進めた時から2つのルートを考えていました。1つ目は決議が本日修正なしでバシッと提出され、中国が応じるにせよ拒否するにせよ日米で制裁を強化するパターン。拉致解決にはこれが最善でした。そしてもう1つについてはこれより説明します。
 小泉総理の「意中の人」は安倍氏です。つまり、福田氏よりも弱者チョンパ政策をしっかり継いでくれると考えているのでしょう。小泉総理が弱者チョンパを継がない人に地位を明け渡そうと考えるわけがありません。そこで、様々な「安倍持ち上げ策」を用い、支持をちまちま増やしておく作戦に出ました。
 そこで渡りに船とばかりに、北朝鮮がミサイルを叩き込んできました。福田氏は北朝鮮問題の面で不安がありますが、安倍氏は少なくともリップサービスでは北朝鮮を批判しています。今回のミサイルについても、「官房長官」を使った派手なパフォーマンスによって、「決議で制裁だ」「中国が何と言おうが出す」と言い出しました。
 これに世論の一部は過敏に反応、安倍支持が広がりました。ところが、実際には最初から決議を出さない、あるいは拘束力の薄いものを出すのが狙いであった日本政府、決議を出すのを延期し、「妥協の可能性もある」と言い出しました。これが今回の北朝鮮問題の真相、所詮は安倍氏に支持を集める道具に過ぎないのです。
 これを裏付けるものとして、安倍氏は「決議に妥協することがあっても、ミサイル技術の売買禁止については譲れない」ととんちんかんなことを言い出しています。日本にとって最も大きいのはハリボテミサイルではなく、拉致問題です。ミサイル技術は売り買いしなくても、自前で失敗するようなモノ作っているのですからあまり関係ありません。そもそも「売買するな」と言っても、ならず者国家が聞いてくれるわけがありません。
 ですから、譲らないのはミサイルではなく「制裁」であるべきなのです。なぜか決議案から「資金」を削除してしまいましたが、これが重要です。「資金」「物資」「エネルギー」などを制限しなければならず、これら全部を骨抜きにしてミサイルだけ規制しても意味がありません。拉致も解決しません。
 残念ながら、今のところ日本政府の対応は2つ目のルートに完全に合致しています。安倍氏の、安倍氏による、安倍氏のための制裁議論です。これは「うがった見方」では決してありません。これまでの日本政府動向、安倍氏・小泉総理の行動パターン、類を見ない強行制裁論からして、十分予想できるものです。
 元から安倍氏支持の人は良いでしょう。しかし、前まで福田氏支持で今回安倍氏に衣替えした人(全体では5%や10%といったところ)、あなた方は詐欺に気をつけた方が良いでしょう。こういう人が振り込め詐欺のようなのに栄養を与えているから、詐欺がなくならないのです。拉致も安保も総裁選の道具とは。

 突然ですが。encode.pmとcgi-lib.plの併用もやめましょう。Encode::Guessに関しては、文字コードセットを最初から指定できるので安全と考えていたのですが、asciiやUnicodeに関して判定を行うらしく、勝手にUTF16LEと判定してくださいました。
 しかも不可解なことに、こうなるとなぜかサーバーエラーを引き起こします。その部分だけ取り出したプログラムでは再現性を得られていませんが、どういうわけか。どのみち、仮に動いたとしても、データは破壊されていますので、cgi-lib.plで切り分けたデータをencode.pmでエンコードしては絶対にいけません
 そもそも\0で区切るというのは、Unicodeの時代にあって時代遅れな方法なのでしょう。代替手段は色々考えられますが、カンマやタブで区切るというのが最も楽な方法です。PHPではフォームの名前に「name[]」のようにカッコをつければ配列にしてくれますが、Perlでわざわざこれをやるのもどうかと。
 とすれば、例えばこういうのが考えられます。
# $name = 名前 , $value = 値
if(!defined($hash{$name})){
	$hash{$name} = $value;
}elsif(ref $hash{$name}){
	my $r = $hash{$name};
	my @arr = @$r;
	push(@arr , $value);
	$hash{$name} = \@arr;
}else{
	$hash{$name} = [$hash{$name} , $value];
}
 が、何と万能なやり方、と感心するのは早すぎます。これ、要するに「2つ以上のデータを配列にする」のですから、同名チェックボックスなどが2つ以上チェックされている限りは
$hash{'name'}->[0];
$ref = $hash{'name'};
@array = @$ref;
 などのようにしてアクセスすることができます。しかし、1つしかチェックされていない場合、$hash{'name'}を読まなければならず、どちらも別の読み方を使うことはできません。さらに、ユーザーが送ってくるデータが信用できないことに基づけば、あらゆるデータは複数の値を持つ可能性があり、あらゆるデータに対してリファレンスチェックが必要になります。
 無論、例えばあらゆるデータを$list{'name'}->[0]に格納し、それへのリファレンスを$hash{'name'}に格納する、という手も考えられます。しかし、そのつどデリファレンスが必要であるなど現実的とはいえません。そもそも複数選択系のフォームなど多くないのに、これではムダというものです。
 開き直ってPHP風に書いてみますか。
my $refname = "$name\[]";
if(ref $hash{$refname}){
	my $r = $hash{$refname};
	my @arr = @$r;
	push(@arr , \$value);
	$hash{$refname} = \@arr;
}else{
	$hash{$name} = $value;
	$hash{$refname} = [\$hash{$name}];
}

# 使い方
# 普通の変数
print $hash{'name'};

# リスト
my $arr = $hash{'name[]'};
my @array = @$arr;
foreach(@array){
	print "[$$_]";
}
 この「名前[]」の形式の変数には全部スカラーへのリファレンスが入っています([]なしの名前のハッシュには先頭の要素のみが格納されますが、これへのリファレンスが入るため、片方に変更を加えればもう片方にも反映されるようにするための工夫です)。ですからデリファレンスを忘れると動きません。
 これだとコード変換バグの可能性は減りますが、取り扱いはなかなか面倒です。やはりカンマ区切りにでもしておいて、カンマが必要そうなら後で考える、というのが良いでしょうか。それにしても、cgi-lib.plとEncode/Jcodeが併用できないとは。multipartデータをさばけない初心者〜中級者の方、だいぶ困ってしまうのでは。
 とにかくcgi-libに頼るのは危ないですから、今後画像転送系のプログラムをPerlで書く(今のところ予定はありませんが)場合、自作ライブラリを用いることにします。あれなら区切り文字もいくらでも変更できますし、仕様も好きなようにできます。また、コード自体をCGIスクリプト内に取り込めば、ライブラリなしで動きます。
 とりあえずはブログからjcode.pmに関するコードを取り去り、代わりにEncodeを使うコードを持ってきました。Encodeが使え(わ)ない場合には、私が先に作ったライブラリで自動認識と変換を行います。このサーバーではEncodeが使えますので、それを使うことにしますが、トラブルが出なければ良いですが。
 ローカル環境でUTF-8のトラックバックを投げてみたところ、どうやら正しく動作しているようではあります。
 それにしても、各種ライブラリで文字コード名が違うのは何とかならないものか。jcode.plの流れを受け継いだjcode.pmでは「sjis , euc , jis , utf8」などであり、Encodeでは「shiftjis , euc-jp , 7bit-jis , utf8」、この混乱がつくづく嫌になった私は、自作ライブラリで「sjis/shiftjis/shift_jis , euc/euc-jp/eucjp , jis , utf8/utf-8」など全部対応にした上、自動判定結果をどのフォーマットで返すかも指定できるようにしたのではありますが、問題はトラックバックのcharset値。正規表現で拾い、それぞれJcodeとEncodeの方式に変換しています。

 それにしても、Perlは深すぎます。私が見てきたことなど、琵琶湖を見て海を語るようなものです。潜在力はC/C++より上でしょう(要するに「分かりづらい」のですが)。その点、C/C++の参照(ポインタ)は覚えるまでが極めて大変ですが、ルールが統一されていて分かりやすいです。
 ただ、「char ***str[8][32];」のようなのは(普通の人ならこういう書き方はしないでしょうが)カンベンして、とも言いたくなるというものでして。オブジェクトでvirtual宣言があったりすれば、さらに混乱します。「object[6][13][2]->function(); /* ※ function() : 仮想関数 */」とか、どの関数が呼ばれるか分かったものではありません。多次元配列の中でも、オブジェクトをやたら多次元にするのはやめた方が良いでしょう。メモリも食いますし。
 本当はSQLまで書いておきたかったのですが、色々検証して力尽きました。ここまでにしておきます。
カテゴリ [開発魔法][社会問題] [トラックバック 1][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

Trackback(1)
漢字バトン(from ブログ@うにうに画像倉庫) - 2006/07/12(Wed)00:28:37
Knew様から、お返しに漢字バトンを頂きました〜。お友達のみの公開ブログだった様な気がするので、参考はとりあえずなしで・・・。本サイトの再開準備中だそうです。復活待っています。WEBバトンなら、ドンドン回して下さい・・・いや、ちょっと最近多すg(ぁ特に、持ち込んで..


- Blog by yamicha.com -