Loqui 0.5.5を出しました。受信時に行なっていたISO-2022-JPの半自前変換を、送信時にも行うようにしました。ただし、受信時と異なり、「半角カナ」などの文字は、エラーにします。
これもまたSolaris用で、Solaris iconvでUTF-8からISO-2022-JPに変換すると、IRCNet的に困ったエスケープシーケンスをつけてしまうことへの対応です。Solarisで起きる現象については、
この一連のスレッドにまとまっています（もう少しするとopensolaris.orgがなくなるので消えてしまうのですが…）
GNU iconvではこのようなことがないので、Linuxユーザの方は今までのままで大丈夫です（0.5.5からLinuxでも自前になるので、かえってあやしいかもしれません。うまく変換できていたのにいかなくなったケースがあれば教えてもらえると助かります。）
さて、せっかくなのでずっと前から実装されていた半自前変換について書いておこうと思います。UTF-8⇔ISO-2022-JP変換をする人の参考になれば。（パフォーマンスはよくないし、ISO-2022-JP-2004なども視野に入れるとやることが増えるので、対応できるケースは限られるのですが…）
Loquiの半自前UTF-8⇔ISO-2022-JP変換
Loquiでは、アカウント設定の「コード」の「一覧から選択する」で「Japanese」を選んだ場合、あるいは「ロケール情報から自動判定する」を選んで「ja_JP」から始まるlocaleで利用している場合、（ただのiconv呼び出しでない）ISO-2022-JP向けの文字コード変換ロジックが動きます。
この変換ロジックはいわゆる「半角カナ」や機種依存文字（の一部：NEC特殊文字(13区)）を受信しても化けずに表示させるためのものなのですが、ざっくり言うと、「iconvが失敗しそうな文字は自前で変換」「そうでない文字はiconvに変換してもらう」（半自前変換）という処理になっています。ただし、以下の図のような、ちょっと変わった流れをしています。
Gtk+(2以降)は、画面に表示するためにUTF-8を要求するのですが、日本語でIRCを使おうとすると、ISO-2022-JPを使っていることがあるので、この場合ISO-2022-JPからUTF-8に変換しないといけません。pureにISO-2022-JPのバイト列が来るならGLibのiconv wrapperでさくっと変換するだけで良いのですが、先の「半角カナ」があったりするので、手を入れないといけないわけです。
まぁ、変換処理を自前で持とう、という話になるのですが、ISO-2022-JPは漢字にJIS X 0208という文字セットを使っているのに対し、UTF-8はUnicodeなので、基本的には1文字1文字の変換テーブルを持つ必要があり、いろいろな意味でちょっとつらいです。そのため、「特殊な対応が必要な文字だけ自前で変換し、そうでないものはiconvに変換してもらう」というアプローチを考えます。
ところが、そうすると1文字1文字変換する必要がでてきますが、困ったことにISO-2022-JPは「ここからJIS X 0208の漢字だよー」といったような、文字セットの呼び出しがあり、コンテキストに意味をもったエンコーディングなのです。そのため、ISO-2022-JPのバイト列のままiconvに渡そうとすると、特殊な文字が入ってきたりこなかったりして、状態の管理がちょっとしんどくなります。
そこでどうするかというと、いったんISO-2022-JPからEUC-JPに変換します。EUC-JPでもJIS X 0208を使っているので、ISO-2022-JPからは計算式的に変換できる一方で、EUC-JPはISO-2022-JPと異なり、持続する文字セットの呼び出し（コンテキストの永続的変更）がない（次の文字だけ変更というのはあります）ので、状態の管理が簡単になります。これが上図のようなちょっと変わった流れをしている理由です。
詳しく知りたい方は、loqui_codeconv_tools.cを見てください。
ちなみに、Loquiはこういった言語ごとの特殊ロジックとlocale名の対応テーブルを持っています。10年以上に渡り、日本語以外に使われたことはないのですが…
余談
0.5.5を出してこの図を描こうと思ったら、
いつのまにか横道にそれてました。
sunnyone.org
