[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:www.NetBSD.orgの日本語訳のwww.jp.NetBSD.orgでの公開について

佐藤です。

 筒井さんのメールがなぜか届いていないので、
 回答が孫引きで混ざってしまってます。すみません...

Ryo ONODERA <ryo_on@yk.rim.or.jp> wrote
  in <20110818.224748.255571566.ryo_on@yk.rim.or.jp>:

ry> 私の理解が間違っているのかもしれませんが、
ry> 今のxmlファイルはiso-2022-jpに統一されていて、
ry>
ry> <?xml version="1.0" encoding="ISO-2022-JP"?>
ry> <!DOCTYPE webpage
ry>   PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//EN"
ry>     "http://www.NetBSD.org/XML/htdocs/lang/share/xml/website-netbsd.dtd">
ry>
ry> <webpage id="ja-changes-1998">
ry> <config param="desc" value="1998 年の変更と NetBSD ニュース"/>
ry>
ry> のように、正しくencodingも書かれていると思います。

 いえ、

  1. XML が UTF-8 で書かれていること

  2. XSLT が UTF-8 で書かれていること

  3. 出力される HTML が UTF-8 になること

 は、すべて独立しています。それぞれ個別に決めないといけなくて、
 何も指定しないと、すべてのデフォルトが UTF-8 になる、というのが処理の実際です。
 また、これら全部が指定されていても、entity reference (&xxx;) は
 別の理由でエンコーディングに関する注意が必要になります。

 &xxx;が化けるのは、XML ソースファイルが iso-2022-jp で書かれているのに、
 &xxx; を UTF-8 の固定ビットパターンに置き換えるという、誤った定義ファイルが
 使われているからです (定義全体は textproc/iso8879 などに入ってます)。

 非 iso-8859-1 圏の言語を処理する場合、
 この定義ファイルを出力エンコーディングに合ったものにするか、
 文字列の entity は展開せず、&xxx; のままで処理させるか、が典型的な
 方法ですが、HTML にする場合は後者が無難なので、後者にすることが多いです。

  # 最近のウェブブラウザは優秀なので、文字コードの扱いとして HTML 4.01 だと
  # SGML, XHTML では XML の流儀を使ってくるので、非常にめんどうなのです...

 SGML や XML まわりの文字コードの扱いは厳格なルールがありますので、
 慣れないと良く分からない → UTF-8 に統一すれば簡単じゃん、という
 流れで UTF-8 を使いましょう、にたどり着くのは、確かにそうなので
 悪い考え方だとは思わないのですが、
 そうするのであれば、最終成果物を XHTML にして、入力・出力データを
 すべて UTF-8 にするという徹底した方法をとらないと、また同じ問題が
 生じると思います。

 小難しい話はどうでも良いから、単に &copy;, &reg;, &nbsp; の〓を
 なくしたいというのであれば、

  <!ENTITY copy "(C)">
  <!ENTITY reg "(R)">
  <!ENTITY nbsp " ">

 という行を DTD に突っ込んで rebuild すれば達成できると思います。

 XSLT で処理した後にスクリプト等で置き換えようという考え方は、
 XML で書いている意味がまったくなくなってしまうので、なるべく捨てましょう。

ry> 私は、htdocs/JP/までUTF-8にしなくても良いのではないかと思っていますが、
ry> cvswebでの表示を考えると、合わせておいた方が見やすいとかあるかも
ry> しれないと思います。
ry>
ry> >  他のページの文字コードって、決まってるんでしたっけ? > どなたか詳しいひと
ry>
ry> http://www.jp.netbsd.org/ja/JP/ml/admin-ja/199812/msg00107.html
ry> で、JIS(ISO-2022-JPということだと理解しますが)という意見が出ています。
ry> htdocs/JP/以下には、ISO-2022-JPに統一するという記述はないようです。

 サイト全体としてのポリシがなくて、文字コードが違ってても
 誰も気にしないのであれば、それで良いのではないでしょうか。

 佐藤は、XML ベースのソースから生成される HTML ファイル群の
 エンコーディングを、既存のものと合わせる操作が、
 そんなに大変なことだと考えていなくて、
 わざわざ別のエンコーディングを選択する理由はあるのかな、という点に
 疑問を持っていました。

 同じウェブサイトなら一貫性があったほうが良さそうだ、というのは、
 その延長上にある、多分に感覚的な意見です。

 問題が良く分かってないのですが、&xxx; の文字が化けるという以外に
 エンコーディングの問題はあるのでしょうか?  「たくさんあって UTF-8 にしないと
 解決できない」というのであれば、UTF-8 を選ぶのに躊躇する必要はないと思います。

> From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
> > これは本家でも同じですし、これぞという解決策があるわけでもないので、
> > ja ローカルで懸念していても意味がないような気がします。

 公開するサーバ側で定期的に自動 build することで解決になると思うのですが、
 それでは解決になりませんか?

 それが不可能だというのであれば、HTML ファイルを commit することに
 異論はありません。両方が可能だとしたら、HTML ファイルを commit することは
 不利な点がたくさんあるので、止めたほうが良いと考えています。

 単なる typo の修正を commit しても、XML のツールを全部インストールしている
 マシンで rebuild して HTML ファイルを commit しないと
 反映させることができない、というのは、すごく不都合な側面だと思っています。

ry> 以上書きましたが、cronでできるのであれば、それがベストだと思います。
ry> 自分の修正したxmlについてだけmake xxx.htmlしても、修正によっては
ry> 全体を作り直さないといけない時もあって、ややこしくなるかも
ry> しれませんので。
ry>
ry> マシンリソースに余裕があるのであれば、マンパワーは提供します。

 いずれにしても、build に必要なファイル群を commit しなければならないことには
 変わりはないと思いますので、これと思う変更を加えながら考えるのは
 いかがでしょう?

-- Hiroki

PGP signature