加藤(大阪)です。 Sat, 21 Dec 2002 09:39:54 +0900 付 Masaki SHINOMIYA <shino@xxxxxx> さんのメールより: > シノバーです > ・・・・・・ > GLOBALというのをインストールしました。 > http://www.gnu.org/software/global/ > ソースのあるディレクトリで > $ gtags > $ htags > でHTMLができあがり、webブラウザでソースが読めます。 面白い情報、有り難うございます、早速インストールしてみました (^ ^;; 少し試しただけですが、関数一覧機能や、呼び出し先等がマウスクリックで表示でき、 エディタの検索機能不用みたいな感じで。 大きなソースを見るときには、使い手が有りそうですね。 > libxmlのほうをずぅっと眺めていて、 > 余分なバイトが加えられるのはどうもここらしいというのが見付かりました。 > parser.c中のxmlCopyCharMultiByteという関数です。 > 非ASCII文字をCOPY_BUFしようとするとこの関数が呼ばれます。 > > この関数の中で非ASCII文字はUTF-8に変換したうえでコピーします。 > libxmlの仕様だとこれまで考えていたのですが、腑に落ちないところもありますね。 > どうして無条件にこの変換をやってしまうのか? > 入力はiso8859-1を仮定しているようですが。 euc-jp の様に、最上位ビットが立っている二文字を読み込むと、無条件に 1バイト ずつ(val < 0x800) で処理してしまっている、とすれば確かに、「あ」の euc-jp コード a4a2は、c2,a4, c2,a2 に変換されてしまうようですね。 これを euc-jp で表示すれば「蔵造」の二文字になるのですが、確かに、旧parser 利用の gnumericで「あ」を入力、保存し、新parser 利用の gnumericで読み込むと、 予想通り「蔵造」と表示されました。 「蔵造」と表示されている状態で(「新」で)再保存し再読み込みすれば、ちゃんと？ 「蔵造」と表示されるところを見れば、UFT-8 ベースでは正常に変換されているの かも？しれませんね。 UFT-8 の漢字コード表のようなものが有れば「あ」入力相当の xml ファイルを作って 試してみることも出来るのですが・・・ 何れにしろ、今の Vine ベースでは、新parser ベースでの利用が可能な訳では無いで しょうが。 > gnumeric-1.0.11のこの問題はDebianでも上がってきました。 > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=173732 英文はまったく苦手で、@nifty 翻訳サイト(http://www.nifty.com/globalgate/)で 拾い読みしただけですが、再読み込み時にデコードミスを起こすと言う事のようですね。 'accented characters'の意味が分かりませんが、「最上位ビットが立った」と同等なら、 我々が遭遇している問題もこれに含まれるのでしょうね。 # Vine ML での話題としては、この位が限界のような気がしないでも無いです・・・ --- 加藤 雅 <mkato@xxxxxxxxxxxxx> http://isweb15.infoseek.co.jp/diary/add10/rox/