Archive for » 5月, 2012 «

Google … still not be evil.

最近とみに not evil じゃないのではないか? is evil じゃないか? という声も聞かれるGoogleですが、、、

小飼弾のニコ生サイエンス 「グーグル潜入映像も公開。『中の人』が明かす検索技術の未来」 – ニコニコ生放送
http://live.nicovideo.jp/watch/lv92787473

なかなか興味深い内容だったのだが、総合した印象としては「Googleの中の人は依然としてちゃんと “Don’t be evil” だということ」は分かった。
と同時に「”Not be evil” なだけでは “not evil” では居られないのじゃないか」という印象を強くした。
それだけビッグデータを握っているというのは、金が一定量以上集まると人智を超えたEvilな振る舞いが出現するように、自分たちはevilでないよう振る舞ってもevilの罠に落ち込む危険性は小さくないのでは?と思わざるを得なかった。
賀沢秀人氏が無邪気だっただけに、逆にevilさが怖くなった、と言って分かってもらえるだろうか?

繰り返すが、Googleは “Don’t be evil” である。これは疑う必要はない。問題はここにはない。

2012年5月20年 23時07分 追記:
だからと言って、そこに人為が入るのはもっとevilになる、こっちの危険性の方が大きい。これも確かだと言える。
だから難しい問題なのだと。

印象誘導の典型「幇間論法」

これを幇間話法と名付けよう。

元官僚の古賀氏の発言が不穏当(または不適切)だとの批判が集中しているが、この動画を見る限りに於いて問題なのは古賀氏であるよりもこの玉川徹って野郎(および雇い主であるテレ朝)ですぜ、皆さん。

過去にTVの取材を何度か受けた経験から、ここで池田信夫氏が述べている通り「言わされてしまった」可能性が高いと思う。 彼らの取材の仕方の定石として
「もし、仮に、、、”仮に” ですよ。仮定として、可能性として “こういうことが考えられる” という、あくまで仮説として○○ということは考えられませんか?」
(○○の部分は具体的に述べてしまうと,後で「あれは言わされたんだ」と言われてしまうと拙いので、あくまで抽象的に匂わせるように、あくまでぼかした、だが確実に匂わせた言い方をする)
と自分たちの言わせたい(言って欲しい)コメントを言わせるよう言わせるよう、しつこいくらいに誘導的訊ね方をする。 [1] 更に都合の良い部分だけを編集で切り貼りするのは周知の通り。
とはいえ、官僚時代からこういう彼らを相手した事ない筈はなく、誘導的訊き方をする事は知っていない筈のない古賀氏の場合、迂闊との非難は最低限逃れ得ないだろうが。

冒頭部分の玉川徹のことばを書き起こしてみる。

つまり、だって関西だって、例えば、もしかしたら、国民感情の反発とかがあってね、原発動かないかも知れないって、私だって思ってた訳だから・・・だったら供給責任があるんだから、こっち(筆者中:関西電力)だって増やしておかないといけないんじゃないかなと、いう風に、思うのが普通だと思うんですけども・・・

こう書き起こして「書き言葉」になると「あれ? なんか詭弁」と分かるのですが、ここが「話し言葉」の怖いところ。

巧妙なポイントその1・・・断定を避ける

注意深く観れば(聞けば)分かる通り、この玉川なる吾人は一切断定を巧妙に避けている。曰く「例えば」「もしかしたら」「とかがあって」「かも知れない」・・・。

巧妙なポイントその2・・・「私だって思ってた訳だから」

これを幇間話法と名付けよう。 「私だって」つまり「私ごときが」 → 「私程度の人間でも」 → 「私程度の低レベルな人間でも」そう思ったのだから、私より賢い皆さんが思わない訳ないですよね。と相手の自尊心を楯に取って「いや、違う」と言い難い空気を作って封じておいて、同意したかの如く話を先に進める(実は同意していないのだが同意したような気分にさせられてしまう → 「Noと言っていないのはYesの意思表示論法」)。
しかも、これはポイント1の「断定を避ける」と組み合わさることで巧妙さを増す。つまり「私は断定できるほど賢い人間ではないのでああいう言い方をしたけども、あなたは賢いのだから・・・後は云わなくても分かりますよね?」と言外に言っていると仄めかしているのである。 インテリぶりたい虚栄心の強いプチ・インテリほどこの仄めかし(誘導)に乗せられてしまいやすいのは、ご想像の通り。 [2]
これは(男性もするが)女性が用いることの多い話法で、曰く「国立大学を卒業なさっている○○さんは、三流私大出身の私なんかより世の中のこともよくご存知でしょうから、こんなこと知らない筈ないですよね?」という風に。だから引用の記事にての池田氏の「専業主婦」云々は不穏当で非難を呼びやすい表現であるかも知れないが言っていることは強ち間違っていない。 普段からこの話法を使い使われして適応している人ほど、この話法の罠にはまりやすいので、主婦層をメインターゲットにしているこの手の番組でこの話法を使うのは合理的と云えば合理的。

巧妙なポイントその3・・・「だったら供給責任がある」

この前段までは「例えば」「もしかしたら」「とかがあって」「かも知れない」と仮定(実際には話者>玉川徹の私見、予断)だった筈の話が、この「だったら」という接続詞を用いることで既定事実であるかのように印象がここで変わっているのに気付かれただろうか。 更にこれに「供給責任」という言葉が結び付けられていることで「供給責任があるのだから、”もしかしたら、国民感情の反発とかがあって、原発動かないかも知れない” と考えて当然だ」と帰納的に考える誘導をされているのである。 これは論理的には正しい帰納ではない(つまり帰納でもなんでもない)。のだが、この手の誤った帰納は情緒に於いては寧ろよくあることなのである。
では何故、こういう論理的に考えられればおかしいと気付く論法にまんまと引っ掛かるのか。それは「人間の脳内の情報処理は論理に依るより “イメージに” “より根源的に依拠” するから」である。 論理はあくまでイメージを事後的に整理、分類、分析するための補助機能でしかないのです。

上記3ポイントを駄目押しする「のが普通だと思うんです」

この「普通」という言葉。 通例、「自明なこと=改めて説明するまでもないほど明らかなこと」を述べる時に使う接頭辞で、この点に於いては洋の東西を問わず共通。 英語でも「ordinary」「commonly」「normally」という表現があるが、欧米圏では自明であるとコンセンサスが成立していない事象に対して迂闊にこれを使うと即座に「お前の云う “普通” とは何に基づくのか?」「何を称して “普通” と云うのか?」「”普通” と云って良いほどコンセンサスは成立していないと思うが?」と突っ込まれる。
欧米圏のようにきちんと明示的にコンセンサスを積み上げる文化の脆弱な日本でも「自明な事=普通」という表現が使われるのは論理的に考えればおかしいことであるが、日本人>同質幻想に基づいているのだろう。

ここまでの私の分析を読んだ上で古賀氏のインタビュー部分だけを観たら、随分印象が違ってくると思うのだが、どうだろうか?
再度繰り返すが、如何に誘導されたにしても、ここまで言ってしまった古賀氏は批判されて当然である。この点は誤解なきように。

原発関連で、この手の詐術的、欺瞞的レトリックを駆使している一番有名人である安冨歩と同時期に京大に通っていたのは単なる偶然だろうか?

以下 wikipedia より
玉川徹
1987年、京都大学農学部農業工学科を卒業し、1989年、京都大学大学院農学研究科修士課程を修了

安冨歩
1986年 京都大学経済学部卒業
1991年 京都大学大学院経済学研究科修士課程修了
1993年 京都大学人文科学研究所助手

——–[ 脚注 ]—————-
  1. 個人的印象と断った上で述べると、この誘導的傾向は、TBS系(含む毎日)、テレ朝(朝日放送は含まない)が特に強い。
  2. 「東京電力の方がましに思えてきた」とコメントする女性コメンテイターは、まんまとこの操作に乗せられている。もちろん、予めこう云うように打ち合わせていた可能性もある

「適度」な大きさがあるというのは何でだろう

さっき、つぶやいたとこなので二階屋を建てるエントリーなのだけど、、、


3 → 3G の時も、4 → 4S の時も出てきたほとんどBuzz Wordな話題であるとは言ってしまえばそれまでだが。

弾さんのコメントを援用するまでもなく、、、Galaxy S II を買った(買わされた?)老年の知り合いに「使い方がイマイチ分からんので教えてくれ」と頼まれて(「なんでiPhoneユーザのわしが教えなアカンのや!」とは言わずに)操作してみたことがあるのだが、文字通り「手に余る」のを実感した。 ほんの1センチちょっとの差なのだけども、この「ちょっとの差」で実に大きいと感じる。

人間には、或る範囲、または或る領域に於いて「やたらと敏感な帯域」(と「そうでない帯域」)があって、、、例えば青色(藍色、紺色)、或程度以上大量生産されている製品だとロットが違えば厳密には全く同じ色目というのは有り得ないわけで、我々がそれを同じ色と感じる許容範囲に納まっていると「同じ色」としてもらえる(察知できないのだから同じ色と言って差し支えない)。という約束事で現実は成り立っている訳だが、そのアイテムが定番商品で長い期間、同じ品番・型番で販売されている場合など特に(こういう場合愛用者が多いということもあって)「以前買ったのと色が違っている!」とクレームが発生しやすいのが青色だと、青色の場合が特にその色目が違うと敏感に察知されやすいということが,特に色目の違いが問題とされやすいアパレル業界ではつとに有名。
で、しかも、これの厄介な(場合によれば「便利な」でもあるのだが)点は、単に察知される(察知できる)か否かの問題だけではないという点・・・つまり、察知しても然程気に留めずにスルーできる要素とスルーできない要素があるということ。 スルーできる要素は、違いを最初察知しても時間の経過と共に「慣れる」こと=「なかったことにしてしまえる」のだが、スルーできない要素はその違いを無視することが、かなり努力しないと出来ない。
[amazonjs asin=”4534045220″ locale=”JP” title=”小飼弾の 「仕組み」進化論”]
「片手で持って、手の中で操作できるかどうか」も,これと同じくほんの些細な差で許容できる/できないのが決ってくるのだろう。

こう考えてみると、平均的に体格の東洋人よりも大きい欧米人文化圏でデザイン検討されているものなので、彼らに合わせてもう少し大きい(日本人からみれば大き過ぎる)サイズに落とし所があっても良さそうになのに、このサイズでそもそも出てきたことに注意を払うべき。
私の見解は(手の中の操作範囲に於いては)「内的イメージ(脳内イメージ)は実サイズには依拠せず、然程差なく同じサイズなのではないか」なのだが、如何だろう?

ことえり は実は結構賢い

10日ほど前のアップデートでGoogle日本語入力がバカになった。具体的には「今までの変換結果から学習している筈の語彙が出てこなくなった(リセットされてしまった感じ)」「歴史上の人物など著名人の名前が候補に挙がってくる率が極端に下がった(ゼロではないが限りなくゼロに近いくらいになった)」「入力中のもの、および直前に入力した文節の文脈を解析して適切な単語変換をする機能の的確さが極端に低下(全く機能していない訳ではないが、的確さが著しく低下)」。
これら全て充分以上に機能していれば使うメリットになる・・・つまり機能しないなら使うメリットはないということになる。

拙のIM(Input Method)の遍歴は、ことえりがまだおバカだったMac OS 9.x 以前 ATOKを使い出してからずっと「ATOK派」だったのだが、Mac OS X 10.4 時代に度々起こるOSの不可解な挙動に悩まされ「ATOKはOSの深部にアクセスしてて色々と予想不能のトラブルの元になる動作をする」という、これ自体は真偽の程がイマイチ確認できない情報ながら、実際Mac OS X 10.4をクリーン・インストールし直してATOKを入れない状態にしたらピタリと、その不可解な症状が一切出なくなったという経験をして以降、ATOKは信用しないことにしたので、これ以降はegbridgeを使用していた。

ATOKと違ってOSの動きをよく理解してこれに不協和無く動作していると感じる「いかなる場面でも軽快」に動き [1] 、今では当たり前になりつつある入力している前後の文脈をよく読んだ的確な変換など申し分無いIMだったのだが、ご存知のかたはご存知の通り、Mac OS X 10.5対応版をリリースした直後にエルゴシステムが開発終了を発表し [2] 先行きが怪しくなってしまった。
「動かなくなるのでは?」という心配も、Mac OS X 10.6リリース当初は杞憂に終わり、egbridgeは正常に動いた。
が、Safari 5 リリースに伴ってWebKitモジュールの仕様が変わった時点からSafari、MailなどWebKitベースで描画するアプリケーションではコンフリクトを起こして異常終了を起こすようになってしまい [3] 万事休す。
折も折、丁度良いタイミングでGoogle日本語入力がリリースされ、試しに使ってみると結構使い勝手も悪くなく、無償であるということもあって、これ以来Google日本語入力を使い続けてきたわけです。

が、ここに来て、冒頭の通りの「こりゃ使えないわ」状態に遭遇し、Mac OS X デフォルトの ことえり に戻ってみることを決意したわけです。

知っている人は知っている話として、ことえり は実はMac OS X 10.4の時点のバージョンで結構賢くなっているのです。
また更に、賢くなったと言っても、こここそ「実は」、単文節で区切ってちょこまかと変換する昔ながらの使い方をすると「そんなに賢くないじゃん!」と思ってしまう羽目になります。

そう! 短い文節で変換をしてしまわずに、長い文節をタイプして一気に変換をする(スペースを押すのを極限まで我慢する)とかなり的確に変換してくれるのです。 使い始めはへんてこな変換になる場合はありますが、これは単語と単語の区切りの判別が間違っていることに起因していますので「shift + 矢印」で正しい区切りを教えてやることで、あなたの使う言い回しに即した区切り方を覚えていってくれ、使っているうちにすぐに快適になっていきます。
この「単文節で変換をせずに長文節で変換を掛けるようにするとかなり賢い(賢くなる)」という話も私はMac OS X 10.4時代に既に聞いていたのですが、今回のこの件で改めてググってみたら、この情報は「無くはないけども然程散見されない」という程度にしか認知されていないみたいなので、改めて強調しておこうと、まずこれが今回このエントリーの主眼の一点目。

次に、
Mac OS X のバージョンが10.6に上がった時に頻発した(これはYahoo!知恵袋などあちこちで発見でます)「タイプに文字トラッキングが着いてこない」というトラブル。具体的には「ことえり」と入力しているのに、画面描画が結構モタついた揚句に「oり」みたいに「キー入力が欠落」した感じ(あくまで一例)になる、特にSafari上でのテキストエリアへの入力時にかなり高確率で発生。という現象。

ググれば直ぐに発見できますが、これの定番対処は

Macintosh HD/ユーザ/[あなたのアカウント名]/ライブラリ/Preferences
の中の「com.apple.JapaneseAnalysis」フォルダ丸ごと、および
「com.apple.inputmethod.Kotoeri.plist」
「com.apple.KotoeriPreferences.plist」
「com.apple.KotoeriWordRegister.plist」
・・・つまり「ことえりに関連する初期設定ファイル類すべて」を削除して一旦ログアウト → ログインし直す。

このトラブルは実は、Mac OS X 10.6 以前からの環境を引き継いできている場合に発生するもので、なので古い初期設定ファイル類を一掃すると解決するというわけです。(Mac OS X 10.6 からMacを使い出している人は、多分遭遇する率は極めて低いと思います)

なのですが、上述の経緯でことえりを使いはじめると早速この症状が出たので上記の対処をした。
のにも関らず、念の為再起動までしたのに、ことえりをSafari上で使うと『画面描画がモタついた揚句に「oり」』となりやがって、、、思わず「おーいっ!」と叫んでしまった。

egbridgeを使っていた時期から、何かトラブった時の事後の策としてegbridgeに登録されてある辞書をテキストに書き出してことえりのユーザ辞書に読み込ませていたのですが、こいつがどうも破損していたみたいで、これを「Dictionaries」フォルダから外してログインし直すと症状は消えました。 旧環境、特にMac OS X 10.4 以前からのことえり辞書を引き継いできている人は問題が起きたときは、これも疑って下さい。

今まで貯めこんできた語句の蓄積の辞書を捨てるのは忍びないという方、ご安心を。
字句入力&変換には支障をきたす破損をしていても、ことえりの「単語登録/辞書編集」から「テキストへ書き出し」は出来るケースが少なくないですので、破損してる疑いのある当該辞書を「テキストに書き出し」てから、その辞書を破棄し、改めて新規に辞書を作成し(これも「単語登録/辞書編集」から)て書き出したテキストを読みこませ直すと一件落着です。
「テキストの書き出し」も出来ない破損をしている場合は、ごめんなさい。諦めてください。

人名、地名などの固有名詞は(案外と出てくるけど)やはり弱いので、以下などを参考に辞書をプラスするのが吉。

MacBookの憂鬱日記:ことえりを賢くする(1)
http://fukafuka.naganoblog.jp/e272116.html


2012年5月15日17時10分追記:
本エントリーを書いて「昔に比べてちょっとは改善してるんかいな」と気になったので(書いていることと相反するかもですが)ATOKの最新版の試用版をダウンロードしてインストールしてみたら、インストール&再起動後・・・レインボー・カーソルが一挙動毎にクルクル回って激重に。確認の意味で再起動し直してログイン項目等一切登録していないサブのアカウントでログインしてみると一応問題なく動きはしたものの、Safariを起動してみるとページの読み込みが異常に遅い。「メモリー食いで動作が重い」という点は何にも変わっていなく「他のアプリケーションとの兼ね合いを考慮に入れていないだなぁ」という印象。 IMはOSはじめあらゆる動作の邪魔をせず「ひっそりと」だが「確実に」動かないといけない。 使い物にならないのみならず動作の足を引っ張るので即アンインストールしたのでが、アンインストール&再起動後、HDD内を調べてみると、機能拡張やプラグイン的ファイル、初期設定類などなど、わんさかと残したままだった(辞書を残すのはわかるが)。ファイル容量にしたら僅かで単なるゴミの初期設定ファイルはまぁ良いとして、起動時に読みこまれる機能拡張を残したままなのはどうなん?

「Macintosh HD/ユーザ/[アカウント名]/ライブラリ/Application Support/Google/JapaneseInput フォルダを削除してログインし直すと復帰するのでは」とtwitter経由で教えてくれた方があったので念のために試してみたが、特には改善は見られなかった。 個人的には落語家の名前が(古参に限らず新人でも)ほぼ一発で出てきてたので重宝していたのが残念。
Google日本語入力はプライベート・モードにしていない限り、入力変換した語彙をGoogleサーバに送信され、これの集積、解析から「よく使われる言い回し&単語」が変換に反映されるしくみになっているので「数を集めた平均は最適になるとは限らない(ならない場合の方が多い)」という実証例か?と穿った見方もしてみる。

——–[ 脚注 ]—————-
  1. ATOKの場合は単独性能は申し分無いがシステム・リソースを遠慮会釈なしに使うので複数のアプリケーションを起動して行ったり来たりの作業をしているとシステム諸ともに動作が緩慢になるという亊は屡々発生した。反対に言えば「それだけ潤沢にシステム・リソースを食い荒らしていれば、そりゃ高性能でしょうよ」ということ
  2. その後「かわせみ」という亜種は残ったものの
  3. だから実はMac OS X 10.6.8でもSafari、Mail以外では大概使える

関係性で心理は変わる

この手の記事にしては割とまとも。

些細なことで激怒する彼!その理由は?-セキララ★ゼクシィ
http://zexy.net/contents/lovenews/article.php?d=20120511&vos=nxywsmts20101214

「男は・・・」「女は・・・」と安直な分析に落し込んでものを言わず、関係性の問題だとの指摘は◯。

更に附言するなら、「どっちが上or下」ということを「意識する関係性」を作ってしまったら(いずれが上でも下でも。これは問題ではなく)アウトだと。
こうなってしまうと「どっちが上か下か」ということに過敏になってしまうので結果、「些細なことで激怒する」ということに。

以下は私見ですが、
以前 世の中によくある男女比較論 で述べたのに類似して、異性兄弟と育っていない(異性兄弟がいない)人の方が『「どっちが上or下」ということを「意識する関係性」』を作ってしまいがちなように経験則からは思います。

formデータの取り出し時 Encode.pm を使ったちょっとした工夫

Perlのバージョンが5になるかならないかの頃に作った送信フォームPerlスクリプトを「そろそろいい加減UTF-8化しないとなぁ」と思って、use CGI すらしていなかった(古っ!)シロモノだったので殆ど抜本的に作り直していて、、、「まぁ、こんなもんか(取り敢えず)」というとこまで辿り付いたので、ハッカー諸氏の「ツッコミという名の添削(|| s/ツッコミ/添削/g )」を期待して。

use strict;
use warnings;
use utf8;
use Encode;
use open ":utf8";
binmode STDIN, ':utf8';
use CGI;
use CGI::Carp qw(fatalsToBrowser);
my $eucjp = Encode::find_encoding('eucjp');
my $utf8 = Encode::find_encoding('utf8');

#----------------------#
# フォームDATAのデコード #
#----------------------#
sub CGI_decode{
my $q = CGI->new;

my @keys = $q->param();
foreach my $key (@keys)
  {
  my $value = $q->param($key);
    if($main::debug_mode==1){$main::sample_str1 .= $key.'<>'.$value.', ';} #debug用テキスト収集
  my $utf8 = Encode::find_encoding('utf8');
  $value = $utf8->decode($value);
    if($main::debug_mode==1){$main::sample_str2 .= $key.'<>'.$value.', ';} #debug用テキスト収集
  $value = initdata::jp_hankaku_trans($value);
    if($main::debug_mode==1){$main::sample_str3 .= $key.'<>'.$value.', ';} #debug用テキスト収集
    $main::in{ $key } = $value;
  }
}

先ずformから送られて来たデータをデコードしつつバラして取り出すルーチン。 $in{ } で括りたがるのなんかコード書き出した時「Kent Web さんのソースのコピペ」から始めたのが丸バレのコードですが。
ツッコんで欲しいのは「$q->param() した@keys をforeachループで連想配列に入れたがる」のは古い記述なのかどうか。もっと 冴えた|モダンな 書き方が在るのかどうか。
ウェブで調べても「CGI.pm 使って my @keys = $q->param(); で取り出す」という記述だけは在るのですが、「汎用性のある」「フォームデータの取り出しルーチン」を、と考えると、key 値はその時毎の送信元HTMLによって違ってくるわけだから、取り出すルーチンの側で変数名を決め打ちできない。のでフォームデータの分解は「受け取った値で key=>value しといたよ!」というかたちになっていて欲しいので、こういう形式にしたのですが、、、どうざんしょ?

それと eucjp、utf8 それぞれの「Encode::find_encoding()」の記述は冒頭に宣言してしまってグローバル・スコープ的に使ってしまう使い方で良いのかどうかもご意見頂きたく(「そんなことしたらメモリー無駄使い」とか「処理速度が遅く(|速く)なる」とか、、、あれこれ)。


外字の処理をする

次に「最終的にiso-2022-jpメールにして送信」を前提として、Encodeの応用として所謂 機種依存文字(正しくは「プラットフォーム依存文字」と云うべき)を以下のように判定しつつエラー表示を返すルーチンを考えてみた。
utf-8のテキストをちゃんと表示してくれるメール・クライアントを使っている人が多くなってきている(少なくとも、Mac OS X 10.5以降、Windows Vista以降、iPhone、Android OS では)ので「メール本文はutf-8で送っちゃって良いんじゃない?」という意見も今や無謀な意見ではなくなってきているとは言え、まだ「iso-2022-jpにして送っておいた方が安全」ということで。
少し巡りくどい引き回しかも知れませんが、Encode.pm でeuc-jpに(sjisでもiso-2022-jpでも構わない)変換を通過させると変換からDropする文字は第三引数に渡してくれて別途処理をさせてくれるという便利な機能を流用します。で、Dropしなかった(使って差し支えない)文字はutf-8に戻すという流れになっています。

元アイデア:404 Blog Not Found:perl – Encode 中級
http://blog.livedoor.jp/dankogai/archives/51047005.html

sub CGI_decode{
my $q = CGI->new;
my @keys = $q->param();
foreach my $key (@keys)
  {
  my $value = $q->param($key);
  my $utf8 = Encode::find_encoding('utf8');
  $value = $utf8->decode($value);
  $value = omit_izonmoji($value);
  $value = initdata::jp_hankaku_trans($value);
    $main::in{ $key } = $value;
  }
 if ($initdata::gaijiflag){
	initdata::error('プラットホーム依存文字(機種依存文字)を使わないで下さい。',"<p>プラットホーム依存文字(機種依存文字)は、<br />貴方のと違う環境では文字化けして意味不明になる文字です。<br />ブラウザーの「戻る」で戻って<br />プラットホーム依存文字(機種依存文字)を削除または非プラットフォーム依存文字に修正して下さい。</p><p><span style=\"color:#ff0000; font-size:14px !important;\"><b>丸・括弧囲み文字、ローマ数字など</b></span><br />が代表的なプラットホーム依存文字(機種依存文字)です。</p>",'','inquiry_cgi_izonmoji');
 }
}
sub omit_izonmoji {
my $str = shift;
#my $eucjp = Encode::find_encoding('eucjp'); #グローバルで宣言していない場合必要
#my $utf8 = Encode::find_encoding('utf8'); #グローバルで宣言していない場合必要
$str = $utf8->encode($str);
  Encode::from_to($str, "utf8", "eucjp", sub {if (Encode::FB_XMLCREF){$initdata::gaijiflag = $_[0] } } );
  $str = $eucjp->decode($str);
  return $str;
}

どれがプラットフォーム依存文字だか分かるようにする

単にエラーを返すだけだと「どれがプラットフォーム依存文字だと分かっている」人じゃないと不親切(わかっている人はそもそも外字を入力したりしないだろうし)なので「これがプラットフォーム依存文字ですよ」と表示してあげるのが良いだろうと考えて以下のようにコードを追加。

sub CGI_decode{
my $q = CGI->new;

my @keys = $q->param();
foreach my $key (@keys)
  {
  my $value = $q->param($key);
  my $utf8 = Encode::find_encoding('utf8');
  $value = $utf8->decode($value);
  $value = omit_izonmoji($value);
  $value = initdata::jp_hankaku_trans($value);
    $main::in{ $key } = $value;
  }
 if ($initdata::gaijiflag){
	initdata::error('プラットホーム依存文字(機種依存文字)は使わないで下さい。',"<p>プラットホーム依存文字(機種依存文字)は、<br />貴方のと違う環境では文字化けして意味不明になる文字です。<br />ブラウザーの「戻る」で戻って<br />プラットホーム依存文字(機種依存文字)を削除または非機種依存文字に修正して下さい。</p><p><span style=\"color:#ff0000; font-size:14px !important;\"><B>丸・括弧囲み文字、ローマ数字など</B></span><br />が代表的なプラットホーム依存文字(機種依存文字)です。</p><p>あなたの入力した内、以下が外字に該当します:$initdata::gaijiflag</p>",'','inquiry_cgi_izonmoji');
 }
}
sub omit_izonmoji {
my $str = shift;
#my $eucjp = Encode::find_encoding('eucjp'); #グローバルで宣言していない場合必要
#my $utf8 = Encode::find_encoding('utf8'); #グローバルで宣言していない場合必要
$str = $utf8->encode($str);
  Encode::from_to($str, "utf8", "eucjp", sub {if (Encode::FB_HTMLCREF){$initdata::gaijiflag .= chr($_[0]).", ";}});
  $str = $eucjp->decode($str);
  return $str;
}

最初 if (Encode::FB_HTMLCREF){ 以下の部分で $initdata::gaijiflag .= $_[0]; としてしまっていて数字の羅列がprintされ「あれ(・_・?)」となってしまった。というのは

Encode::from_to($str, "utf8", "eucjp", Encode::FB_HTMLCREF);

とした場合「数値文字参照:&#nnnn; 形式」で以降の処理に渡されブラウザ表示上では普通に表示されていたので、そのまま持っていけば良いと思っていたら、文字列処理を通過させてしまうと「純粋に十進数(|十六進数)になってしまう」みたい。
ということで chr() してやって文字コードに戻してやらないといけないと。
因みに、これを $str = $eucjp->decode($str); すると「Wide character in subroutine entry」と怒られます。一つ前の処理で $utf8->encode() しているのでutfフラッグは立っていないと思うので、この挙動はイマイチ納得できない(エライ人の解説希望!)。(euc-jpへの変換からDropしているのでutf-8のままであるとは分かるのですが、、、)


おまけ:全角英数字を半角に && 半角カタカナを全角に

sub jp_hankaku_trans{
my $after=shift;

    $after =~ tr/ !”#$%&’()*+,-./0-9:;<=>?@A-Z[¥]^_`a-z{|}/ -}/;

{
  use Encode::JP::H2Z;
  my $eucjp = Encode::find_encoding('eucjp');
  sub hankaku2zenkaku { 
    my $str = $eucjp->encode(shift);
    Encode::JP::H2Z::h2z(\$str);
    $eucjp->decode($str);
  }
  sub zenkaku2hankaku { 
      my $str = $eucjp->encode(shift);
      Encode::JP::H2Z::z2h(\$str);
      $eucjp->decode($str);
  }
}
hankaku2zenkaku($after);
}

前半:全角英数字を半角には

Perl用、日本語「全角」→「半角」変換ルーチン – adiary開発日誌 http://adiary.blog.abk.nu/0263

から、
後半:半角カタカナを全角に

404 Blog Not Found:perl – 勝手に添削 – utf8環境でperl::Jcodeのtrが使えないとき http://blog.livedoor.jp/dankogai/archives/51693618.html

から丸々借用です。


追記:2012年5月8日19時56分
Encode::FB_HTMLCREF の代わりに Encode::FB_XMLCREF と記述すると16進数表記になるわけですが、FB_XMLCREF とする場合は、Encode.pm のバージョンが中途半端に古いと(ver.2.10~2.12)上手く動いてくれない場合があるという情報をDankoghaiさんの別のページで見付けましたので念の為、補記しておきます。

404 Blog Not Found:perl – Encode::from_to() and fallback options
http://blog.livedoor.jp/dankogai/archives/50502791.html

この場合、以下の通りにすると良いみたいです(手元環境のEncodeは最新版なので未検証)。

sub omit_izonmoji {
my $str = shift;
my $eucjp = Encode::find_encoding('eucjp');
my $utf8 = Encode::find_encoding('utf8');
$str = $utf8->encode($str);
  my $check = ( $Encode::VERSION < 2.13 ) ?  Encode::FB_XMLCREF() : Encode::XMLCREF();
  Encode::from_to($str, "utf8", "eucjp", sub {if ($check){$initdata::gaijiflag .= chr($_&#91;0&#93;).", ";}});
  $str = $eucjp->decode($str);
  return $str;
}
%d人のブロガーが「いいね」をつけました。