- ソースのソース
まずは前記事の復習。
ローマ字サンスクリットをすべて活字画像ファイルを使って表示するようにしたわけであるが、
画像であるからにはIMG SRCタグで参照しなければならない。
どういうふうに参照しているかは、それぞれのページのソースを見てほしい
（IEなら表示−ソース、Netscapeなら表示−ページのソース）。
このIMG SRCタグを、最初はいちいち手で書いていたのだが、
しばらくやっているうち、これがいかに大変かを痛感した。
手で書く大変さもさることながら、可読性を著しく損なう（要するに読みにくい）ので、
メンテナンスが大変である。
そこで、HTMLソースのさらにソースを別に書いてそれをHTMLファイルに変換することにした。
ＫＨ法など適当なローマ字でサンスクリットを書いて、
それをプログラムでIMG SRCタグを用いたHTMLファイルに変換しようというわけである。
- ローマナイズ方式を決める
サンスクリットのローマナイズ転写法はこちら(東北大の相場さんの)のページにまとめられているが、
一番一般的と思われるＫＨ式の中ですら、
細かい方言がいろいろあり、
使う人の数だけ方式が存在するという感じである。
もっとも、この仕事を始めたときの私は、
サンスクリットのローマナイズ方式って、
東外大ＡＡ研高島研究室で使っている方式しかないと思っていた
（だから後述の、私の独自の方法も、
 をAでなくaaと書く流儀だったりする）。
で、この方法であるが、
大文字と小文字とで別の文字を表すという簡便な特長は、
この仕事の場合は難点になってしまう。
単にこの「ソースのソース」だけだったらいいのだが、
ファイル名やブックマーク名のように、
大文字と小文字を区別しない環境では使えない。
正確にいえば、LinuxなどUNIX環境を使えばファイル名は大文字と小文字を区別するし、
Windowsも一応そうなのだが、
けっこうDOS時代からのユーティリティも使っており、
そういうものを使うと、生成するファイル名はみんな大文字になってしまう。
また、Netscape(少なくとも手元にある7.1)ではブックマークの大文字と小文字を区別するようだが、IEでは6でもダメである。
また、記号類を多用すると、ファイル名やブックマーク名に使えなくなってしまう。
そういった点を考慮して、
「すべて小文字、使う記号は数字のみ」というローマナイズ法を作り、
それでソースのソースを書くことにした。
具体的には、文字表の「内部表現用ローマ字表記」がそれである。
「おいおい、アヴァグラハの ' っていうのはいいのかよ」という声が聞こえてきそう。
一応 ' はファイル名としても(WindowsでもUNIXでも)通るし、
もちろんURLとしても通る。
ブックマークとしても(IEでもNetscapeでも)大丈夫である。
一部で用いられている/だとファイル名として通らない場合があるので、
はるかにましである。
もっとも、アヴァグラハは単独の語の中に出てくることはないので、
ファイル名やブックマークに使う機会は永久に訪れないことだろう。
データベース中では、ダブルクオーツだとカンマ区切りファイルにするときに困るが、
シングルクオーツならば大丈夫だろう。
なお、上記の相場さんの表を見ても、
諸家がアヴァグラハやアヌナーシカをどうしているかは、
いまひとつ不明確である。
特にアヴァグラハが不明。
いったいどうしてるんだろう。
上記の「内部表現用ローマ字表記」に出てこないものとして、
§ は $ 、√は % 、省略記号用の。は ~ で打っている。
あとは、完全にオモテに出てこない内部表現として、
黒と赤の切り替え（トグル）スイッチを @ にした。
dvi@s3@ii@ya(       )みたいに使うのである。
それから大文字は、やはりトグルスイッチ \ を使う。
\r\aama(   )。
あとは、明示的に空白をはさむのに _ を使うなど、細かいのがいろいろある。
- ソースのソースを作る
さて、いよいよ「ソースのソース」を作りはじめたわけだが、
dr3s3t3ha(
   )みたいに英字と数字がひんぱんに入り混じるのは、
決めた私ですら入力しにくい。
やっぱり入力のしやすさではＫＨ式が勝る。
そこで私は、まずはdRSTaのようにＫＨ式で入れておいて、
ＫＨ式→まんどぅーか式に一括変換するマクロをエディタに組み込んでいる。
なあにたいしたことはない。
両者の違いは10数箇所くらいしかないのだ。
だから10数個ぐらいの全置換コマンドを並べるだけですむ。
このエディタ全置換方式の便利なのは、
ＫＨ式とまんどぅーか式とを混在させたものをまんどぅーか式に統一する、
という使い方ができること。
ヘンにプログラムを使うと、
「入力は絶対にＫＨでなきゃダメ」という仕様になりがちで、かえって面倒である。
というのも、ＫＨ式の中でも特にのAというのは、
私はどうも入力しづらく、aaのほうが楽である。ここだけはまんどぅーか式にしたいのだ。
こういうふうに、ケースバイケースでいろんな方式で入力したものを、
最終的に一つの方式に統一する、というのには、
エディタ全置換方式が優れているように思う。
そんなことよりもっと重大なことがある。
いまの上２つの段落にあるように、まんどぅーか式ローマナイズを書いていても、
無変換でそのまま出したいときがある。
というより、「ここからここまでが変換の必要な部分だよ」と明示したいわけだ。
このためには｛ ｝を使っている（ここは大文字で打っているが実際は半角。以下同）。
｛ ｝で囲まれた部分がまんどぅーか式であり、
IMG SRCタグに変換しなきゃいかん部分だよ、というわけである。
今にして思えば、これはあまり賢くない仕様であった。
こう決めてしばらくたったころ、どうも一部の｛ ｝囲みが変換されず、
｛ ｝を含めてそのまま出力されてしまったり、
｛ ｝で囲んでいない部分が変換対象になってしまったりという現象が出た。
原因は、シフトＪＩＳの第２バイトが｛や｝の文字というのが少なからずあり、
プログラム開発に使っているツールが米国仕様で日本語のことを考えていないものなので、
シフトＪＩＳの第２バイト目の｛や｝で誤動作していたというわけである。
そこで私の書いたプログラムも、
｛を見つけたら、「ひょっとしてシフトＪＩＳの２バイト目かな？」という判定をして、
もしそうなら無視してしまうという方法にしたのだが、
実は「ひょっとしてシフトＪＩＳの２バイト目かな？」という判定は非常に難しいのだ。
シフトＪＩＳは、第１バイトが0x81(16進数で81、つまり10進数で129ということ。以下同)〜0x9F、
第２バイトが0x40〜0xFCなのだが、単に直前が0x81〜0x9Fかどうかだけではダメ。
ひょっとしたら、直前が第２バイトであり、そこは本当に｛や｝かもしれないのである。
だからもう一つ前から調べればだいたい大丈夫なのだが、
それでも運が悪いと間違えてしまう。
結局シフトＪＩＳは、最初から順繰りに処理していかないとダメなコード体系なのである。
それをしないでいきなり「ここは第２バイト目かな？」と言われてもわからないのだ。
Ｃでのやり方の例がこちらにあるが、
結局文字列を最初からスキャンして調査しているわけである。
そんなわけで私のプログラムも、「｛を見つけて」という部分は、
開発ツールの組み込み関数を使えず、自分で一文字一文字調べていく方式になってしまい、
いまいち効率のよくないものになってしまった。
これ、｛をトリガーにしたのがいけないのだ。
では何ならよかったかというと、
単に半角１文字であれば、必ずそれはシフトＪＩＳの２バイト目とバッティングしてしまうので、
｛｛ から ｝｝ まで、というふうに、
トリガーの文字列を２文字以上にしてしまえばよかったのである。
これなら絶対に間違わない。
しかし、こういうことがわかったときには遅かった。
もうすでに、｛ ｝方式で書いたソースのソースが大量になってしまい、
いまさら変更できなくなっていまったというわけである。
思えば最初にこの症状が出たときに、原因を徹底調査すればよかった。
｛ の直前で改行するとこの症状が出なくなったので、
それでかわしていたのが致命的であった。
問題点はその場で一つ一つ解決していかないと、後で困るという例である。
もっとも、｛｛ よりは ｛ のほうがはるかに入力はラクなので、
これはこれでよかったのかもしれないが。
実は、「ソースのソース」式に移行するときも、
それまでに手でIMG SRCタグを打ち込んだファイルがけっこうあり、
これを逆に｛ ｝式に直すという、
今にして思えばちっとも役立たないプログラムを作るハメになってしまった。
最初こそ、このプログラムは大活躍したが、
すべて「ソースのソース」式にしてしまった今ではお払い箱である。
これも「はじめが悪いと後で苦労する」例。
最初の方式設計は大事である。
けっこう長文になってしまったので以下続刊。
|
に戻り、掲示板あるいはメールで賜るとありがたく思います。