写真は、サーバー状態のomnibook。劣悪な環境でがんばってます。
ところで、Fedoraの文字化けについて、EUCからUTF-8に移行したためという情報を読んだ。そうか、macで変換してアップロードしても文字化けが直らなかったのは、そのせいか。そして、cgiで文字化けをしたのはブラウザの宣言と本文の文字コードが矛盾したせい。TL8wで文字化けしなかったのは、コード体系がEUCだったからか。今頃になって、パズルのピースがはまった。
同じLinuxなのに、文字コード体系が異なるなんて、全く予想できなかった。しかし、こういうことは「ビギナーズ バイブル」にはしっかりと書いておいて欲しいよな・・・まあ、ちゃんと読んでないのではあるが(^ ^;
追記：
ところで、Duronサーバーへ環境を移植するとき、スムーズに移せなくて戸惑うことがあった。/var/www/cgi-bin/とか/var/lib/mysql/のディレクトリは、そのままではコピーできない状態になっていた。TL8wからはあっさりとコピーできたので、理由が分からずに焦った。ここらへんで、すぐに所有者とパーミッションが思い浮かばないのが文化の違いだ。
それと、これは実に間抜けな失敗を一つ報告。パーミッションを設定するのに、ftpでコピーしたファイルはそのままgftpを使うことが多い。gnomeのツール（macでいうfinder）はイマイチ使いにくいからだ。ところが、そこで実につまらないミスを犯してタイムロスをしていたような気がする。それは、パーミッション設定ダイアログのレイアウトがソフトによって違うことに起因する。例えば644だと、下のように食い違ってしまう（本来は左）。
read write exe owner group other
owner Ｘ Ｘ read Ｘ Ｘ
group Ｘ write Ｘ
other Ｘ exe Ｘ
この例では、一般ユーザーは該当ファイルを読み出すことができないからエラー必至だ。俺はfetchのクセで左のようなイメージで、反射的に設定していた。ffftpかコマンドラインのように数字で設定すればいいのだが、gnomeのツールには無い。cgiが動かずに苦労したのはこれが原因のような気がしてきた。情けなや・・・そういえば、ffftpを使ってwinから設定したcgiが問題なく動きやすい気がするのは、パーミッションの設定に数字が使えるからかもしれない。