Index: [Article Count Order] [Thread]

Date:  Mon, 28 Feb 2000 16:17:25 +0900
From:  monyo@home.monyo.com
Subject:  [analog-jp:00017] Re: 今回の日本語の問題に付いて
To:  analog-jp@monyo.com
Message-Id:  <20000228161721F.monyo@home.monyo.com>
In-Reply-To:  Your message of "Mon, 28 Feb 2000 14:46:33 +0900"	<200002281442.JIH99816.OLBBUB@c-netc.co.jp>
References:  <200002281442.JIH99816.OLBBUB@c-netc.co.jp>
Posted:  Mon, 28 Feb 2000 16:17:21 +0900
X-Mail-Count: 00017

  たかはしもとのぶです。

# ML 開設の挨拶の方がまだできていない...(^^;

>田中@シーネットです。
>
>このML立上げのきっかけににも成った訳ですが、ISO-2022-JP、
>EUC、SJISでのjp.lng記述と、analog側の仕様による問題とを整理
>して頂ければと思います。

以下、そのときにやりとりしたメールを適当に切り貼りします。

まず、analog の lang ファイルでは、現在のところ EUC-JP 以外の文字コー
ドは使えません。したがって、他の文字コードを利用したいときは、一回 
EUC-JP で出力してから、他の文字コードに変換する必要があります。

これらの問題に付いては、今後は対応して行きたいとのことでしたので、取り
敢えずオライリーの日本語情報処理の紹介と、Samba の kanji.c というファ
イル中での日本語の扱いとを参考情報として伝えておきました。

1. JIS がダメな理由
===================

  JIS コードで文字化けする件は原因が分かりました。長文ですが、私の頭の
中では今回の現象は完全に理解したつもりですので、もし不明な点がありまし
たら、ご遠慮無くお問い合わせください。
  それでは、以下長文ですが、解説します。

  JIS コードは 0x0 - 0x7f の範囲(7bit)だけを用いて2byte 文字の漢字を表
現しようという目的で策定された文字コードです。このため、文字コードとし
て用いる範囲は 1byte 目、2byte 目ともに 0x21-0x7e の範囲となっています。

  ところで、output2.c 中の 226 行目あたりでは HTML 中で直接表記できな
い '<' 文字(文字コード 0x3c)や '>'(同0x3e), '&'(同0x26)、'"'(同0x22)を
各々'&lt;' 等に変換するという処理を行なっています。

  ここで、例えば 'ー' (0x213c) という文字コードの文字は、2 byte 目が 
'>' であるため、'&lt;' に置き換えられ 0x21266c743b という文字列に変換
されてしまいます。これが JIS コードで文字化けしてしまう理由です。
 
  ちなみに SJIS コードで使用するのは 0x40-0xfc 、EUC では JIS 補助漢字
(JIS X 0212-1990)を使わない限り 0xa1 -0xfe の範囲のため、この問題は発
生しませんが、そのかわり文字は 7bit で表現されるという前提で処理を行なっ
ているロジックがあるとそこで問題が発生します。ただ、ちゃんとチェックし
たわけではありませんが、幸い analog ではそういう処理を行なっているとこ
ろはないようです。

  現状 2 byte 文字に完全に対応するには、全ての文字列処理関数で、いま 
2byte 文字を処理しているかどうか、また 2byte 文字の 1 byte 目を処理し
ているのか、それとも 2 byte 目を処理しているのかを常に意識しながら処理
を行なうか、Unicode 等を使うしかありません。
しかも、ある文字列を見たときに、どの 2 byte が 2byte 文字を構成してい
るかを判断するロジックは文字コード固有にならざるを得ないので、簡単に挿
入できるようなものではありません。

  ということで、現状を考えると、こういった問題があるので JIS コードで
の出力はサポートしないことに割り切るのが現実解だと思います。
私自身以前 JIS 出力を主張したので申し訳ないとは思いますが、よろしくお
願いします。

  また、日本語以外の 2 byte 文字コードでも、0x40 より下を利用している
コード(GB 2312-80 の 7bit コード、KS C 5601-1992 の 7bit コード)等では、
同様の問題が発生しますので、lang ファイルのポーティングを考えている方
のためにもドキュメントのどこかに追記してもらったほうがよいと思います。

2. SJIS がダメな理由
====================

以下、松木さんが Analog の開発者である Turner に送ったメールです。
ISO-8859 (西ヨーロッパ言語)に対応する過程で、文字コードが 0x80-0xff の
文字コードの変換処理が入っているのですが、このロジックが日本語に対応し
ていないために、SJIS だと文字化けが発生してしまうようです。

I found that SJIS doesn't work either in the "Search Word
Report". This may be due to the following part of init.c (line 774-779)

    /* Set the convfloor (see do_alias(n|N)). We only do this approximately:
       convert A0-FF for ISO-8859-*, 80-FF o/wise. This may still include some
       non-printable characters! But we can't have a table for every charset.*/
    if (!op->outopts.searchconv ||
        strcaseeq(op->outopts.lngstr[charset_], "US-ASCII"))
      op->outopts.convfloor = 0;

By using the same pharases as before we could succeed in producing all the
meaningful HTML output so far.

Would you try the attached file? If you still feel uneasy with this file,
please put your HTML output in some directory and let me know the URL so that
we can check it from Japan.

-----
Motonobu TAKAHASHI (高橋 基信)        mailto:monyo@home.monyo.com
                                      http://home.monyo.com/