あ、xmms-alsa なんだけど、オレが入れている 0.4.1 というヤツは、赤帽用のパッケージも用意されていたのだが、xmms は確かに入っているにも関わらず、ねぇよなどとホザいてうまく入らないという困ったちゃんだったので、とっとと自分でパッケージしなおしてカタにハメなおした(笑)
で、肝心の xmms なんだけど、これにも一部パッチをあてて、MP3 の TAG に日本語を使えるようにしてみた。xmms はもともと x11amp の名前が変わったもの、というような経緯があるようで、x11amp に対する日本語なパッチは古川さんがMy Linux 日本語化計画という素晴らしいページで公開なさっていたのだが、やはりやや古くて、そのままではあたらなかったらしい。
らしい、というのはなんでか、というと、x11amp へのパッチをベースに、xmms-0.9.1 に対するパッチを作ってくださったのは、例によって_tom_ さんだったりするから(笑) いつも感謝です。
xmms 日本語化パッチには、大きくわけて2つの目的があるのだが、1つ目は、gtk_set_locale() などを呼び出すようにし(いつものお約束だ)、リソースに日本語のフォントを指定可能にすること、2つ目は、TAG に使われている文字コードを、動作中の locale に合わせて変換してやること、と言えるだろう。
xmms を使って、Linux で MP3 を聞いている人はおおむね TAG には EUC を使っているのではないかと思うが(オレもそうだ)、場合によっては Windows と共有していて、Shift JIS の方が都合がよい人もいると思う。JIS で TAG を打ってる人はあまりいないだろう(汗)
というわけで、主に Shift JIS から EUC にコード変換する処理を追加してあるのだが、よく考えるとこれってすげ〜無駄だよねぇ。
エディタやらメーラやら、日本語化されているものって、えてしてこういった漢字コードの変換部というのを内蔵しているでしょ？それも、人それぞれ、モノに寄りけりで、あれでもコード変換、これでもコード変換、同じことする処理部が散在しているのだ。
コード変換つっても、Multi Byte Char と Wide Char の変換のように、I18n などを前提として文字コードを Unified するといった目的ではなくて、単なるベタベタの L10n だぜ。これってのは、歴史的な経緯などで、我々日本人がローカルな文字コードとして、Shift JIS だの EUC-JP だの iso-2022-jp (はメールとか web のコンテンツ とか、おおむね通信経路上にしか出てこないと思うけどさ)とか、複数の文字コードを使い散らしてるからなんだけどさ。Linux では今のところローカルな文字コードとしては選べないけど、EBCDIC も日本語なヤツがあるし。
従来の x11amp の日本語化パッチでは、こういった文字コードを変換する部分として、libjcode というライブラリを使うようになっていたんだよね。この libjcode って、GICQ の日本語化でも使っているライブラリなのだが、ライセンスが GPL ぢゃない(つまり改変・再配布が不可)のでわないか、などという憶測が流れて、作者の倉光さんに問い合わせるなどという騒ぎまで起きてしまった。
結局、ライセンス的には再配布も問題ない、という結論に落ち着いたので、コ鯖にあるxmms-0.9.1.ja-1.src.rpmは libjcode を使って日本語のコード変換をするようになっている。
しかし、漢字コードの変換ライブラリなんて、いったいいつまで付き合わなければならないのだろう。今まで何回、同じものを書いたことか。Shift JIS だ、EUC だって、もう10年もやってんぞ。VMS 上でも書いたし NetWare 上でも書いた。もうウンザリだね…
と思っていたのだが、実は glibc 2.1 には文字コードの変換ルーチンが含まれているのだ。そう。それが iconv() だ。赤帽 6.0 で提供される glibc-2.1.1-7 にももちろん含まれている。
とはいえ、glibc の iconv() を使って得られるメリットというのは今の時点では実はあんまりなくて(笑)
1. (既存のものを使うならともかく)似たようなコード変換処理を皆で別々に実装する必要がなくなる。
2. コード変換処理部はえてして startic link なライブラリだが、アレでもコレでも皆でリンクするのはアホらしい。glibc に任せてしまうとシンプルになる。
くらいしか思い付かぬ。その反面、デメリットは見過ごせないほどあって(笑)簡単にあげても
1. glibc-2.1 でないディストリビューションでは動作しない。
2. iconv() の仕様そのものが大きく変動して(ヘタすると名前が変わったり、なくなっちゃったり)、動かなくなる危険がある。
3. 既存の、すでに動いているコード変換ライブラリを差し替える際には、レベルダウンする危険がある上に、なんら新機能が得られるわけではない。
といったところか。しかし、これわやはり使わない手はなかろう。せっかくの glibc-2.1.1 を、ただ「新しい glibc」としてしか利用できていないのでは意味なさすぎるもんね。どうせオレのマシンは日々是スナップショットなのだから(笑)
が、wcsmbs の枠組みからすると、現 locale から UCS4 などの Wide Char に変換する、あるいはその逆、というのはできるのはわかっているのだが、それってのはあくまで MB と WC との変換であって、ある MB を別の MB に変換したいという場合に、locale の切り替えが必要だなどといわれてしまっては使い物にならないよねぇ。そもそも locale なんてもんは本来、プログラム内でガチャガチャ切り替えられることを想定してないわけだし。
どんな風に使うのかなぁ、iconv() わ、などと調べてみるも、man iconv などとしてもなにも出て来ぬし、libc.info の Generic Charset Conversion の項目しか情報がなかった。一応 iconv example として、一通りの使い方が出ているので、それを読んで見よう見まねで書いてみたのがコレだ。xmms-0.9.1.ja-2.src.rpm にもそのまま使っちゃった。
iconv って実は割とそのまんまな使い方ができて、流れとしては以下のようになる。
#include <iconv.h>
iconv_t cd;
cd = iconv_open (dstset, srcset);
if (cd == (iconv_t) -1)
{
/* エラーぢゃボケ。そげな変換はできぬわ。*/
}
といった感じ。dstset は変換後の文字コードの名前を指定する。srcset は変換前ね。この srcset と dstset ってのがちょっと笑えて、数値ぢゃないんだよ。文字列で指定するのだ。わはははは。例えば、Shift JIS から日本語の EUC に変換してちょ、というときは iconv_open("EUCJP", "SJIS") などとするワケ。これってのはつまり、locale を指定する文字列のピリオド以降、つまり文字コードの指定をそのまま使うということなのだろうなぁ。
locale が ja_JP.EUCJP だとすると、iconv での識別はピリオド以降の "EUCJP" になる、というね。
nconv = iconv (cd, (const char **)&inptr, &insize, &outptr, &outsize);
if (nconv == (size_t) -1)
{
/* 変換できなんだわ。引き数をよ〜く確かめんかいコラ。 */
}
*((wchar_t *) outptr) = L'\0';
とか、こんな感じに使ってる。見たまんま。 変換する文字列とそのバイト長、変換後の文字列がはいるバッファとそのバイト長を渡せばよいらしい。最初は、バイト長を渡すのではなくて、文字数を渡すのかと誤解してハマッてしまった(汗) 変換に成功すると、返すのはバイト数でもなく文字数でもなく、変換に成功した回数を返すらしい(汗) SJIS で"あいうえお"を EUC にする場合は 5 が返ってくるので文字数と等しくなるが、英数字などが含まれている場合は単純な文字数よりも少なくなるってことか。
iconv_close(cd);
そのまんま。open してホゲホゲして close する、というのは、Unix にとってはもはや様式美であって、横綱の土俵入りのようなものなので、なにも言うまい(笑)
というワケで、首尾よく漢字コードの変換を iconv() によって行なわせることはできたのだが、これだけの機能では実際には使えない。コードの判別については一切面倒を見てくれないようだから。だもんで、そこだけは従来のものを流用してくっつけちゃったよ。
MB な漢字コードを取り扱う際に、かならず出てくるイヤな命題として、ソレが SJIS なのか EUC なのか、というのが必ず出てくるんだが、こういう部分はやっぱ、さすがに glibc に取り込むってワケには行かないのかなぁ。SJIS と EUC の判別ってえれ〜面倒だし… 任意の1バイトを抽出して、それが漢字の1バイト目か2バイト目かというのも、完全に重なってる部分だと、判別不可能だったりするしなぁ。
JIS というか(ISO-2022 のサブセットの) ISO-2022-JP にしたって、前方にさかのぼってエスケープシーケンスを見付けないかぎり、その任意の1バイトがいったい何なのか、ってのはわからない。面倒だよねぇ日本語って。
う〜む、しかし読みなおすと上の段は、一応意味が通じはするが、その筋の人にはもうボロクソ文句言われそうだな(汗)
JIS だ SJIS だ EUC だ、という話は、エンコーディングの話であって、キャラクタセットの話ではないのよ。たとえば、単にごく簡単に、JIS コード、などというと、それはつきつめると(つめなくてもそうか(笑))、文字集合としてのキャラクタ・セットと、それをいかにしてデータとして符号化するかというエンコーディングとの、2つの側面をひとくくりにしてしまうので、なんだかワケワカになる、という罠がある。
一応オレの理解としては、ISO-2022-JP にしろ SJIS にしろ EUC にしろ、キャラクタセットとしては、JIS X 0208 の漢字コードの部分をそのまま使っているものと解釈している。外字などの例外や、補助漢字などを除くと、基本的には ISO-2022-JP でも SJIS でも EUC でも、表現できる文字に差はないし、文字集合としては同じもの、というね。
では、いわゆる文字化けしちゃうからコード変換が必要、とかいう場合の変換ってのはなんなの？というと、それは単にエンコーディング、和風に言うと符号化方式の違いを吸収しているということなんだよね。指してる文字そのものは一緒なのだ。
ISO-2022-JP は、いわゆる JUNET コードなどと呼ばれるもので(今じゃ死語か)、7 bit で全部の文字を表してくれちゃう ASCII な環境に、なんとかして漢字を通そうとして生まれた苦肉の策といった側面が拭えないけど、internet (というか JUNET)の先人達の知恵で、7 bit な枠組みのなかで、英数字と JIS X 0208 なキャラクタ・セットを共存させることに成功している。
カラクリとしてはお約束のエスケープシーケンスを使う方式で、ここから先は、次のエスケープシーケンスが出てくるまでずっと漢字だよ、てな具合に指示をする、という方式だ。-JP のつかない ISO-2022 というのがもちろん存在して、そっちではもっとたくさんの種類のキャラクタ・セットが扱える。なにしろ ISO だもんね。
で、その ISO-2022 では、もっとエスケープシーケンスも複雑なのがある(のだそうな(笑))が、現実にオレたち日本人が必須としているのは、漢字と英数字の混ざったエンコーディングだけでしょ？だもんで、漢字を指示するものと英数字を指示するものだけにエスケープシーケンスを簡略化してしまえ、というのが ISO-2022-JP だ、と思っておけばとりあえず大きく外れてはいないだろう。
などと書いているが、これって実際には、従来の JIS の符号化方法を ISO-2022 の枠組みに当てはめただけなんじゃないの？と常々思っているのだが(自信なし)
全然大事なことじゃないのだが書いておくと、よく言われる漢字イン、漢字アウトというのは誤りだと思う。そこまで書くと強すぎか。なら違和感がある、と書いておこう。だって、ISO-2022 にしろ JIS にしろ、どういうキャラクタ・セットを扱うのか指示する、というのがエスケープシーケンスの役割なんだぜ。意味としてはインしかないはずだ。
例えば、人によっては漢字アウトと呼ぶ、英数字を指示するエスケープシーケンスを検出したとしよう。でも、そのエスケープシーケンスの前方にある文字データが、漢字だとは誰も保証しないもんね。本当に意味的に漢字アウトなのであれば、漢字確定であるはずだよねぇ？ でも現実にはそうじゃない。スウェーデン語から英語に切り替えただけかも知れないぞ(笑)
だから、漢字インはなんとか許せても、漢字アウトはおかしくないか？と常々思っていたのだ。漢字イン、英数字イン、ならわからぬでもないが、そういうのは聞いたことがないしなぁ。わははは。とにかく、なにがなんでもさかのぼって、エスケープシーケンスを見付けださないと、そのキャラクタ・セットがなんなのか、判別できないのが ISO-2022 による符号化の特徴であり欠点でもある。一連のストリームとして扱うならいいが、会話的なエディタなんかにはも〜全然向かないんぢゃないの？
EUC はその点、さらに簡略化されていて、同じ JIS のキャラクタ・セットを、エスケープシーケンスなしに英数字と混在させたものだ。そう。漢字コードの 8 bit 目を常に立てて、7 bit である英数字と区別する、というね。えらく簡単。JIS の漢字コードに 0x8080 を足すだけで EUC (の漢字)になる。
SJIS はそういう意味(どういう意味？)からすると実際にかなり邪悪で、1バイトなカナを捨てて、英数字と漢字を清々しく混在させた EUC (といってもシングルシフトで1バイトなカナも表せるんだけどさ)に対して、1バイトなカナを生かした(要するに 8 bit で表わせる範囲の一部をカナに割いた)ために、算術的な演算(これをして「シフト」と称しているらしい)をして、空き領域に漢字を押し込めている。って、カッコが多いなどうにもこうにも(笑)
今となっては、錦の御旗の Windows ですら1バイトのカナを捨ててしまったのだから、使いもしない領域を後生大事に確保して、おかげで補助漢字が使えないなどの弊害を持ってしまった悲しいエンコーディングという気がする。
そうそう、半角カナ、という言葉だけど、これも使うのやめようと思う。オレもよく使っていたけど、半角だ全角だってのは、活字屋さんの言葉というか、カラムの話だよねぇ。漢字を基準(全角ね)としたときに、半分の幅しか占めない(だから半角)というね。でもプロポーショナルなフォントじゃ意味がないし、だいたい英語で説明できねぇぞ。どうすんだ。オレはいつも One byte KANA とか Single byte KANA と言ってたけど。だから日本語でも1バイトなカナ、などと書いた。
そうそう、半角全角といえば、最近よく見かけるメールなんだけど、英数字が全部2バイトなヤツがある。Ｌｉｎｕｘ をインストールしました、とかゆ〜ヤツ。あれってどうして？ MS IME とか OutLook とか使って、プロポーショナルなフォントだとああなっちゃうの？ オレ的にはものすげ〜見にくいし、だいたいカッコ悪いのでやめてくれ。オレに読ませないでくれ。そんなクソメールを。
悪いが、英数字に2バイト使って平気な顔してる人を、オレはコンピュータ・リテラシのない人と見なすのでそこんとこよろしく。言い方は悪いが、要は馬鹿扱いするよ、ってこった。
英単語で検索するとしよう。Linux で検索したとして、普通はＬｉｎｕｘはヒットしない。どんなに素晴らしい内容でも、検索したときにヒットしないんじゃ価値も半減だよなぁ。まぁ、えてして検索するような価値もないのに限って、英数字がデカいんだけどさ(笑) 頼みもしねぇのに html とかくっついてくるし凸(-_-#)
それに、英単語としての扱いを受けないから、word wrap もしなくなっちゃうぞ。Ｌｉ
ｎｕｘ なんてなっちゃって嬉しい？オレはイヤだね。あ、送信するとにきに、自分とこで wrap してないんだからいいじゃん、とか思ってない？ だからリテラシがねぇってんだよ。もっと狭い画面で見る人がいるかも知れぬし、部分的に引用されるかも知れないぞぅ。恥ずかしいぞ〜。
7/24 ちょっと加筆〜
なんか、すげ〜大家な方にツッコミ入れられてしまったので、参照しとこう。あわせて読んでちょ。
けっこうボロクソ書かれてたりする(苦笑) オレ的には、大筋の見えない人に枝葉を語っても、とかちょっとエラそうに思ってしまい、EUC-JP の シングルシフトとか、その辺のとこには触れなかったんだが、やっぱちょっとくらい書いときゃよかったか。少し後悔。とはいえ、その筋の方々から見れば五十歩百歩なのはその通りではある。
でもまぁ、「私はいわゆる「全角英数字」をつかってる人をみると、「ださださー」と思って、そして、その程度の技量だと判断します。いじょ。」ってことだな、オレも。
| メール | 戻る |