Change the encoding of the Japanese docs to UTF-8

This commit is contained in:
Shun Sakai
2020-05-06 21:54:30 +09:00
parent d95c6eb5aa
commit d2283055e2
49 changed files with 5387 additions and 5387 deletions

View File

@@ -1,193 +1,193 @@
<html>
<head>
<title>w3mの開発について</title>
<title>w3mの開発について</title>
</head>
<body>
<h1>w3mの開発について</h1>
<h1>w3mの開発について</h1>
<div align=right>
1999/2/18<br>
1999/3/8改訂<br>
伊藤 彰則<br>
1999/3/8改訂<br>
伊藤 彰則<br>
aito@fw.ipsj.or.jp
</div>
<h2>はじめに</h2>
w3mはWWWに対応したページャ/ブラウザで,テキストベースで動く.
w3mに最も近いアプリケーションとして有名なテキストベースブラウザ
<a href="http://www.lynx.browser.org/">Lynx</a>があるしかしw3mには
Lynxにないいくつかの特徴がある例えば
<h2>はじめに</h2>
w3mはWWWに対応したページャ/ブラウザで,テキストベースで動く.
w3mに最も近いアプリケーションとして有名なテキストベースブラウザ
<a href="http://www.lynx.browser.org/">Lynx</a>があるしかしw3mには
Lynxにないいくつかの特徴がある例えば
<UL>
<LI>tableがレンダリングできる
<LI>frameがレンダリングできる(frameをtableに変換して表示するだけ)
<LI>標準入力を読んで表示することができる.
(最近のLynx では,こんな風にして標準入力から文書を読むことができる
そうです:
<LI>tableがレンダリングできる
<LI>frameがレンダリングできる(frameをtableに変換して表示するだけ)
<LI>標準入力を読んで表示することができる.
(最近のLynx では,こんな風にして標準入力から文書を読むことができる
そうです:
<pre>
lynx /dev/fd/0 &lt; file
</pre>
うんLinuxでは確かに動くようです)
<LI>軽くて小さいstripした後のw3mのバイナリサイズはSparcの場合で
260KByte弱である(version beta-990217現在)
ちなみにLynxのバイナリは 1.8MB以上ある.
うんLinuxでは確かに動くようです)
<LI>軽くて小さいstripした後のw3mのバイナリサイズはSparcの場合で
260KByte弱である(version beta-990217現在)
ちなみにLynxのバイナリは 1.8MB以上ある.
</UL>
などだもちろんLynx は優れたブラウザでw3mにない多くの機能を
持っているLynxにあってw3mにない機能は例えば
などだもちろんLynx は優れたブラウザでw3mにない多くの機能を
持っているLynxにあってw3mにない機能は例えば
<UL>
<LI>Cookie対応
<LI>豊富なオプション設定.
<LI>多国語対応.
<LI>Cookie対応
<LI>豊富なオプション設定.
<LI>多国語対応.
</UL>
などなどLynx には豊富なドキュメントもあり一方w3mにはほとんどまともな
ドキュメントがない.ドキュメントは今後の課題だ.
などなどLynx には豊富なドキュメントもあり一方w3mにはほとんどまともな
ドキュメントがない.ドキュメントは今後の課題だ.
<P>
というわけでw3mは既存のブラウザ(NetscapeはもちろんLynxも)を代替
するものでは<strong>ない</strong>それではw3mは何のためにあるのか
それは,日常的に「ちょっと」 web を使うためだ.専用線で接続された環境で,
「ちょっとwebを見に行きたい」ときNetscapeを立ちあげるのはイライラする
Lynxも立ちあがるのにちょっと間がある
その点w3mは一瞬で立ちあがりマシンにほとんど負担をかけない
そこで情報を見て,もっと詳細に見たいときに,はじめて他のブラウザを使う
のだもっとも私の場合ほとんどはw3mだけで十分なのだが
というわけでw3mは既存のブラウザ(NetscapeはもちろんLynxも)を代替
するものでは<strong>ない</strong>それではw3mは何のためにあるのか
それは,日常的に「ちょっと」 web を使うためだ.専用線で接続された環境で,
「ちょっとwebを見に行きたい」ときNetscapeを立ちあげるのはイライラする
Lynxも立ちあがるのにちょっと間がある
その点w3mは一瞬で立ちあがりマシンにほとんど負担をかけない
そこで情報を見て,もっと詳細に見たいときに,はじめて他のブラウザを使う
のだもっとも私の場合ほとんどはw3mだけで十分なのだが
<h2>w3mの誕生</h2>
<h2>w3mの誕生</h2>
<P>
w3m の前身はfm
というページャ(moreやlessの親戚)だったfmが書かれたのは1991年以前
(記録していなかったので正確な日付はわからない)で当時まだWWWは
一般的ではなかった(存在しなかったかも)その当時「ブラウザ」といえばlessなどの
ファイルを見るツールのことを指していた.
w3m の前身はfm
というページャ(moreやlessの親戚)だったfmが書かれたのは1991年以前
(記録していなかったので正確な日付はわからない)で当時まだWWWは
一般的ではなかった(存在しなかったかも)その当時「ブラウザ」といえばlessなどの
ファイルを見るツールのことを指していた.
<P>
fm は,当時私が書いていた
研究用のプログラムをデバッグするために書いたものだ.プログラムの状態
をトレースするため,プログラムの内部状態を延々とファイルにダンプし,
それを見ながらデバッグをしていたある時点での内部状態を1行にプリント
していたためそのファイルは1行が数百文字あったそれをmoreやlessで
見ると,行が折り返されるため,何が何だかわからなくなってしまうのだった.
そこで私は行を折り返さないページャであるfmを書いた物理的な1行は
画面の上でも1行で画面からはみ出した部分を見るには画面全体をずらす
という設計にした当時私は80x24の画面を使っていたのでfm はデバッグ
にとても役立った.
fm は,当時私が書いていた
研究用のプログラムをデバッグするために書いたものだ.プログラムの状態
をトレースするため,プログラムの内部状態を延々とファイルにダンプし,
それを見ながらデバッグをしていたある時点での内部状態を1行にプリント
していたためそのファイルは1行が数百文字あったそれをmoreやlessで
見ると,行が折り返されるため,何が何だかわからなくなってしまうのだった.
そこで私は行を折り返さないページャであるfmを書いた物理的な1行は
画面の上でも1行で画面からはみ出した部分を見るには画面全体をずらす
という設計にした当時私は80x24の画面を使っていたのでfm はデバッグ
にとても役立った.
<P>
そのうち私もWWWの存在を知って使いはじめた当時使っていたブラウザは
XMosaic と Chimera だった.特に Chimera は軽いので愛用していた.
興味があったので HTML と HTTP の勉強をしてみたが,案外簡単なので,
これなら自分でもブラウザが書けるのではないかと思った当時のHTTPは
GOPHERプロトコルに毛が生えた程度で非常に簡単なものだったまた
HTML は 2.0 で,行の折り返しと箇条書きがほとんど全てだった.
そこでfm にちょっと手を入れてWWWブラウザを作ってみたこれがw3mだった
ちなみにw3m は WWW-wo-Miru (日本語だ)の略でfm (File-wo-Miru)に
倣った.最初に w3m を書いたのは1995年初頭だったと思う
そのうち私もWWWの存在を知って使いはじめた当時使っていたブラウザは
XMosaic と Chimera だった.特に Chimera は軽いので愛用していた.
興味があったので HTML と HTTP の勉強をしてみたが,案外簡単なので,
これなら自分でもブラウザが書けるのではないかと思った当時のHTTPは
GOPHERプロトコルに毛が生えた程度で非常に簡単なものだったまた
HTML は 2.0 で,行の折り返しと箇条書きがほとんど全てだった.
そこでfm にちょっと手を入れてWWWブラウザを作ってみたこれがw3mだった
ちなみにw3m は WWW-wo-Miru (日本語だ)の略でfm (File-wo-Miru)に
倣った.最初に w3m を書いたのは1995年初頭だったと思う
<h2>w3mの没落と再生</h2>
<h2>w3mの没落と再生</h2>
<p>
それ以来,ずっと私は w3m を「ページャ」として使っていた.ファイルや
電子メールマニュアルなどを読むときにlessの代わりにしていたのだ
w3mでwebを見ることも時々あったがその後 w3m で正常に見られないページが
多くなった(その多くはtableを使っていた)こともあってwebブラウザと
してはほとんど使わなくなっていた.一度 table のレンダリングを検討
したことがあったが,難しいので放ってあった.
それ以来,ずっと私は w3m を「ページャ」として使っていた.ファイルや
電子メールマニュアルなどを読むときにlessの代わりにしていたのだ
w3mでwebを見ることも時々あったがその後 w3m で正常に見られないページが
多くなった(その多くはtableを使っていた)こともあってwebブラウザと
してはほとんど使わなくなっていた.一度 table のレンダリングを検討
したことがあったが,難しいので放ってあった.
<P>
もう一度 w3m に手を入れる気になったのは1998年のことだ動機は2つあった
その当時,私は客員研究員としてボストン大学に滞在しており,多少時間に余裕があった
ことが一つ.もう一つは,研究日誌を HTML で書いていて,結果をどうしても表に
したくなったためだ.それまでは表を &lt;pre&gt;..&lt;/pre&gt;で書いていたのだが,
plain textで表を作るのがわずらわしくて仕方なかったとうとう我慢できなくなって
&lt;table&gt;タグを使ったが,そうすると今度は Netscape を使わないと日誌が
見られなくなってしまったそこでw3m で table の
レンダリングができるようにしようと試みた.
もう一度 w3m に手を入れる気になったのは1998年のことだ動機は2つあった
その当時,私は客員研究員としてボストン大学に滞在しており,多少時間に余裕があった
ことが一つ.もう一つは,研究日誌を HTML で書いていて,結果をどうしても表に
したくなったためだ.それまでは表を &lt;pre&gt;..&lt;/pre&gt;で書いていたのだが,
plain textで表を作るのがわずらわしくて仕方なかったとうとう我慢できなくなって
&lt;table&gt;タグを使ったが,そうすると今度は Netscape を使わないと日誌が
見られなくなってしまったそこでw3m で table の
レンダリングができるようにしようと試みた.
<P>
私としては,それほど複雑でない表を見ることができれば十分だった.ところが,
半端にtableに対応した結果画面のレイアウトにtableを使っているページの
表示がぐちゃぐちゃになってしまった.結局,「表が見られて」「その他のページ
もそこそこに見られる」ようにするためにはtableの表示が完璧に近くなければ
ならないのだった.茨の道だ.
私としては,それほど複雑でない表を見ることができれば十分だった.ところが,
半端にtableに対応した結果画面のレイアウトにtableを使っているページの
表示がぐちゃぐちゃになってしまった.結局,「表が見られて」「その他のページ
もそこそこに見られる」ようにするためにはtableの表示が完璧に近くなければ
ならないのだった.茨の道だ.
<P>
結局,結構時間がかかったが,何とか
実用になるものができたと思うtable の実装に気をよくして,次に form を実装
したこれでw3mはほぼ実用になるブラウザとして生まれ変わったのだ
結局,結構時間がかかったが,何とか
実用になるものができたと思うtable の実装に気をよくして,次に form を実装
したこれでw3mはほぼ実用になるブラウザとして生まれ変わったのだ
<h2>w3mでのtableのレンダリングアルゴリズム</h2>
<h2>w3mでのtableのレンダリングアルゴリズム</h2>
HTMLのtableのレンダリングは結構難しいLaTeX の tabular のように,
「表の各列の幅を指定するか,さもなければ必要な最大の幅を取る」
というのなら話は簡単なのだがHTMLのtableは「画面に適当に収まるように」
列の幅を設定して,表の内容を適当に折りかえさなければならない.
幅の決定をいいかげんにすると,非常に表が見づらくなってしまう.
またtableは入れ子にできるのでそれが話を一層ややこしくしている
そこでw3mでは次のようなアルゴリズムで幅を決定している
HTMLのtableのレンダリングは結構難しいLaTeX の tabular のように,
「表の各列の幅を指定するか,さもなければ必要な最大の幅を取る」
というのなら話は簡単なのだがHTMLのtableは「画面に適当に収まるように」
列の幅を設定して,表の内容を適当に折りかえさなければならない.
幅の決定をいいかげんにすると,非常に表が見づらくなってしまう.
またtableは入れ子にできるのでそれが話を一層ややこしくしている
そこでw3mでは次のようなアルゴリズムで幅を決定している
<OL>
<LI>まず,各列の内容の最大幅と最小幅を求める.最大幅というのは,
もしいくらでも広い幅が取れたとしたら,最大何桁になるかというもの
だ.一般的には,&lt;BR&gt;&lt;P&gt;で区切られた段落の長さになる.
最小幅は,それより列の幅が狭いと内容が詰められないという限界の幅
である表の内容が日本語だけの場合には最小幅は常に2であり
internationalization という単語が含まれていれば最小幅は20
である.また,表の中に&lt;pre&gt;..&lt;/pre&gt;があった場合,
その一行の長さの最大値が最小幅になる.
<LI>もしWIDTH属性で列の幅が指定してあれば列の幅をその値で固定
する.ただし,その幅が最小幅よりも小さければ,列の幅を最小幅で固定する.
<LI>列の最大幅(または固定幅)を合計して,画面の幅よりも広いかどうかを調べる.
もし合計が画面に収まるなら,その値を各列の幅として使う.
<LI>もし合計が画面に収まらなければ,次のようにして幅を決定する.
<LI>まず,各列の内容の最大幅と最小幅を求める.最大幅というのは,
もしいくらでも広い幅が取れたとしたら,最大何桁になるかというもの
だ.一般的には,&lt;BR&gt;&lt;P&gt;で区切られた段落の長さになる.
最小幅は,それより列の幅が狭いと内容が詰められないという限界の幅
である表の内容が日本語だけの場合には最小幅は常に2であり
internationalization という単語が含まれていれば最小幅は20
である.また,表の中に&lt;pre&gt;..&lt;/pre&gt;があった場合,
その一行の長さの最大値が最小幅になる.
<LI>もしWIDTH属性で列の幅が指定してあれば列の幅をその値で固定
する.ただし,その幅が最小幅よりも小さければ,列の幅を最小幅で固定する.
<LI>列の最大幅(または固定幅)を合計して,画面の幅よりも広いかどうかを調べる.
もし合計が画面に収まるなら,その値を各列の幅として使う.
<LI>もし合計が画面に収まらなければ,次のようにして幅を決定する.
<OL>
<LI>画面の幅から,幅が固定された列の幅の合計を引く.これを W とする.
<LI>幅が固定されていない列に対して,各列の最大幅の対数に比例して W を配分する.
<LI>もし配分された幅が最小幅よりも小さければ,その列の幅を最小幅で固定し,
幅の配分をやり直す.
<LI>画面の幅から,幅が固定された列の幅の合計を引く.これを W とする.
<LI>幅が固定されていない列に対して,各列の最大幅の対数に比例して W を配分する.
<LI>もし配分された幅が最小幅よりも小さければ,その列の幅を最小幅で固定し,
幅の配分をやり直す.
</OL>
</OL>
幅の配分を最大幅の対数に比例させているが,これでいいのかどうか検討を要する.
ただし最大幅そのものに比例させると悲惨なことになるtable を画面レイアウト
に使っていた場合,ある列に長い文章があると,その列が画面の幅のほとんどを使って
しまうからだ.対数じゃなくて n 乗根でもいいかもしれない.
幅の配分を最大幅の対数に比例させているが,これでいいのかどうか検討を要する.
ただし最大幅そのものに比例させると悲惨なことになるtable を画面レイアウト
に使っていた場合,ある列に長い文章があると,その列が画面の幅のほとんどを使って
しまうからだ.対数じゃなくて n 乗根でもいいかもしれない.
<P>
上記のアルゴリズムでは,画面の幅が既知であることが前提になっている.ところが,
これでは困る場合がある.どういう場合かというと,表が入れ子になっている場合だ.
外側の表の列幅がわからないと内側の表がレンダリングできないが,内側の表を
レンダリングしてみないと外側の表の幅が決定できないという矛盾に陥るWIDTH属性
が指定してあれば問題はないのだが,そうでない場合には,結局
「内側の表の幅は外側の表の幅の0.8倍」で決め打ちしてしまうことにした.
ほとんどの場合はこれで問題ないがある表の中に表を入れ子にして2つ並べると
外側の表が必ず画面をはみだしてしまうようになった.もし厳密にこれを画面に収め
ようとすると,一旦レンダリングして全体の幅を調べたあと,幅を設定しなおして
もう一度レンダリングするという過程を収束するまで繰り返さなければならない.
Netscapeは多分これをやっているのだろう
上記のアルゴリズムでは,画面の幅が既知であることが前提になっている.ところが,
これでは困る場合がある.どういう場合かというと,表が入れ子になっている場合だ.
外側の表の列幅がわからないと内側の表がレンダリングできないが,内側の表を
レンダリングしてみないと外側の表の幅が決定できないという矛盾に陥るWIDTH属性
が指定してあれば問題はないのだが,そうでない場合には,結局
「内側の表の幅は外側の表の幅の0.8倍」で決め打ちしてしまうことにした.
ほとんどの場合はこれで問題ないがある表の中に表を入れ子にして2つ並べると
外側の表が必ず画面をはみだしてしまうようになった.もし厳密にこれを画面に収め
ようとすると,一旦レンダリングして全体の幅を調べたあと,幅を設定しなおして
もう一度レンダリングするという過程を収束するまで繰り返さなければならない.
Netscapeは多分これをやっているのだろう
<h2>利用したライブラリ</h2>
<h2>利用したライブラリ</h2>
w3m は,
w3m は,
<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm GC</a>
というライブラリを利用している.これは私が書いたものではないが,
コンパイル時の便宜を考えて配布パッケージに含めている.
というライブラリを利用している.これは私が書いたものではないが,
コンパイル時の便宜を考えて配布パッケージに含めている.
<P>
# Boehm GC は、w3m-0.4.2 以降のパッケージには含まれていません。
# Boehm GC は、w3m-0.4.2 以降のパッケージには含まれていません。
<P>
なおlibwww は使っていない.
なおlibwww は使っていない.
<P>
Boehm GCはCから使えるガベージコレクタだtable を実装したあたりにこれを
使いはじめたのだが非常に快適だったGCなしではw3mにtableやformを実装
する根性が私にあったかどうか疑わしいBoehm GCの利用については
Boehm GCはCから使えるガベージコレクタだtable を実装したあたりにこれを
使いはじめたのだが非常に快適だったGCなしではw3mにtableやformを実装
する根性が私にあったかどうか疑わしいBoehm GCの利用については
<a href="http://homepage2.nifty.com/aito/gc/gc.html">
Boehm GCを使おう</a>」という文章を書いたので,それも見ていただけると良い
と思う.
Boehm GCを使おう</a>」という文章を書いたので,それも見ていただけると良い
と思う.
<P>
beta-990304より前のバージョンでは
<a href="http://home.cern.ch/~orel/libftp/libftp/libftp.html">LIBFTP</a>
いうライブラリを使っていた.
libftp を使った理由はFTPプロトコルが HTTP に比べて面倒だったためだ.
しかし,ライセンスの問題がありそうだということなので,同等の関数(のサブセット)
を自前で書いてしまった.
beta-990304より前のバージョンでは
<a href="http://home.cern.ch/~orel/libftp/libftp/libftp.html">LIBFTP</a>
いうライブラリを使っていた.
libftp を使った理由はFTPプロトコルが HTTP に比べて面倒だったためだ.
しかし,ライセンスの問題がありそうだということなので,同等の関数(のサブセット)
を自前で書いてしまった.
<P>
ちなみにw3mはUNIXの正規表現ライブラリと curses ライブラリを使っていない.
どちらも自前の関数群だこれらを自前で用意した理由はfmを書いた当時
日本語の通るまともでフリーな正規表現とcursesのライブラリがなかったためだ
現在ではどちらも存在するし,他のライブラリを使った方が速そうなのだが,
面倒なので現在までこの実装を引きずっている.
ちなみにw3mはUNIXの正規表現ライブラリと curses ライブラリを使っていない.
どちらも自前の関数群だこれらを自前で用意した理由はfmを書いた当時
日本語の通るまともでフリーな正規表現とcursesのライブラリがなかったためだ
現在ではどちらも存在するし,他のライブラリを使った方が速そうなのだが,
面倒なので現在までこの実装を引きずっている.
<h2>今後の予定</h2>
<h2>今後の予定</h2>
...ないw3mは軽快さが売りなのであまり機能を満載してしまうとw3m独自の
良さが失われるからだとはいってもまだバグが多いのでそれらのfixは
していきたいと思っている.
...ないw3mは軽快さが売りなのであまり機能を満載してしまうとw3m独自の
良さが失われるからだとはいってもまだバグが多いのでそれらのfixは
していきたいと思っている.
</body>
</html>