多符号化対応w3m

### 多符号化方式対応 w3m

以下の方式で符号化された文字セットに対応させたw3mの亜種を公開します:

- ISO 2022
- UTF-8、UTF-16、UTF-16BE、UTF-16LE
- Shift_JIS
- Big Five
- EUC-tw
- GBK、GB 18030-2000 (a.k.a. GBK2K)
- Johab
- Unified Hangul
- KOI8-R
- KOI8-U
- Microsoft Windows Codepage 1250 〜 1258

…だけのつもりだったのだけれども、 諸般の事情により

- ローカルファイルやHTTPレスポンスのボディのencodingの処理プログラムを実行時に動的に指定可能、
- ローカルファイルの言語を表わす拡張子(content-typeの推定に使われない拡張子)が指定可能、
- ユーザ関数を多ストロークキーにバインドできる(今のところ2ストロークまで)、
- 1行編集のキーバインドも変更可能(keymap中で「E:」で始まる名前の関数を指定すればよい)、
- メニュー操作のキーバインドも変更可能(keymap中で「M:」で始まる名前の関数を指定すればよい)、
- ページの取得・レンダリングを別プロセスで並列に行うことが可能、 さらにHTTP/1.1の「keep alive」接続にも対応、
- 「-dump」や関数SAVE_SCREENの出力中で、 アンカー や 画像へのリンク を番号付き・一覧付きにできる、
- 任意のHTTPリクエストヘッダを実行時に動的に指定できる、
- mailcapエントリ中の文字列展開の拡張、
- 「browsecap」のサポート、
- 長い行の折り返し表示のサポート、
- (ほとんど)本物のフレーム (≒タイリングウィンドウシステム) のサポート、
- 組み込みの1行エディタにおける補完の強化 (とにかくTABをたたきませう)、

という拡張も加えられます。

### 現在の状態

UnicodeとISO 2022が混在するページ が、 期待したとおりにレンダリングされ、 kterm上でISO 2022を使って、 またはxterm上でUnicodeを使って表示できることは確認しています。 ただしフォントの無い文字は画面に怪しげなゴミの出ることがありますが、 これはフォントが揃えば無くなる筈です。

JIS X 0208以外の2バイト文字セットを入力ルーチンが正しく扱えるかは、 入力する環境がないのでまったくテストしていません。 右から左に向って書き進める言語のことはまったく考えていません。 テストに使った端末(エミュレータ)は、 kterm(-6.2.0)、 utf-8サポート付きのxterm(-165)、 及びeuc-jpサポート付きのrxvt(-2.6.3)です。

私自身は常用ブラウザを、 素のw3mからこの亜種に完全に移行してしまいました。

### インストール

「多符号化拡張」部分が必要ならば、 まず サポートライブラリ をインストールする必要があります。 多くのPOSIX準拠な環境では、 tarballを展開したディレクトリに移動し、 rootとして

> make install ; ldconfig

とするだけでよいのではないかと思います。 なおサポートライブラリはできる限り最新のものをお使い下さい。 「多符号化拡張」部分が必要無い場合はライブラリのインストールは不要です。

さらにBoehm-GC libraryも、 別にインストールする必要があります。 gc.h(と場合によってはpirvate/gc_priv.h)は手でインストールする必要があることに注意して下さい。

あとは tarball を展開したディレクトリに移動して普通に

> configure ; make ; su -c 'make install'

するのですが、 configureの際に

> Which language do you prefer?

に「3」と答えないと多符号化方式対応になりません。 ただしその場合もそれ以外の拡張は有効です。

このページを読んでいる人が多符号化拡張付きで使う場合は、 実行ファイルを起動するときに環境変数「W3MLANG」の値が

- 端末エミュレータがktermならば「ja_JP.kterm」
- 端末エミュレータがxtermならば「ja_JP.UTF-8」
- 端末エミュレータがrxvtならば「ja_JP.eucJISX0208」または「ja_JP.sjis」

となるようにして下さい。 レンダリング結果や、 オプション設定画面、 メインメニューが、 言語として「1 - Japanese …」を答えた場合とほぼ同じになる筈です。