TSfree 発言

うぇいくさん  ＜  こん？？は でび です

On Thu, 25 Dec 2008 10:29:20 +0900 (JST)
うぇいく <weyk@...> wrote:

> 　長さではなく取出しているデータと比較してますから、おそらくは、
> まったくの見当違いかと思います。

ありがとうございます。

> 　どうも、検索していゆくなかでマーカーとして使用しているようです。
> そのため、読み込みの時に強制的に0x8000のbitをオフにして、表示の
> 際には２バイト文字なら強制的に0x8000のbitをオンにしています。

つまり、KI/KO処理に使っている、と。
なんだか難しいことやってるんですね。

素朴な疑問ですが、オリジナルの作者さんが、内部変数として
KANJI_INとかKANJI_OUTみたいなのを定義して、そのON/OFFで
処理しなかったのはどうしてなのでしょう？

アドレス空間内のbitのON/OFFで処理する、というようなのは
スクリプト言語的な思考回路だと、あんまり出てこなんじゃ
ないかと思うんですよね。

640KBの壁とかのような、そういうアセンブラ脳な昔の人の
「メモリ節約の知恵」的な常套手段の一部なんでしょうか？

> # 3バイト文字とか、4バイト文字とかがない限りはこのままでよいはず。
> # もし、2バイトとを超える文字があるなら、Bufの型(ungined ing)から
> # 修正が必要です。

ぐは。
ASCII文字列と非ASCII文字列との複雑な区分けをしている処理を
取っ払って、0000〜FFFFまでの空間までを一括で扱うような
シンプル構造にしてUnicodeモードでコンパイルすれば、
（少なくとも、UnicodeのBMP領域までには対応した）Unicode版に
仕立て上げられるかも…と考えていました。

> 　charは、singedかunsignedのいずれかを省略しているだけです。
> で、どちらを省略しているかというと、コンパイル時のオプションに
> 依存します。
> # デフォルトではsingedのはず。

char ＝ （コンパイラ依存だけど、基本的には）signed char
signed char ＝ -128〜+127
unsigned char ＝ 0〜255

こういうことですね？

awk脳だと、「型」と聞いた途端に腰が引けるんですが、
signed charとunsigned charを相互変換する便利な関数とか無いんですか？
JavaScriptのevalとかStringみたいな感じで。

> # singedなchar型の変数(配列)と、buffer[i]>=0x80とゆー判定をしてしまう
> # 失敗が結構ありがちです(利口なコンパイラは警告をだしてくれます)

# ちと調べたら、「(静的)キャスト」がどうのとか説明されていて、
# 変数にぶち込んでからsigned/unsigned charで強制的に型宣言し直す
# みたいですね。
# でも、桁がはみ出ちゃった分はどうなんの？　すげー危険っぽいんですが。

# あとは原始的にビットの並びを上位下位にオフセット分解して
# 特定の数値を加算するなどの変換操作をしているみたい…。む〜ん…。

> 日本語を扱う場合、unsingedのほうが便利なんですが、標準ライブラリの文字列系の
> 関数と型が一致すなくなるため、適時使い分けたりします。

ここで言う「日本語」とはS-JISや日本語EUCなどのデータ内で、ASCII文字列と
非ASCII文字列とを扱う場合、という意味に受け取って良いでしょうか？

しかし、Bufの型の修正とかって話になると、かなり知識がないと無理そうですね。

# たとえて言えば、Jperlのコードから日本語対応処理部分を取っ払って、
# ascii文字列だけを前提としているperlのコードに戻し、
# それをそのまんまUnicodeベースでビルドをすれば、たぶん、Unicode
# 文字列を処理できるモノができそうだよね、という発想だったんですが。

でび  http://davi.txt-nifty.com/1984/