最近書かれた記事5件分を表示します。
更新状況をRSS 1.0形式でご覧になれます。
最近書かれた記事5件分を表示します。
更新状況をRSS 1.0形式でご覧になれます。
「サニタイズ言うなキャンペーン」とは何か（高木浩光＠自宅の日記）を読み、自分のプログラムを見直した。
高木浩光氏は次のように述べている。
元々、HTMLを出力するときは、その出力全体に対して「<」「>」「&」のエスケープ処理の検討が要求されているのであって、CGI入力に依存しているかどうかは無関係である。そこの考え方に「無毒化」だの「無害化」だの「消毒」だの「サニタイズ」だの「サニタイジング」だのという（最近流行の）発想は出てこない。
「サニタイズ言うなキャンペーン」とは何か - 高木浩光＠自宅の日記より引用
つまり、あって然るべきエスケープ処理（PHPならhtmlspecialchars()）を通していないからこそ、「サニタイズ」する必要が出てくるという意味か。自分のプログラムには、当たり前のように「サニタイジング」処理が入っている。htmlspecialchars()は存在を知っているくらいのもので、どこにも使っていない。
htmlspecialchars()に通すhtmlspecialchars()に通すこれらの、言わば当たり前の処理を通していなかった。ユーザがHTTP_USER_AGENTを偽装できるのはもちろん知っている。しかし、「攻撃手段」となり得るものとは認識していなかった。
PHP関数の一つ。「<」「>」「&」といった文字を一般実体参照（&など）に変換する。シングルクォート・ダブルクォートの変換はオプション指定による。
外部からのパラメータを受け取る部分は、次のように修正した。
$foo = htmlspecialchars(strip_tags($_GET['bar']), ENT_QUOTES);
htmlspecialchars()だけでよいのか分からないため、strip_tags()にも通すようにしている。最後のENT_QUOTESは、シングルクォート・ダブルクォートをともに変換する、htmlspecialchars()のオプションである。
PHP関数の一つ。文字列からHTMLやPHPのタグを取り除く。
HTTP_USER_AGENTやHTTP_ACCEPTを受け取る部分も同様に修正している。
$baz = htmlspecialchars(strip_tags($_SERVER['HTTP_USER_AGENT']), ENT_QUOTES);これで十分と言えるのか分からないが、どんな処理も通していなかった以前よりはよくなった。「初心者」だとか「個人サイトでの使用」だとか言わずに、するべきことはしっかりとしておきたい。
高木浩光氏より指摘をいただいた。続・「サニタイズ言うなキャンペーン」へ続く。
2006-01-16 18:58追記
XML+XSLT+PHPのシステムを導入したものの、うまく処理がなされず、時々白紙のコンテンツが返されていた。どうやら、記事を収めている/notes/2005/articles.xmlのファイルサイズが大きすぎるために起きているようだ。
/notes/2005/articles.xmlには2005年分の記事をすべて収めており、ファイルサイズは190KB程度になっている。先日、50Bほどの文字列を追加した途端に白紙のコンテンツが返されるようになったため、190KB付近が（このサーバにおける）ファイルサイズの制限値だと言えそうだ。
このため、190KBあったarticles.xmlを、2005年前半の記事を収めるarticles-first-half.xml、2005年後半の記事を収めるarticles-second-half.xmlに分割し、システムを書き直した。
「サニタイズ言うなキャンペーン」へ続く。
2005-12-29 22:47追記
XSLTスタイルシートのMIME typeは、text/xslではなくapplication/xmlであるようだ。
W3CのXSL Transformations Version 1.0には、XSLTスタイルシートのMIME typeを、text/xmlもしくはapplication/xmlとするように書かれている。
The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT stylesheets.
XSL Transformations (XSLT) Version 1.0 - W3Cより引用
text/xslの文字列はどこにも見当たらない。それもそのはず、IBMのXMLデータの管理: XMLドキュメントの識別では、text/xslをMicrosoftの想像力の中だけの存在です。
と言い切っている。
- text/xsl
MIMEタイプを勝手に作り上げた最も悪名高い例は、Microsoft® Internet ExplorerがXSLTスタイルシートの識別に使用しているtext/xsl擬似タイプです。このタイプは、Microsoftの想像力の中だけの存在です。
そして、間違いなく、これは誤りです。XSLにしても、そうでないにしても、いかなる種類のXMLドキュメントでも、textが適切なメディア・タイプであることは、まずありません。
XMLデータの管理: XMLドキュメントの識別 - IBMより引用
前半部分はともかく、重要なのは後半部分である。XSLTスタイルシートがXMLで記述されている以上、MIME typeのサブタイプ（スラッシュ以降）がxslであれxmlであれ、タイプ（スラッシュ以前）がtextの時点で誤りなのだそうだ。従って、application/xmlが妥当なMIME typeだと言える。
.htaccessには次のように記述するとよい。
AddType "application/xml; charset=UTF-8" .xml .xsl以前の記事（『XML Hacks』を読む）に記した通り、XML+XSLT+PHPによるWebサイトの再構築を実現することができた。
データの構造や意味を定義するためのマークアップ言語。要素型（タグ）の名前を好きなように設定できるため、より分かりやすくマークアップすることが可能になる。
XML文書を一般的な形式に変換するための言語。多くはXHTMLに変換する用途で用いられる。
実際に使っているXML文書とXSLTスタイルシートの例は次の通り。
これらのファイルをSablotron（XSLTプロセッサ）に通してXHTML文書を出力している。
XML+XSLT+PHPのシステムを構築する際に学んだことは、またの機会に記そうと考えている。問題解決の過程はローカルサーバに記しているため、それをまとめるだけでよい。
XML文書・XSLTスタイルシートの中身は、ソースを表示することで見られる。これは、ブラウザがXMLとして処理してしまうためだ。例えば、MSIEではツリー（木構造）が表示される。
2005-12-29 17:28追記
Windows付属のディスクデフラグツールを用い、OSをインストールしてある論理ボリューム（C:）を分析したところ、1.5GBものページファイルが断片化したものとして検出された。この断片化したページファイルは、通常のデフラグ処理では解消できないようだ。
論理ボリューム（C:）には10GBしか割り当てていないため、約15%の領域（空き領域が5GBあるため、実際には1.5/5の約30%）が断片化していることになる。「このボリュームを最適化してください。」とのメッセージが出るが、デブラグ処理を行ってもこの断片化が解消されることはなかった。
ページファイルの断片化を解消できない件について、＠ITのページ・ファイルによるディスクのフラグメントを防止する方法では次のように述べられている。
さらにたちが悪いのは、ページ・ファイルは、仮想メモリ・システムによって、Windowsの起動時にロックされるので、このままディスク・デフラグ・ツールを実行しても、ページ・ファイルのクラスタは移動できないということだ。
ページ・ファイルによるディスクのフラグメントを防止する方法 - ＠ITより引用
断片化を解消できないのは、ページファイルの領域をWindowsがロックするからだそうだ。考えてみれば当たり前のことである。
同じく＠ITのページ・ファイルを別ドライブに一時待避し、デフラグを効率よく行う方法では、断片化を解消する方法が示されている。
C:を最適化したいなら、それとは別の論理ボリューム（パーティション）あるいは物理ドライブ（HDDそのもの）が必要になる。C:とは別の論理ボリュームをD:とすると、手順は次の通りである（Windows XP; それ以外では項目の名称が異なっている場合がある; []はボタンを示す）。
この手順で断片化を解消できる（ページファイルが連続したものになる）はずだが、私の場合はうまくいかなかった。ページファイル領域がシステム領域によって二分されてしまう恰好になっているのである。
左側に分割されたページファイル領域は、緑色の面積から察するに少しだけであることが分かる。それならば、ページファイルの割り当てを減らしてやれば解決しそうだ。
ページファイルの初期サイズ（確保する容量）には、コンピュータに積んでいる物理メモリの容量を1.5倍した値がデフォルトでセットされている。1024MB（1GB）の物理メモリを積んでいるなら、ページファイルの初期サイズは1536MB（1.5GB）となる。
ページファイルの使用量を知るには、タスクマネージャのパフォーマンスタブにある「コミットチャージ」を見ればよい。タスクマネージャの下側に「プロセス」「CPU使用率」と共に並んでいる「コミットチャージ」と同一である。
私の環境では、1GBはおろか500MBにすらそう達しない。そのため、1.5GBも確保しているページファイルサイズを1GBにまで縮小することに決めた。500MBに設定することも可能だが、ページファイル領域を二分しないことこそが目的である。
ページファイルを1GBに変更した結果、二分されていたページファイルは一つの連続する領域に収まった。
マスタファイルテーブル（MFT）の断片化についても覚え書きしておく。ディスクデフラグツールで分析したところ、MFT断片の総数は2と表示された。断片が2つ、つまり連続していないことを意味している。気になって調べると、さらに同じく＠ITのWindows 2000標準のデフラグ・ツールを使うという文書で次の記述が見つかった。
- MFT断片の総数
MFTに関する断片の数。すべてのMFTが連続していれば値は「1」になるが、万一のクラッシュに備えて、MFTはあらかじめ2重化されているため、この項目の最小値は「2」になる。
検証 ディスク・デフラグメント完全マスター 3．Windows 2000標準のデフラグ・ツールを使う（1） - ＠ITより引用
断片が2つ存在するのは、二重化によるものだそうだ。それなら気にしなくともよい。
諸事情から所属している研究室のWebサイトを制作（厳密には更新、あるいはリニューアル）することになった。何時もの調子で制作するわけにはいかないため、注意するべき点を挙げることにしたい。
まず当然に注意するべき点として、以前の失敗を引き継がないことが挙げられる。これはリニューアルする際に限られるが、不要なものはばっさり切り捨てるとよい。
Flashは特に注意する必要があると考えている。Flashを見られない環境を考慮し、内容の代替手段は必ず用意しなければならない。「Skipする」は見やすい文字色で分かりやすい位置に配置し、Flash内にリンクを作成するならば必ずFlash外からもアクセスできるようにする。これは必ず守りたい事柄である。
また、通常はOperaやGecko（Firefox）を想定して制作するところ、今度は利用者が多いであろうMSIEを中心に考えなければいけない。CSSはもちろんのこと、XHTMLの記述にも気を遣う必要がある。コメント（注釈）もしっかり付けておきたい。
普段はUTF-8（Unicode）を用いているが、どんなエディタでも扱えるようにWindows標準とされているShift_JISを採用した。私一人が担当すると分かっているならともかく、分からないうちはこうしておくと無難である。改行コードもWindows標準とされているCR+LFに変更した。
文字コード系をShift_JISにしたため、XML宣言は省略することができない（UTF-8およびUTF-16の場合は省略可能）。だが、MSIEを中心に考えると省略せざるを得なくなる。
MSIE6の!DOCTYPEスイッチに記した通り、XML宣言を置くと後方互換モードに入ってしまって正しいレンダリングが行われない。1行目をDOCTYPE宣言にすれば標準準拠モードに入るため、面倒な作業を回避するならXML宣言をする方が得策だ。
標準準拠モードを基準にしていれば、OperaやGeckoで表示が崩れることはそうないだろう。
XML宣言の問題はPHPを使えばすぐに解決できる。だが、PHPは敢えて使わなかった。これも他の人が編集作業をする際の弊害となるからである。
PHPの便利さを再認識したと同時に、自分がどれだけPHPに頼っているかがよく分かった制作であった。
よく聞く言葉だが、制作してそれで終わりではない。更新の指示があったら迅速に実行すること、管理を怠らないことが肝要か。
11月22日にOpera 8.51がリリースされている。今回はセキュリティフィックスが中心であるようだ。
大きな変更がないため、修正のあったファイルのみを8.50に上書きすることにした。別のディレクトリに8.51をインストールした後、ファイルの更新日時を見比べるとよい。
私が上書きしたファイルは次の通りである。
インストールした時刻を更新日時とするファイルが存在するため、それらのファイルを上書きしてしまわないように注意したい。