綾小路龍之介の素人思考

サーバ上でファイルを書き換えるe.cgi(ProjectRotation8)

Webページをローカルで編集するとダウンロード、編集、アップロード、という手順をとらなくてはならない。リモートのディレクトリをマウント出来れば最高。手元にあるマシンが自分のマシンで無い場合はパスワードを入力。みんなで Webページ編集を前提にすればどうかな。

目次

[メモ] 今までのものは

使ったことがあるWikiクローンはみんな乗り換えに困った。そんなことがあってから、どうも乗り換えのことを考えてしまいWikiクローン導入には二の足を踏んでるんだ。

Wikiのいいところはみんなで書き込みができる点だ。Wikiを公開する前に管理者がやらなければいけないことは、内容を濃くすることなんじゃないだろうか。つまり、良いものの周りには良いものが集まる、ということだ。つまり、朱に交われば赤くなる、ということだ。いたずら的な書き込みに対する、特権発動をどこまで制御するかはどのように考えればいいのだろう。これはe.cgiにも同じだといえる。不特定多数の訪問者から記事を募集するということは、この線引きが重要となってくるだろう。

Wiki文法を一般的なhtml文法に変えることで生じる最大の恐ろしさは、e.cgiで作られたページで別のページに飛ばすこともできるということだ。例えば、meteタグを使ってそのようなことができる。多くのブラウザではmetaタグによる飛ばしに確認メッセージを出さないから、e.cgiで編集されたページを経由して別のページに行っても、これに気づかないユーザもいるかもしれない。どうすればhtml文法を使うことを許可できるだろうか。それもなるべくスクリプトを複雑にしないで。

もしかするともっと別のことを考えたほうがいいかもしれない。つまり文書を作るのになにもhtmlでなくてもかまわないということだ。僕はよくLaTeXを使うから、LaTeX文法を解釈してしかるべきhtmlタグに変換して表示できればそれもよいのかも知れない。とくに文書の共有という点ではいいかもしれない。今まで書き溜めた文書を公開できるのならば。でもどうなのだろう。LaTeXに未来はあるのだろうか。LaTeXの文書の構造化という概念はhtmlでも実現可能なわけだし、構造化タグ付けもhtmlのほうが簡単なように見える。確かに組版を前提に作られているだけあって、印刷した場合はきれいだと思うけど、電子財産の共有という点では難しいのかもしれない。これ以降の紙メディアの動向にかかっているかもしれないな。でもCSSの差し替えとかをつかえば、印刷に適したフォーマットを提供するもの簡単だと思うんだけどな。

とにかく書き込み文法の問題が解決しない限りは、e.cgiは使用制限を掛けておかねばならないだろう。

[メモ] 懸案1: ブラウザと文字コード

Firefoxは書き込みのときにUnicodeで書き込む。Intenet ExplorerはShift-JISのようだな。XHTMLを出力するようにした。すると上で挙げたどちらのブラウザを使ってもUnicodeで書き込まれるようになった。XHTMLファイルの出力の1行目で文字コードをUTF-8にしたからかな。やったぁ。結局変わらなかった。やはりInternet ExplorerはXHTMLを理解してくれないようだ。じゃぁヘッダの中に文字コードはUTF-8という指定を書けばいいのかもしれない。本当はShould notなんだけど。この際仕方あるまい。

変な表示になったらブラウザの文字コード判定を使えばいいかな。文字コードを変えたくなったら、正しい表示が出来るまでブラウザの文字コードを変える、テキストエリアの中身を全選択してコピー、ブラウザの文字コードを替えたい文字コードに変更。テキストエリアに貼り付け、eボタンを押してテキストエリアの内容を保存。

ブラウザの文字コード判定を信用することにしよう。とかくcgiで文字コード判定をするのは面倒だ。勉強にはなるけど。

とにかくcgiのほうでインプットの文字コード判定をしなくてよくなった。これでプログラムが簡単になるな。少なくとも僕のユースではUnicodeのほうが嬉しい。

[メモ] 懸案2: textareaの中にtextareaを入れる

まずはDTDを読んでtextareaの中に入れてもいいデータを確認しないと。一番知りたいのは空白の取り扱い。HTMLエスケープせよということ。とにかく大事みたい。クロスサイトスクリプティング?

結論を先に言おう。ソースを見たとき<textarea>から</textarea>の間に<や>や&を含めてはいけない。文字参照(&lt;、&gt;、&amp;)はブラウザによって対応する文字(<、>、&)に変換される。<textarea>の後に終了タグの開始を意味する<が出てきた時点でtextareaは終了しているとみなされる。XHTML 1.1ではtextareaの中身は#PCDATAでなければならない(Parsed Character Data)。

cgiで出力された文書の構造を考えれば、textareaの中身に文書自体の見出しを示すh1タグとか段落を示すpタグが含まれるのはおかしい。編集先の文書の構造とcgiで出力された文書の構造の間に関係は無いからだ。ゆえにtextareaの中に構造化タグを含めるのはおかしい。ソースを見たときに構造化タグを示す<や>がtextareaの中に含まれてはならない。では&はどうだろうか。

#PCDATAは構文解析対象文字データなので、textareaに含まれる内容はtexareaが含まれている文書構造ツリーの枝になれるということだ(頭に#がついているので子要素を自身の内に含むことができる)。でも、編集中の文書をe.cgiの文書構造から見れば、ただのデータであり、2つの文書の間に内容構造のオーバーラップがあってはならないはずだ。

書いたはいいが、いまだにDTDの読み方は良くわからない。特にXHTMLになってモジュール化されてよりわからなくなった。つまりどこを見れば目的の情報にたどり着けるのか良くわからなくなった。上に書いた情報も、Googleで探し当てた情報だし。

[メモ] 懸案3: font-family:sans-serif;は読みやすい?

WindowsMeとWindows2000のInternet Explorerではなんとなく表示が違うような気がする。特にpreタグの中に書いた[]の形が。preタグの中に読みにくい[]があったらそのページの管理者はWebページの編集をWindows 2000で行っているのかもしれない。preタグの中身だけをmonospaceとかにすればいいのかな。どちらも年賀状ソフトなどを入れていないフォントに関してはクリーンなシステムを使っているはず。やめたほうがいいかなサンセリフ体。読みやすいって話を聞いたんだけど。読みやすいのは英語だったかな?

文字コードも読みやすさの指標なのかもしれない。このページはUTF-8にしているけど、UnicodeのフォントはWindows Meでは貧弱なのかもしれない。試しにマイクロソフトが開発したShift-JISコードで書き込んでみると、見やすい。さすがはマイクロソフトである。寡占化のセオリーに忠実だ。どこでも読めることを考えれば、Unicodeで書いといたほうがいいと思う。編集環境にShift-JISを理解できるコードセットが導入されているかわからないし。

おなじOSでもブラウザが変われば見た目も変わる。Firefoxではsans-serifを入れても入れなくても同じ様に見えた。Internet Explorerではぜんぜん違って見えた。特に半角英字がぜんぜん違った。やはり日本語で読みやすいとされているfont-familyはsans-serifではないのかもしれない。英語と日本語が混じっている文書の場合はcursiveのほうが見やすいような気もしてきた。

Windows 2000にインストールしたFirefoxとIEでみると、サンセリフは結構読みやすいと思った。結局今は下のようにサンセリフを指定している。Windows Meの場合も調べなければ。Windows Meのことを考えると、無理にフォント指定するのは労多くして益少なしなのかもしれない。下のように指定して、Windows MeのIEで見ると見にくいフォントでmonospaceの文字が表示されるように思う。不思議なことにWindows Meで見た場合はフォントファイリーの指定はないほうがmonospaceの文字が読みやすい。というわけで今のところフォントファミリーの指定はしていない。うちではまだWindows Meは現役真っ盛りなので。

*{font-family:sans-serif;}
pre{font-family:monospace;}

ちなみにserifを指定するとこうなる。

ちなみにsans-serifを指定するとこうなる。

ちなみにcursive を指定するとこうなる。

ちなみにfantasyを指定するとこうなる。

ちなみにmonospaceを指定するとこうなる。

日本語の読みやすさはどれも変わらないような気がする。結局のところ、フォントの指定はユーザ任せでいいんじゃないだろうか。多分どんなブラウザでもフォントの指定はできるのだし。Googleで見やすいPC画面上で見やすいと言われているフォントを探したところ、Verdanaというフォントがそうらしい。今のところこのサイトはfont-family:Verdanaである。

[html] 懸案4: 結局WEBセーフカラーは使えるのか

セーフカラーだけでやるのは少し大変そうだな。

[メモ] 懸案5: 印刷に適したCSSの提供

問題はブラウザが対応しているかだな。たしかページ数とか、紙の大きさもCSSで指定できるんじゃなかったっけ?でも実際使ってみると余白とか紙の大きさとかはブラウザの対応状況が遅れているためにほとんど使い物にならないのだとか。ということは余分なものは最初からつけないようにしてページを作ればいいのか?

印刷時に広告表示をきってしまうのは犯罪か?まぁユーザが自発的にページの頭と尻尾につけられる広告を除いて選択して、選択した部分だけ印刷すればそれでいいんだけどね。

<link rel="stylesheet" type="text/css" href="a.css" media="all">
<link rel="stylesheet" type="text/css" href="p.css" media="print">

[メモ] 懸案6: ファイルは一つにまとめるべし

設置を簡単にするためにもスクリプトのサイズは小さく、数は1つで、ライブラリの読み込みはしない、モジュールは使わない、という前提でどうだろう。

[メモ] 懸案7: 自分で自分に書き込めるか

これが出来なければコンパイラが書けないプログラミング言語みたいでだめだな。

ソーシャルブックマーク

  1. はてなブックマーク
  2. Google Bookmarks
  3. del.icio.us

ChangeLog

  1. Posted: 2003-12-22T18:35:12+09:00
  2. Modified: 2003-12-22T18:51:17+09:00
  3. Generated: 2016-12-27T23:09:28+09:00