Filter::Regexp　（前半戦）

トラブル解決 こまりごと

otsune 2008/04/29 12:36
>何故か上のDedupedが無効になってるね。
expressionの返り値が1か0かでPlagger::Ruleのdispatchが分岐されるので想定された動作。
「RuleでDedupedして、同時に別のRuleを」という場合は op: AND を使う。
ただ、今回のconfig.yamlのような場合は無理にexpression hackしないでFilter::Regexpを使えばOk

というわけでコメントにて示唆を頂いたので取り組む（毎々有難う御座います）。
まずは先達がいて手をつけやすいと思われるFilter::Regexp。
頂いたコメント通り、フォントの色換えと太字化をExpressionではなく、こちらでやってみます。
CpanのFilter::Regexpページによると…

Plagger::Plugin::Filter::Regexp - Rewrite entry body using regular expression

あ、すっげえわかりやすい。この子達いじり始めて一番わかりやすいかも。
ていうかこの辺も一通り読んだらもっと賢くなれるよね…ぼく…
なら今まで

  - module: Filter::Rule
　　rule:
      module: Deduped
      engine: DB_File_URL
      path: /tmp/deduped_urlonly.db
      expression: $args->{entry}->{body} =~ s/(HOGE|Hoge|hoge)/<font color="#ff0000"><b>$1<\/font><\/b>/g;

という風に書いていたけど

  - module: Filter::Rule
    rule:
      module: Deduped
      engine: DB_File_URL
      path: /tmp/deduped_urlonly.db
  - module: Filter::Regexp
    config:
      regexp: s/(HOGE|Hoge|hoge)/<font color="#ff0000"><b>$1<\/font><\/b>/g;

という風に役割分担してもらうことにしました。わーい。


…はい、しかしここでも問題発生。
今現在進行形で書き直しながらこれ打ってるけど、

"Cannot decode string with wide characters"

とか怒られます。日本語訳すると「マルチバイト文字を含む文字列をデコードできなかったよ」というような話。多分取ってこようとしてる元のページ（ええ、まぁ某やほおですけど）が骨の髄からEUCとかいうＸＸＸな文字コードで出来てるせいなんだろうなぁ（指定の仕方が普通の…charsetとかじゃないのが僕きっと悪いんだと思う）…。いや、わかった振りしてますけどもちろんわかってませんよ。とりあえずでもEUCのせいで日ごろ色々邪魔なのは確か。configはUTF-8で勿論保存してるし、what can i do sir?って気分。

とはいえ自分で何かしないと何も起こらないのが無常なる機械の世界なので
Plagger::Util::decode_content が使う文字コードを強制指定するを見てglobalに charset: utf-8してみる→だめ。

フォント情報無視させるには一回Plain Textにすりゃいいんだよなぁ…とおもって文字コード無視させるにも同じもの使えるかもと思ってFilter::FormatTextを導入…してもそれ以前にこれがこける。2chの中級スレの435によるとPublish::GmailではそもそもこのFormatTextはだめということで諦め（ここの質問者はまた別のプラグイン導入して自己解決したようだけど今の僕がそんなことやっても解決から遠ざかるばかりなので回避）。
というか上記はplagger的にはあってもなくても前に進んでくれるみたいで、逆に言えばとまりもしないんじゃ解決してもなんも意味ないね的な。

※しかも
http://xyz.lotroblog.jp/article/7282.html
この辺では普通にFormatText使ってGmailに送ってる…

ぬうう。


で、本題に戻して。
http://sonic64.com/2005-10-04.html
Yahoo 検索で文字が表示されない・文字化けする件の対処法
で「user agentによって返ってくるデータが違う（そして一部はそもそもデータが壊れている）」という記述があったのでuser agentを例によって導入→これもだめ。


なんかEncode自体をいじれ、的なお答えがあったりもしたんだけどソース読めもしない自分がめくらで書き直すのは怖いので最終手段として以外には避けたいです。
http://lab.z-nix.jp/2005/10/cannot_decode_string_with_wide.html


ここまでで３時間弱ほど経過し、明日はお仕事なので一旦手仕舞い。
明日以降もう少し考えて（明日仕事結構暇だから職場で考えるかも…）、駄目そうならop: ANDを考えます。