しらいです。
昔の FreeBSD には /usr/bin/unzip なんて無かったので、歴史
的には ports の方が元祖の筈。
In Message-Id <20171119223316.5435c1f05c48b62b94090...@dec.sakura.ne.jp>
Tomoaki AOKI <junch...@dec.sakura.ne.jp>さんwrites:
> 青木@名古屋です。
> > 内部コードの EUC-JP との間で変換が大量に発生して遅くなって
> > いるんだと思います。付け焼刃ですが UNICODEBUFFER=1 に設定す
> > ると多少はましになるかと。
>
> ありがとうございます。 .fd2rcに追加してみたら、多少どころか
> 劇的な改善でした。 運・不運の問題もあるかもしれませんが、
> 今のところ特に副作用も見られません。
現行システムではまず副作用はないと思います。大昔のメモリが
極端に少なかった時代の環境だと、swap が働いてしまうのでむし
ろ遅くなるかも知れません。
> 名前からすると、全て都度変換していたのを変換結果をキャッシュする
> 動作に変えるのでしょうか？ それとも、文字単位の変換からある程度
> バッファリングしてからの一括変換に変更？
> あぁ、ソースを読んでいないのがバレる...。
いえ、公式な設定項目なのでソース読まなくても man page にあ
ります。テーブルの中身を一気に読んでオンメモリで保持している
だけです。高々 45KB しかないので cache はむしろ遅いかと。
> UTF-8だと判定用の（でかい）ビットマップを持たせるか全角にする
> 範囲の（複数の）始点・終点のテーブルを作って判定するかに
> なりそうですが。 非ASCIIの半角文字を使う言語圏のユーザや
> 2バイト半角の場合に表示が間延びし得る点を泣いてもらう前提なら
> MSBが立っているかどうかでの判定も可能ですが...。
そもそも UTF-8 化のニーズ自体が、JIS 範囲外の文字をそのま
ま表示させたいというところから来ているので、そいつらを殺すの
だと UTF-8 化のメリットが殆んど無くなってしまいます。
内部コードが EUC-JP にしろ Shift_JIS にしろ、一旦 JIS 系の
コードに変換してしまうと Unicode 独自文字が全部ゲタ化しちゃ
うんですよ。
で、そういうマイナー文字の中にこそグリフ幅のイレギュラーな
連中が潜んでるので、途端に難易度が上がるという訳です。
あと、一文字が 1-4 byte(s) の揺れ幅を持つのもなかなかに扱
いづらいですね。順方向のポインタ移動ならまだしも逆方向の移動
がなかなかに面倒です。
「文字数」という概念が「バイト数」「表示幅」「文字の数」と
いう三種の実体に分かれて、しかも相関関係が計算では出せない辺
り、モティベーションに繋がる要素がまるで見出せません。
> そもそも、一時はご自身がメインで使っておられたOS/2への移植も、
> 当時「WPSがあるのに今更FDでもないじゃろ」と一蹴されてしまい
> ましたから、まだコンパチまで作って使っとるのか、と笑われるかも。
OS/2 も CP/M も所詮は CP932 単一環境なので、少なくとも文字
コードに関しては考慮すべき点は余りないと思いますよ。テキスト
ベースの OS で Unicode 対応したのは PC-DOS くらいかな？
> CUIが現役バリバリな環境では無くてはならないほど便利なのですが。
リモート環境だと CUI 便利だと思うんですけどね。地球の裏側
からリモートデスクトップなんて、遅くて話にならないんですが、
みんな平気なのかなー？
> ・2は、UTF-8に対応するからには8bit透過は不可欠なので、
> コード認識がうまくいっていない可能性が高そう。
これが気になるんですよねー。単なる誤認であれば nkf の入出
力コードを適切に指定すれば元に戻る筈なんで、それが無理となる
と、文字列の前半と後半とで違うコードに認識されたとか？
しらい たかし
_______________________________________________
freebsd-users-jp@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp
To unsubscribe, send any mail to "freebsd-users-jp-unsubscr...@freebsd.org"
