なんとまぁ

　ゆきだるまさん お悩み中。

　利用したい人が困っていると、何とかならないかと思ってしまうのが作ってる人間の人情というもので(笑

　どうもチャンネル名の文字コードがiso-2022-jpでチャンネル内の会話の文字コードがUTF-8という変則的なサーバがあるのかもしれないという話です。

#　上記はActivePerl5.10において、encodingの挙動が変化したものによるようです。
#　当時はソースがShift-Jisでしたが、現在はソースをUTF-8で記述することで回避しています。
#　(2008/10/05追記)

　もっとも、LimeChat2のサーバ設定で文字コードがiso-2022-jpというのですから、LimeChat2で会話の文字コード自動判別でもしてない限り、UTF-8で会話したら文字化けするんじゃないかと思うのですが、なんでそんな変則的な運用してるんでしょうね？
　チャンネルリスト取るときに問題があるのかな？

　いろいろ疑問がありますが、問題がはっきりしないと解決は難しいでしょう。
　そこで、テスト用にチャンネル名と会話の文字コードを別々に指定出来るVerを書いてみました。

　私のテスト環境では、-iオプションと-rオプションで設定を変えて実験してみた所

1.ボットのチャンネル名はiso-2022-jp
2.ボットの会話がUTF-8
3.LimeChat2.28でサーバの文字コード設定をUTF-8

にして繋ぐと、上手く動作しませんでした。
　Inviteしようとすると文字化けしてボットが訳のわからない部屋に入ってしまいます。
　３つ全てUTF-8だと問題なく動作しました。

　同様に

1.ボットのチャンネル名はiso-2022-jp
2.ボットの会話がUTF-8
3.LimeChat2.28でサーバの文字コード設定をiso-2022-jp

　にすると、Inviteは出来ますが、ボットのコンソールを見ると会話が文字化けして見えているのが判ります。

　変なのは

1.ボットのチャンネル名はUTF-8
2.ボットの会話がiso-2022-jp
3.LimeChat2.28でサーバの文字コード設定をiso-2022-jp

　にするとボットのコンソール上で部屋名が化けてるのに何故かInvite出来てしまいます。
　サーバの設定(や実装)に依存するのかなぁ。

　あくまで試験用ですが、こんな感じで設定を変えて問題点を見つけだすのには使えるかも知れません。

「SR4用ダイスボットv1.2 test用」をダウンロード

　本来ならLimeChat2のサーバ設定で文字コードがiso-2022-jpなら、ボットのIRC用文字コードも全てiso-2022-jpで揃えれば上手く動くと思うんですけどね～。