PC（記述・ブログ・OS）
- 2008年03月19日: Wise Disk Cleaner (0)
- 2007年12月30日: PCトラブル・防御・安定 (0)
- 2007年12月25日: Mozilla Firefox の起動を早める (0)
- 2007年05月10日: ライブドアブログ （表の作成） (0)
- 2006年08月30日: 続W3C準拠（サイト書直し） (0)
- 2006年06月25日: マークアップ言語（XHTMLまで） (0)
- 2006年06月21日: IEの問題点 (0)
- 2006年06月18日: XHTML1.1、IEと認証の問題 (0)
- 2006年06月04日: Ｗ３Ｃ準拠 (2)
- 2005年12月12日: 同一化が終了 (0)
Wise Disk Cleaner
2008年03月19日
肥大化したレジストリ内の不要項目を削除するのに、Freeの「Wise Registry Cleaner」を使っている。
ここでは、詳しい説明を省くが、レジストリの肥大化は、「起動が遅い」「動作の不安定」に繋がるといわれている。
最初にこれを使用した後、もたついていた終了が速やかになった。
現在は、バージョンアップされた「Wise Registry Cleaner 3」がサイトから入手できる。
私は、レジストリの詳しいことが判らないので、デフォルトの「削除しても安全」という項目しか削除しないことにしている。
所で、同じサイトに「Wise Disk Cleaner 3」というアプリケーションがある。
これは、バックアップファイル、テンポラリーファイル等の不要なファイルをリストし、削除できるソフトである。
個人的に、不要なファイルが存在しているということは、気分的に宜しくない（さして影響がなくてもである）。
最初に使用したときには、200個以上のファイルがリストアップされた。やはり不都合が怖いので、デフォルトの推奨（安全）項目しか削除しないことにしている。
「Wise Registry Cleaner」は、日経PC21という雑誌に紹介されていたのだが、これらのソフトがどれだけ優れているのか、素人レベルの私には判定できないことをお断りしておく。
ここでは、詳しい説明を省くが、レジストリの肥大化は、「起動が遅い」「動作の不安定」に繋がるといわれている。
最初にこれを使用した後、もたついていた終了が速やかになった。
現在は、バージョンアップされた「Wise Registry Cleaner 3」がサイトから入手できる。
私は、レジストリの詳しいことが判らないので、デフォルトの「削除しても安全」という項目しか削除しないことにしている。
所で、同じサイトに「Wise Disk Cleaner 3」というアプリケーションがある。
これは、バックアップファイル、テンポラリーファイル等の不要なファイルをリストし、削除できるソフトである。
個人的に、不要なファイルが存在しているということは、気分的に宜しくない（さして影響がなくてもである）。
最初に使用したときには、200個以上のファイルがリストアップされた。やはり不都合が怖いので、デフォルトの推奨（安全）項目しか削除しないことにしている。
「Wise Registry Cleaner」は、日経PC21という雑誌に紹介されていたのだが、これらのソフトがどれだけ優れているのか、素人レベルの私には判定できないことをお断りしておく。
PCトラブル・防御・安定
2007年12月30日
ハードディスクが壊れた。主要なファイルのバックアップは取ってあるので問題ないが、システムを元に戻す労力を考えると、ウンザリどころの話ではない。できることは、疑問を抱かず何も考えず、ひたすら粛々と復旧への歩を進めること。
（注：HDは、まともなメーカーの新品を購入したのだが・・）
この際、バックアップ、セキュリティ、そしてシステムの安定化について、少しだけ関連ソフトを試した。
以前から、ハードディスクのバックアップの必要性を感じていたが、壊れて痛い目に会わなければ、金も掛かるということもあり、腰を上げない。遂にバックアップソフトを購入することにした。
WINがインストールされたドライブを丸ごとバックアップし、WINの故障時にそっくり元の状態に戻すというバックアップと、メインで使用しているハードディスクのクローンを作成するソフト（ハードディスクの交換に便利）が一緒になった、「LBバックアップコマンダー9」というものを購入した。
セキュリティソフトはインストールしてあるのだが、この際、「アスキー・ドットPC」という雑誌のお勧めだった「AVG」のフリー版をインストールしてみた。製品版と同様のヴァイルス検出能力ということだが、ファイアウォールとスパイウェアのサポートはしていない。
記事では、ファイアウォールは「ゾーンアラーム」、スパイウェア対策は「ウィンドウズ・ディフェンダー」で対策せよとのこと。ただでさえ遅くなるセキュリティソフトを3つをインストールすれば重くて使えない。実際、試しに3つをインストールしてみた（！！）。スタートもシャットダウンも時間が掛かる。その上、自動アップグレードが重なり、ネットが遅くて使えない。感想としては、ヴァイルス対策機能としての「AVG」に問題は無くても現実的に使えない。婉曲な宣伝、プロモーションではないか。ヴァイルス対策だけでPCのセキュリティが保てる時代ではない。無責任な記事だと感じた。
この過程で、「Kingsoft」の「InternetSecurity」という、ヴァイルス、ファイアウォール、スパイウェアがセットになってフリー（しかも製品版と同様）という、少々考えにくいものを「窓の杜」で見つけた（見つけたというほどのことではないが・・）（注：このソフトは、「日経PC21」という雑誌の編集長インタビューでも取り上げられていた）。性能はよく分からないが、これをインストール。多少心配もあったが、共存できないために製品版のセキュリティソフトは削除した。
WINを長く使っていると、原因不明の不具合が発生する場合がある。その原因の多くがレジストリの肥大化だという。レジストリを整理し、削除しても問題のないファイルを表示してくれるフリーソフト（ワイズ・レジストリクリーナ/WiseCleaner/日本語版あり）（この種のソフトは他にも様々ある）を新たにインストール。
レジストリを整理した後は、再構築して不要な部分を削除して軽量化したほうがいい。そのためのフリーソフトもインストールした（今回、同時に紹介されていた、「NTREGOPT」を使用）。
（レジストリの整理、再構築のためのソフトは様々あり、どれがいいのかは、私には判断が付かない）
シャットダウンに時間がかかるようになっていたディスクトップは元に戻り（注1）、ノートブックは、製品版セキュリティソフトが入っていたにもかかわらず、230もの危険性の低いヴァイルスが見つかり、どうしても原因が分からなかった、起動時に「**.dill」ファイルがありませんというメッセージも消えた（注2）。
我家の2台のPCは現在、「安定」さを取り戻している。
（詳しい方にとっては間抜けな話題だと思うが・・）
注1：レジストリの整理で直る。
注2：ヴァイルスの削除で直る。
（注：HDは、まともなメーカーの新品を購入したのだが・・）
この際、バックアップ、セキュリティ、そしてシステムの安定化について、少しだけ関連ソフトを試した。
以前から、ハードディスクのバックアップの必要性を感じていたが、壊れて痛い目に会わなければ、金も掛かるということもあり、腰を上げない。遂にバックアップソフトを購入することにした。
WINがインストールされたドライブを丸ごとバックアップし、WINの故障時にそっくり元の状態に戻すというバックアップと、メインで使用しているハードディスクのクローンを作成するソフト（ハードディスクの交換に便利）が一緒になった、「LBバックアップコマンダー9」というものを購入した。
セキュリティソフトはインストールしてあるのだが、この際、「アスキー・ドットPC」という雑誌のお勧めだった「AVG」のフリー版をインストールしてみた。製品版と同様のヴァイルス検出能力ということだが、ファイアウォールとスパイウェアのサポートはしていない。
記事では、ファイアウォールは「ゾーンアラーム」、スパイウェア対策は「ウィンドウズ・ディフェンダー」で対策せよとのこと。ただでさえ遅くなるセキュリティソフトを3つをインストールすれば重くて使えない。実際、試しに3つをインストールしてみた（！！）。スタートもシャットダウンも時間が掛かる。その上、自動アップグレードが重なり、ネットが遅くて使えない。感想としては、ヴァイルス対策機能としての「AVG」に問題は無くても現実的に使えない。婉曲な宣伝、プロモーションではないか。ヴァイルス対策だけでPCのセキュリティが保てる時代ではない。無責任な記事だと感じた。
この過程で、「Kingsoft」の「InternetSecurity」という、ヴァイルス、ファイアウォール、スパイウェアがセットになってフリー（しかも製品版と同様）という、少々考えにくいものを「窓の杜」で見つけた（見つけたというほどのことではないが・・）（注：このソフトは、「日経PC21」という雑誌の編集長インタビューでも取り上げられていた）。性能はよく分からないが、これをインストール。多少心配もあったが、共存できないために製品版のセキュリティソフトは削除した。
WINを長く使っていると、原因不明の不具合が発生する場合がある。その原因の多くがレジストリの肥大化だという。レジストリを整理し、削除しても問題のないファイルを表示してくれるフリーソフト（ワイズ・レジストリクリーナ/WiseCleaner/日本語版あり）（この種のソフトは他にも様々ある）を新たにインストール。
レジストリを整理した後は、再構築して不要な部分を削除して軽量化したほうがいい。そのためのフリーソフトもインストールした（今回、同時に紹介されていた、「NTREGOPT」を使用）。
（レジストリの整理、再構築のためのソフトは様々あり、どれがいいのかは、私には判断が付かない）
シャットダウンに時間がかかるようになっていたディスクトップは元に戻り（注1）、ノートブックは、製品版セキュリティソフトが入っていたにもかかわらず、230もの危険性の低いヴァイルスが見つかり、どうしても原因が分からなかった、起動時に「**.dill」ファイルがありませんというメッセージも消えた（注2）。
我家の2台のPCは現在、「安定」さを取り戻している。
（詳しい方にとっては間抜けな話題だと思うが・・）
注1：レジストリの整理で直る。
注2：ヴァイルスの削除で直る。
Mozilla Firefox の起動を早める
2007年12月25日
ブラウザーはFirefoxを使っている。このブラウザの起動時間を短縮するTipを知って試したのだが、それまでに比べ圧倒的に早くなった。
詳しい方には当たり前で、かつ初歩的でまだ不完全なのかもしれないが、PCを長く使っている割には基礎的なことが分かっていない私には充分な効果があった。
� �prefetch」機能を使う。
Windows XPに備わっている、「prefetch」オプションを追加して起動することによって起動を早める。アプリケーションのディスクアクセス情報を先読みするという機能で、2回目以降は起動が速くなる。当然、他のアプリケーションにも有効。
通常、ディスクトップのショートカットアイコンをクリックしてアプリケーションを起動させると思うが、このアイコンをを右クリックして”プロパティ”を開く。
この中の「リンク先（T）」欄には、デフォルトインストールの場合、"C:\Program Files\Mozilla Firefox\firefox.exe"と書かれているはずである。この部分の最後に「半角スペース/Prefetch:1」を追記する。
"C:\Program Files\Mozilla Firefox\firefox.exe" /Prefetch:1
�� Firefoxのconfigurationのカスタマイズ。
1.Firefoxアドレスバーに「about:config」と入力し「Enter」を押す。
2.表示された画面上部の”フィルタ”欄に「browser.cache.memory.enable」と入力する。
3.画面をダブルクリックし、「値」の部分を「true」にする（デフォルトはtrue(?)）。
4.画面を右クリックし、新規作成→整数値をクリックする。
5.「新しい整数値の設定名」入力ボックスが表示されるので、空欄に「browser.cache.memory.capacity」と入力。
6.「整数値を入力してください」という窓が開くので、そこに下記を参考にして自分のPCの搭載メモリに応じた数値を入力する。
メモリが256MBの場合：4096
メモリが512MBの場合：8192
メモリが1GMBの場合：16384
7.OKボタンをクリックして終了。
��フリーソフト「Firefox Preloader」の利用
「Firefox Preloader」は、インストールするだけで、Firefoxの起動時間を大幅に短縮するフリーソフトである。これは、Firefoxで利用するいくつかのパーツを予め読み込み（プリロード）、起動時間を短縮する。
Windows (95/98/NT/2000/XP) に対応。英語だがダウンロード、インストールも非常に簡単（指示に従ってクリックしていけばインストールは終了する）。ファイルは自動セットアップと、Zipファイルの2種類があるが、好みで選べばいい。
インストールが完了し、「Firefox Preloader」を起動すると、WindowsのステータスバーにおなじみのFirefoxアイコンが表示され、これで起動速度向上の準備は完了。
「Firefox Preloader」のダウンロードサイトはここから。
他にも様々な方法があるようだが、ここで紹介したものは、「Mozilla Re-Mix」から参照させて頂いた（感謝します）。
詳しい方には当たり前で、かつ初歩的でまだ不完全なのかもしれないが、PCを長く使っている割には基礎的なことが分かっていない私には充分な効果があった。
� �prefetch」機能を使う。
Windows XPに備わっている、「prefetch」オプションを追加して起動することによって起動を早める。アプリケーションのディスクアクセス情報を先読みするという機能で、2回目以降は起動が速くなる。当然、他のアプリケーションにも有効。
通常、ディスクトップのショートカットアイコンをクリックしてアプリケーションを起動させると思うが、このアイコンをを右クリックして”プロパティ”を開く。
この中の「リンク先（T）」欄には、デフォルトインストールの場合、"C:\Program Files\Mozilla Firefox\firefox.exe"と書かれているはずである。この部分の最後に「半角スペース/Prefetch:1」を追記する。
"C:\Program Files\Mozilla Firefox\firefox.exe" /Prefetch:1
�� Firefoxのconfigurationのカスタマイズ。
1.Firefoxアドレスバーに「about:config」と入力し「Enter」を押す。
2.表示された画面上部の”フィルタ”欄に「browser.cache.memory.enable」と入力する。
3.画面をダブルクリックし、「値」の部分を「true」にする（デフォルトはtrue(?)）。
4.画面を右クリックし、新規作成→整数値をクリックする。
5.「新しい整数値の設定名」入力ボックスが表示されるので、空欄に「browser.cache.memory.capacity」と入力。
6.「整数値を入力してください」という窓が開くので、そこに下記を参考にして自分のPCの搭載メモリに応じた数値を入力する。
メモリが256MBの場合：4096
メモリが512MBの場合：8192
メモリが1GMBの場合：16384
7.OKボタンをクリックして終了。
��フリーソフト「Firefox Preloader」の利用
「Firefox Preloader」は、インストールするだけで、Firefoxの起動時間を大幅に短縮するフリーソフトである。これは、Firefoxで利用するいくつかのパーツを予め読み込み（プリロード）、起動時間を短縮する。
Windows (95/98/NT/2000/XP) に対応。英語だがダウンロード、インストールも非常に簡単（指示に従ってクリックしていけばインストールは終了する）。ファイルは自動セットアップと、Zipファイルの2種類があるが、好みで選べばいい。
インストールが完了し、「Firefox Preloader」を起動すると、WindowsのステータスバーにおなじみのFirefoxアイコンが表示され、これで起動速度向上の準備は完了。
「Firefox Preloader」のダウンロードサイトはここから。
他にも様々な方法があるようだが、ここで紹介したものは、「Mozilla Re-Mix」から参照させて頂いた（感謝します）。
ライブドアブログ （表の作成）
2007年05月10日
前々回のブログ記事では表を使いたかった。
そもそも、ブログにおいて表を簡単に作成できると考えることが素人なのかもしれない。ブログでは、表はフォームが用意されていて簡単に作成できると思っていた。所が、表についてのフォームはおろか、表についての説明もない。結局、HTMLで記述しなければ表を表現することはできないことが判った（そんなことは常識？）。
ブログは簡単であると思って始めた方が、表現上、表を必要とした場合、かなり困るのではないかと思った。そこで、参考になるかどうかはわからないが、ライブドアブログにおいて私が遭遇した問題点と注意点を述べる。
先ず、「デザインの設定」の「スタイルシート（CSS）」のページに表のスタイル（表のサイズ、文字の大きさ等）を記述する（注1）。
次に、投稿記事の中にHTMLを用いて表の記述をする（どちらが先でも構わないが・・）。この時の注意点は、記事の投稿画面の下にある「さらに詳しく設定する」をクリックし、「投稿フォームの設定」の中の、「改行をそのまま反映」にチェックを入れた場合・・、
通常は、見やすいように適当な位置で（<tr>の後など）、段を下げる。当然改行命令<br>は入れない。所がこの場合、改行した部分に自動的に改行命令<br>が、挿入される。その結果、実際のページでは、表の上下に広大なスペースができてしまう。だから、全て詰めて記述しなければならない。
「改行しても反映しない」にチェックを入れた場合は、改行命令<br>が、挿入されないので、文章（記事）の改行したい部分の最後に<br>を加える必要がある。
次の問題点は、判っている範囲では、「border」（外枠）と「cellpadding」（セル内の余白）命令は、何故か「スタイルシート（CSS）」の中に記述しても機能しない（私がどこかで間違っている可能性も有り）。そこで、投稿記事の中の表作成のためのHTMLの中に記述した（アンダーライン部分）（注2）。
注1：「デザインの設定」の「スタイルシート（CSS）」のページに挿入した表の記述。
table{
width:440px;
border-collapse:collapse;（注3）
font-size:12px;
margin-top:5px;
margin-bottom:5px;
}
注2：アンダーライン部が「スタイルシート（CSS）」で制御できない。
<table border="1px" cellpadding="2px">
<tr><td>開発コード</td><td>Katmai</td>・・（以下略）
注3：ボーダーの表示命令
border-collapse :セルのボーダーの表示の仕方を指定する。
collapse :隣接するセルのボーダーを重ねて表示する。
separate :隣接するセルのボーダーの間隔をあけて表示する。
そもそも、ブログにおいて表を簡単に作成できると考えることが素人なのかもしれない。ブログでは、表はフォームが用意されていて簡単に作成できると思っていた。所が、表についてのフォームはおろか、表についての説明もない。結局、HTMLで記述しなければ表を表現することはできないことが判った（そんなことは常識？）。
ブログは簡単であると思って始めた方が、表現上、表を必要とした場合、かなり困るのではないかと思った。そこで、参考になるかどうかはわからないが、ライブドアブログにおいて私が遭遇した問題点と注意点を述べる。
先ず、「デザインの設定」の「スタイルシート（CSS）」のページに表のスタイル（表のサイズ、文字の大きさ等）を記述する（注1）。
次に、投稿記事の中にHTMLを用いて表の記述をする（どちらが先でも構わないが・・）。この時の注意点は、記事の投稿画面の下にある「さらに詳しく設定する」をクリックし、「投稿フォームの設定」の中の、「改行をそのまま反映」にチェックを入れた場合・・、
通常は、見やすいように適当な位置で（<tr>の後など）、段を下げる。当然改行命令<br>は入れない。所がこの場合、改行した部分に自動的に改行命令<br>が、挿入される。その結果、実際のページでは、表の上下に広大なスペースができてしまう。だから、全て詰めて記述しなければならない。
「改行しても反映しない」にチェックを入れた場合は、改行命令<br>が、挿入されないので、文章（記事）の改行したい部分の最後に<br>を加える必要がある。
次の問題点は、判っている範囲では、「border」（外枠）と「cellpadding」（セル内の余白）命令は、何故か「スタイルシート（CSS）」の中に記述しても機能しない（私がどこかで間違っている可能性も有り）。そこで、投稿記事の中の表作成のためのHTMLの中に記述した（アンダーライン部分）（注2）。
注1：「デザインの設定」の「スタイルシート（CSS）」のページに挿入した表の記述。
table{
width:440px;
border-collapse:collapse;（注3）
font-size:12px;
margin-top:5px;
margin-bottom:5px;
}
注2：アンダーライン部が「スタイルシート（CSS）」で制御できない。
<table border="1px" cellpadding="2px">
<tr><td>開発コード</td><td>Katmai</td>・・（以下略）
注3：ボーダーの表示命令
border-collapse :セルのボーダーの表示の仕方を指定する。
collapse :隣接するセルのボーダーを重ねて表示する。
separate :隣接するセルのボーダーの間隔をあけて表示する。
続W3C準拠（サイト書直し）
2006年08月30日
W3CのXHTML1.0という文法に則ったサイト（ホームページ）の書き直しをほぼ終えた（終えさせた）。
W3Cとはウェブの標準化を標榜する非営利団体である。また、ページレイアウトはCSS（カスケイディング・スタイルシート）により制御している。
前回も書いたが、その目的は、ブラウザ（インターネットエクスプローラーやモジラ等、ウェブサイトを見るためのソフトウェア）に左右されない表示。訪問者の方々の意志を尊重するサイト作りである。
（ページレイアウトやデザインはほとんど変えていない）
主に心がけた点は、
1.ブラウザの違いによるレイアウトのズレをなくす。
2.文字を拡大してもレイアウトが崩れない。
3.CSSを使用を解除しても読みやすいページ作り。
4.JavaScript、Flash等、特定のアプリケーションに依存する機能を使用しない。
等々であるが、100％具現化することは、私には相当困難であり、ブラウザによってはレイアウトのズレを取りきれていない。
また、全てのブラウザ、及びバージョンでの確認はできていないので、不都合が存在するかもしれない。
CSSの記述にしても、結局の所、おっつけになっていった感がある。当初はそれを是正しようと思っていたが、考えすぎると終わりそうにないので、申し訳ないが不完全さを納得させた。
（御指摘、御指導、アドバイス等、宜しくお願いします）
今後は、W3CのXHTML1.1のほうがいいという御指摘があったが、同様に振り出しに戻りそうなので、今回はXHTML1.0のまま進むことにした。
ブログも見直す部分があるかと思うが、当分手が回りそうに無い。
W3Cとはウェブの標準化を標榜する非営利団体である。また、ページレイアウトはCSS（カスケイディング・スタイルシート）により制御している。
前回も書いたが、その目的は、ブラウザ（インターネットエクスプローラーやモジラ等、ウェブサイトを見るためのソフトウェア）に左右されない表示。訪問者の方々の意志を尊重するサイト作りである。
（ページレイアウトやデザインはほとんど変えていない）
主に心がけた点は、
1.ブラウザの違いによるレイアウトのズレをなくす。
2.文字を拡大してもレイアウトが崩れない。
3.CSSを使用を解除しても読みやすいページ作り。
4.JavaScript、Flash等、特定のアプリケーションに依存する機能を使用しない。
等々であるが、100％具現化することは、私には相当困難であり、ブラウザによってはレイアウトのズレを取りきれていない。
また、全てのブラウザ、及びバージョンでの確認はできていないので、不都合が存在するかもしれない。
CSSの記述にしても、結局の所、おっつけになっていった感がある。当初はそれを是正しようと思っていたが、考えすぎると終わりそうにないので、申し訳ないが不完全さを納得させた。
（御指摘、御指導、アドバイス等、宜しくお願いします）
今後は、W3CのXHTML1.1のほうがいいという御指摘があったが、同様に振り出しに戻りそうなので、今回はXHTML1.0のまま進むことにした。
ブログも見直す部分があるかと思うが、当分手が回りそうに無い。
マークアップ言語（XHTMLまで）
2006年06月25日
ブログなどの制作で使われているマークアップ言語の一つである、XHTMLに至る今日までの過程を簡単に振り返ってみた。
XMLだのXHTMLだの、何がどうして、どこが問題なのか。ホームページやブログといわれるウェブサイト制作とはどう関わって来たのか、不明な点が多い。自分自身の理解のために調べてみた（間違っている場合、ご指摘頂けたら幸いです）。
結論（私の理解）として、文書や、様々な情報を特定のアプリケーションに頼ることなく、安全、長期に渡り、誰もが利用しやすく、カスタマイズしやすい、標準的な文法を作る努力がなされてきた（今だ進行形）。それが、SGML、HTML、XML、XHTMLなどの言語を生み出してきたといえる。
1986年ISO（国際標準化機構：International Organization for Standardization）は、SGML（標準汎用マークアップ言語：Standard Generalized Markup Language）という標準言語を規格化した。
それまでのMarkup Languageによる、共通マークアップ（マーク付）（注１）は、特定の処理システムに依存していない利点を持ってはいるが、文書（内容）とレイアウトなどの表示方法が混在し、論理的な構造を持ったデータとして記述されていなかったために混乱が生じていた。
この問題を解決するためには、文書構造の記述を、印刷や表示などの処理系から切り離し、独立した言語として定義する必要があった。このような状況で、論理構造を対象とし、処理系非依存の共通マークアップを行う文書記述言語として誕生したのがSGMLであった。
SGMLでは、文書情報を正確に伝えること、正確に保存すること、印刷や表示などの処理には関与しないことが特徴としてあげられる。さらにSGMLは、タグや属性情報などの記述方法を規定しているだけで、名前や属性を固定的に決めているわけではなく、使用者が定義（注２）すれば自由に設定できた。また、固有ソフトに依存しないテキスト形式で記述するため、保存した文書を長期間使用できるもので、まさしく汎用ツールとしての明確な理念を持った言語として構築されたのである。
そして1990年、主に電子データ交換のため、SGMLをベースにして、Web用としてHTML（Hyper Text Markup Language）が開発された。
HTMLはインターネット上での情報共有が目的であったため、DTDを自由に定義できないように固定し、記述を簡便にした。
HTMLは、「文書の構造化」という目的よりも、ページのレイアウトや装飾も含めた記述言語として使用されることが日常化し、IEやNNなどの各ブラウザも競って固有の拡張タグを採用した。また、文法的に厳格ではなかったために、多少のミスがあっても見栄えのいい情報ページ（ウェブサイト）を公開することができた。そのために、いわゆるインターネットを爆発的に普及させる要因となった。
しかしながら、本来の勧告から外れ、混乱を招いている状況から、HTMLを本来の目的である文書構造の記述言語に戻し、デザインやレイアウトは「スタイルシート」という別の文法に担わせようという方向で確認されていった。
また、HTMLの手軽さは、ユーザーがタグを設定できない、情報の意味を記述できないなどの問題があった。また、HTML文書を保存してもブラウザで見ることしかできないというデメリットがあり、Web上でSGMLを利用しようとしても様々な問題があった。
さらに、SGMLはその記法の自由度の高さから実装が煩雑で、実装・運用にコストがかかるという難点を抱えていた。そこで、SGMLをもっとスリム化し、データ交換を重視した共通マーク付けへの拡張したものとし、インターネット上の利用を前提にして思想で再構築されたものが、1998年2月10日、XML1.0（拡張可能マークアップ言語：Extensible Markup Language）として、W3C（World Wide Web Consortium）から勧告されたのである。
XMLはSGMLのサブセット（部分集合）であり（XML文書はSGML文書でありえる）、目標は以下である（抜粋）。
・インターネット上でそのまま利用可能。
・広範多様なアプリケーションをサポートする。
・SGMLと互換的であること。
・XML文書の記述の容易さ。
XMLは、その性質上、他のマークアップ言語の骨組みとして使用される位置にあり、XMLベースのマークアップ言語としては、リモート経由で他のコンピュータのサービスを呼び出すSOAPや、Web上で画像表現のためのSVGがあり、HTMLをXMLの仕様で再定義したものがXHTML（Extensible Hyper Text Markup Language）である。
XHTMLは、HTMLのタグ構造よりも厳格に定義する。そのため、形式的に扱うことが容易であり、ホームページの自動生成などは行い易くなる。
参考までに、大蔵省の財務報告書申請・公開，特許庁の特許申請など、政府機関の各省庁や、民間の電子文書化ではSGML/XMLが利用されてきている。
注１：文章中に「タグ」という先頭と終了を示す「マーク付け」を行い、それに挟まれた文章に属性を与えたり、修飾したりすること。例：<p class="date">2006年06月21日</p>など。
注２：DTD（Document Type Definition）と呼ばれ、「見出し」や「脚注」などといった要素は、SGMLの場合、記述する人が自由に定義できた。
参照資料
各種W3C勧告文書・日本語版（どら猫本舗）
SGML/XMLによる電子文書処理（日本印刷技術協会）
ＷＷＷ講座総目次（杉浦のホームページにようこそ）
PDF資料（日本土木工業協会）
XMLだのXHTMLだの、何がどうして、どこが問題なのか。ホームページやブログといわれるウェブサイト制作とはどう関わって来たのか、不明な点が多い。自分自身の理解のために調べてみた（間違っている場合、ご指摘頂けたら幸いです）。
結論（私の理解）として、文書や、様々な情報を特定のアプリケーションに頼ることなく、安全、長期に渡り、誰もが利用しやすく、カスタマイズしやすい、標準的な文法を作る努力がなされてきた（今だ進行形）。それが、SGML、HTML、XML、XHTMLなどの言語を生み出してきたといえる。
1986年ISO（国際標準化機構：International Organization for Standardization）は、SGML（標準汎用マークアップ言語：Standard Generalized Markup Language）という標準言語を規格化した。
それまでのMarkup Languageによる、共通マークアップ（マーク付）（注１）は、特定の処理システムに依存していない利点を持ってはいるが、文書（内容）とレイアウトなどの表示方法が混在し、論理的な構造を持ったデータとして記述されていなかったために混乱が生じていた。
この問題を解決するためには、文書構造の記述を、印刷や表示などの処理系から切り離し、独立した言語として定義する必要があった。このような状況で、論理構造を対象とし、処理系非依存の共通マークアップを行う文書記述言語として誕生したのがSGMLであった。
SGMLでは、文書情報を正確に伝えること、正確に保存すること、印刷や表示などの処理には関与しないことが特徴としてあげられる。さらにSGMLは、タグや属性情報などの記述方法を規定しているだけで、名前や属性を固定的に決めているわけではなく、使用者が定義（注２）すれば自由に設定できた。また、固有ソフトに依存しないテキスト形式で記述するため、保存した文書を長期間使用できるもので、まさしく汎用ツールとしての明確な理念を持った言語として構築されたのである。
そして1990年、主に電子データ交換のため、SGMLをベースにして、Web用としてHTML（Hyper Text Markup Language）が開発された。
HTMLはインターネット上での情報共有が目的であったため、DTDを自由に定義できないように固定し、記述を簡便にした。
HTMLは、「文書の構造化」という目的よりも、ページのレイアウトや装飾も含めた記述言語として使用されることが日常化し、IEやNNなどの各ブラウザも競って固有の拡張タグを採用した。また、文法的に厳格ではなかったために、多少のミスがあっても見栄えのいい情報ページ（ウェブサイト）を公開することができた。そのために、いわゆるインターネットを爆発的に普及させる要因となった。
しかしながら、本来の勧告から外れ、混乱を招いている状況から、HTMLを本来の目的である文書構造の記述言語に戻し、デザインやレイアウトは「スタイルシート」という別の文法に担わせようという方向で確認されていった。
また、HTMLの手軽さは、ユーザーがタグを設定できない、情報の意味を記述できないなどの問題があった。また、HTML文書を保存してもブラウザで見ることしかできないというデメリットがあり、Web上でSGMLを利用しようとしても様々な問題があった。
さらに、SGMLはその記法の自由度の高さから実装が煩雑で、実装・運用にコストがかかるという難点を抱えていた。そこで、SGMLをもっとスリム化し、データ交換を重視した共通マーク付けへの拡張したものとし、インターネット上の利用を前提にして思想で再構築されたものが、1998年2月10日、XML1.0（拡張可能マークアップ言語：Extensible Markup Language）として、W3C（World Wide Web Consortium）から勧告されたのである。
XMLはSGMLのサブセット（部分集合）であり（XML文書はSGML文書でありえる）、目標は以下である（抜粋）。
・インターネット上でそのまま利用可能。
・広範多様なアプリケーションをサポートする。
・SGMLと互換的であること。
・XML文書の記述の容易さ。
XMLは、その性質上、他のマークアップ言語の骨組みとして使用される位置にあり、XMLベースのマークアップ言語としては、リモート経由で他のコンピュータのサービスを呼び出すSOAPや、Web上で画像表現のためのSVGがあり、HTMLをXMLの仕様で再定義したものがXHTML（Extensible Hyper Text Markup Language）である。
XHTMLは、HTMLのタグ構造よりも厳格に定義する。そのため、形式的に扱うことが容易であり、ホームページの自動生成などは行い易くなる。
参考までに、大蔵省の財務報告書申請・公開，特許庁の特許申請など、政府機関の各省庁や、民間の電子文書化ではSGML/XMLが利用されてきている。
注１：文章中に「タグ」という先頭と終了を示す「マーク付け」を行い、それに挟まれた文章に属性を与えたり、修飾したりすること。例：<p class="date">2006年06月21日</p>など。
注２：DTD（Document Type Definition）と呼ばれ、「見出し」や「脚注」などといった要素は、SGMLの場合、記述する人が自由に定義できた。
参照資料
各種W3C勧告文書・日本語版（どら猫本舗）
SGML/XMLによる電子文書処理（日本印刷技術協会）
ＷＷＷ講座総目次（杉浦のホームページにようこそ）
PDF資料（日本土木工業協会）
IEの問題点
2006年06月21日
前回、XHTML1.1での記述について書き、その中でＩＥの問題点に触れた。
ブラウザによって見え方が違う、レイアウトが一様ではないという問題があり、その多くはＩＥのバグによる原因から、主にＩＥで発生しているということは、多くの方が指摘している。
その一つについて、「CSSによる段組（マルチカラム）レイアウト講座」に述べてあったので紹介したい（文章も一部、引用させて頂きました）。
前回書いた記述の順序・・
XHTMLで書かれる内容の最初の１行目には、XML宣言文が来なければならない。
２行目には、XHTMLを示す、DOCTYPE宣言がくる（例はXHTML1.0）。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
所が、比較的新しいブラウザには「DOCTYPEスイッチ」という機能があり、DOCTYPE宣言の有無や、書き方によって表示モードを切り替える。
これは、CSSを正しく解釈できるブラウザにも、アバウトな解釈をする古いブラウザに合わせた表示をさせることができるというものである。
普通に規則にのっとり、DOCTYPE宣言した文章であれば、Standardsモードになる。つまり、仕様どおりに書かれたものをそのまま解釈する。
DOCTYPE宣言のない文書等はQuirksモードとなり、アバウトな解釈に合わせる。ただし、この場合、仕様どおりに書かれたCSSが、制作者の意図どおりに機能しない場合がある。
繰り返すが、XHTMLでは冒頭にXML宣言を記述するようになっている。しかし、WinIE6ではDOCTYPE宣言より前に何か文字列があると、Quirksモードになってしまう。これでは正しく表示されない。
特にボックスモデルでは、解釈が違うため、表示が崩れる。
この対策として、古いHTMLで記述するか、先頭にあるXML宣言を書かないということも考えられるが、それはできない。
そうなると、Quirksモードになっても表示が崩れないようなCSSを書く他ない。
ここではTipを書くつもりはないが、参考までにボックスモデルバグの対処法を同サイトから引用する。
widthを指定した要素には左右のpaddingとborderは指定しない。同様に、heightを指定した要素には上下のpaddingとborderは指定しない。
paddingまたはborderを指定した要素にはwidthやheightを指定しない。
この方法なら、StandardsモードとQuirksモードの違いによるボックスのサイズに違いは生じない。
結局、シェア9割前後（？）を占めるＩＥいやＩＥファミリーで正しく表示されれば他のブラウザがどうあれ、意に返す必要はないし、Ｗ３Ｃの勧告も大した問題ではないのだ。
昔、ＩＥしか知らなかった時代、私の記述はいい加減だったから、ＩＥにはよく馴染んだ。Ｗ３Ｃの勧告に近づけるようになってからも、まだネットスケープの表示がおかしいななどと、ＩＥ側から見た評価をしていた。
今は、普通のことが普通でない状況に驚いている。
ブラウザによって見え方が違う、レイアウトが一様ではないという問題があり、その多くはＩＥのバグによる原因から、主にＩＥで発生しているということは、多くの方が指摘している。
その一つについて、「CSSによる段組（マルチカラム）レイアウト講座」に述べてあったので紹介したい（文章も一部、引用させて頂きました）。
前回書いた記述の順序・・
XHTMLで書かれる内容の最初の１行目には、XML宣言文が来なければならない。
２行目には、XHTMLを示す、DOCTYPE宣言がくる（例はXHTML1.0）。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
所が、比較的新しいブラウザには「DOCTYPEスイッチ」という機能があり、DOCTYPE宣言の有無や、書き方によって表示モードを切り替える。
これは、CSSを正しく解釈できるブラウザにも、アバウトな解釈をする古いブラウザに合わせた表示をさせることができるというものである。
普通に規則にのっとり、DOCTYPE宣言した文章であれば、Standardsモードになる。つまり、仕様どおりに書かれたものをそのまま解釈する。
DOCTYPE宣言のない文書等はQuirksモードとなり、アバウトな解釈に合わせる。ただし、この場合、仕様どおりに書かれたCSSが、制作者の意図どおりに機能しない場合がある。
繰り返すが、XHTMLでは冒頭にXML宣言を記述するようになっている。しかし、WinIE6ではDOCTYPE宣言より前に何か文字列があると、Quirksモードになってしまう。これでは正しく表示されない。
特にボックスモデルでは、解釈が違うため、表示が崩れる。
この対策として、古いHTMLで記述するか、先頭にあるXML宣言を書かないということも考えられるが、それはできない。
そうなると、Quirksモードになっても表示が崩れないようなCSSを書く他ない。
ここではTipを書くつもりはないが、参考までにボックスモデルバグの対処法を同サイトから引用する。
widthを指定した要素には左右のpaddingとborderは指定しない。同様に、heightを指定した要素には上下のpaddingとborderは指定しない。
paddingまたはborderを指定した要素にはwidthやheightを指定しない。
この方法なら、StandardsモードとQuirksモードの違いによるボックスのサイズに違いは生じない。
結局、シェア9割前後（？）を占めるＩＥいやＩＥファミリーで正しく表示されれば他のブラウザがどうあれ、意に返す必要はないし、Ｗ３Ｃの勧告も大した問題ではないのだ。
昔、ＩＥしか知らなかった時代、私の記述はいい加減だったから、ＩＥにはよく馴染んだ。Ｗ３Ｃの勧告に近づけるようになってからも、まだネットスケープの表示がおかしいななどと、ＩＥ側から見た評価をしていた。
今は、普通のことが普通でない状況に驚いている。
XHTML1.1、IEと認証の問題
2006年06月18日
恥ずかしい話だが、今頃になって、サイトデザインについて、実に様々な問題があることが分ってきた。自分自身への理解を含め、その一部を述べてみたい。
ウェブサイトをデザイン（制作）する場合、文法にのっとって記述する。そして、それがどの程度正しいかチェックするサイトがある。
Ｗ３Ｃは書式の標準化を目指す非営利団体で、これまでにもいくつかの標準書式を勧告してきた。それが、HTML4.01やXHTML1.0などである。
その、Ｗ３Ｃも記述のチェックサービスを行なっている一つで、承認されると認証マークを貼り付けることが許される。日本で有名な検証サービスサイトでは、「Another HTML-lint gateway」（以下:lint）がある。
だから、チェックで合格することは励みになるし、記述の理解を高めることになる。
今回、サイトの記述のリデザインを行なうにあたり、どうせなら、最新バージョンのXHTML1.1にのっとろうとした。
所が、世の中の大半の方が使っているマイクロソフト社のインターネットエキスプローラー（通称ＩＥ）という、ブラウザの仕様は、勧告された記述ではうまく動作しないし、ＩＥに合わせると承認を得る事ができないということが分った。
例えば、XHTML1.1で書かれる内容の最初の１行目には、XML宣言文が来なければならない。
<?xml version="1.0" encoding="Shift_JIS"?>
続いて２行目には、XHTMLを示す、DOCTYPE宣言がくる。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
先頭の!DOCTYPEとは、ドキュメントタイプ（Document Type）のことで、DTDとは、文書型の宣言（Document Type Declaration）をしている。
問題は<head>の中に記述する以下の行。
<meta http-equiv="content-type"
content="application/xhtml+xml; charset=shift_jis" />
これを、「lint」でチェックすると、「XHTML1.1では<?meta http-equiv>を記述すべきではありません」というエラーメッセージをもらう。
対策として、.htaccess（注１）を使って直接メディアタイプを指定するという方法がある（つまり、「meta http-equiv」の記述を省く手法）。
.htaccessの内容を「AddType "application/xhtml+xml; charset=shift_jis" .html」と記述し（注２）、サーバーにアップする。
「lint」では見事に合格するが、ＩＥは、XHTML文書として扱わずにダウンロードファイルとなる。
結局、「AddType "text/html; charset=shift_jis" .html」でなければ、ＩＥでは見られないということになり、取りも直さずXHTMLの推薦値ではなくなるため、「lint」では合格しない。
こんなことにエネルギーを費やしている事が、実にバカバカしくなってきた。ＩＥ対策を施してXHTML1.1の認証を受けることへの興味を失った。
大きなシェアをしめるＩＥを考慮すると、個人的には（自分の能力も含め）、XHTML1.0 strictで記述するのが妥当ではないかと思っている。
注１：設定、テキストファイル。自分のサーバーのディレクトリーにアップして使用する。Webサーバの動作をディレクトリ単位で設定するためのファイル。このファイルを設置したディレクトリ以下、全てのページに有効となる。
注２：XHTML1.1文書のMIMEタイプの指定は「application/xhtml+xml」が推薦（Should）。「application/xml,text/xml」が可能（May）であり、「text/html」は禁止（Must not）ではないが、非推薦（Should not）となっている。
ウェブサイトをデザイン（制作）する場合、文法にのっとって記述する。そして、それがどの程度正しいかチェックするサイトがある。
Ｗ３Ｃは書式の標準化を目指す非営利団体で、これまでにもいくつかの標準書式を勧告してきた。それが、HTML4.01やXHTML1.0などである。
その、Ｗ３Ｃも記述のチェックサービスを行なっている一つで、承認されると認証マークを貼り付けることが許される。日本で有名な検証サービスサイトでは、「Another HTML-lint gateway」（以下:lint）がある。
だから、チェックで合格することは励みになるし、記述の理解を高めることになる。
今回、サイトの記述のリデザインを行なうにあたり、どうせなら、最新バージョンのXHTML1.1にのっとろうとした。
所が、世の中の大半の方が使っているマイクロソフト社のインターネットエキスプローラー（通称ＩＥ）という、ブラウザの仕様は、勧告された記述ではうまく動作しないし、ＩＥに合わせると承認を得る事ができないということが分った。
例えば、XHTML1.1で書かれる内容の最初の１行目には、XML宣言文が来なければならない。
<?xml version="1.0" encoding="Shift_JIS"?>
続いて２行目には、XHTMLを示す、DOCTYPE宣言がくる。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
先頭の!DOCTYPEとは、ドキュメントタイプ（Document Type）のことで、DTDとは、文書型の宣言（Document Type Declaration）をしている。
問題は<head>の中に記述する以下の行。
<meta http-equiv="content-type"
content="application/xhtml+xml; charset=shift_jis" />
これを、「lint」でチェックすると、「XHTML1.1では<?meta http-equiv>を記述すべきではありません」というエラーメッセージをもらう。
対策として、.htaccess（注１）を使って直接メディアタイプを指定するという方法がある（つまり、「meta http-equiv」の記述を省く手法）。
.htaccessの内容を「AddType "application/xhtml+xml; charset=shift_jis" .html」と記述し（注２）、サーバーにアップする。
「lint」では見事に合格するが、ＩＥは、XHTML文書として扱わずにダウンロードファイルとなる。
結局、「AddType "text/html; charset=shift_jis" .html」でなければ、ＩＥでは見られないということになり、取りも直さずXHTMLの推薦値ではなくなるため、「lint」では合格しない。
こんなことにエネルギーを費やしている事が、実にバカバカしくなってきた。ＩＥ対策を施してXHTML1.1の認証を受けることへの興味を失った。
大きなシェアをしめるＩＥを考慮すると、個人的には（自分の能力も含め）、XHTML1.0 strictで記述するのが妥当ではないかと思っている。
注１：設定、テキストファイル。自分のサーバーのディレクトリーにアップして使用する。Webサーバの動作をディレクトリ単位で設定するためのファイル。このファイルを設置したディレクトリ以下、全てのページに有効となる。
注２：XHTML1.1文書のMIMEタイプの指定は「application/xhtml+xml」が推薦（Should）。「application/xml,text/xml」が可能（May）であり、「text/html」は禁止（Must not）ではないが、非推薦（Should not）となっている。
Ｗ３Ｃ準拠
2006年06月04日
現在、Ｗ３ＣのＸＨＴＭＬ１．０という文法にのっとってサイト（ホームページ）を書き直している。
以前からＸＨＴＭＬ１．０で書いており、検証の結果、承認を得たこともある。その後、サイトの作成と文法チェックはエディターの機能を使っているせいもあって割りと安心していた。
しかし、閲覧してくださる方を考慮したとはいえない部分も多々あり、エディターでのチェックは最低限のもので、利用を考慮したとはいえないものだった。
訪問者の意志を尊重するサイト作りの一例を挙げる。
私は老眼鏡を離せなくなっているが、意匠優先で文字の小さなサイトは多く、うっかり持ち合わせていない場合、読むのに往生する。ブラウザの機能で大きくさせればいいのだが、絶対単位を用いて設計してあると、文字は固定されていて動かない。かく言う私のサイトも然りだ。
ブラウザに左右されず、閲覧者に優しい、訪問者の方々の意志を尊重するサイト作りの大切さを感じ、サイトを運営する者の責任として、改善していかなければならないと改めて考えたのである。
この作業は、私には至難である。ＸＨＴＭＬの文法にしても、系統だった正しい認識を持ち合わせておらず、その場しのぎでＣＳＳ（カスケードスタイルシート：デザイン、レイアウト等を制御する命令）をいじってきたため、記述はいい加減でシンプルではない。
完全にということは難しいと思うが、今より多少は改善されたサイトを目指している。時間はかかりそうであるが・・。
以前からＸＨＴＭＬ１．０で書いており、検証の結果、承認を得たこともある。その後、サイトの作成と文法チェックはエディターの機能を使っているせいもあって割りと安心していた。
しかし、閲覧してくださる方を考慮したとはいえない部分も多々あり、エディターでのチェックは最低限のもので、利用を考慮したとはいえないものだった。
訪問者の意志を尊重するサイト作りの一例を挙げる。
私は老眼鏡を離せなくなっているが、意匠優先で文字の小さなサイトは多く、うっかり持ち合わせていない場合、読むのに往生する。ブラウザの機能で大きくさせればいいのだが、絶対単位を用いて設計してあると、文字は固定されていて動かない。かく言う私のサイトも然りだ。
ブラウザに左右されず、閲覧者に優しい、訪問者の方々の意志を尊重するサイト作りの大切さを感じ、サイトを運営する者の責任として、改善していかなければならないと改めて考えたのである。
この作業は、私には至難である。ＸＨＴＭＬの文法にしても、系統だった正しい認識を持ち合わせておらず、その場しのぎでＣＳＳ（カスケードスタイルシート：デザイン、レイアウト等を制御する命令）をいじってきたため、記述はいい加減でシンプルではない。
完全にということは難しいと思うが、今より多少は改善されたサイトを目指している。時間はかかりそうであるが・・。
同一化が終了
2005年12月12日
ようやくＨＰとブログサイトの各部寸法を含めた同一化が終了しました。これで完全にシームレスな感覚で相互を横断的に見ることができると、自己満足しています（アイデンティティの統一でどこのサイトにいるか明瞭になる）。
ＨＰトップは従来から３カラムでしたが、ＨＰ記事本文は擬似３カラムでした。これをきちんとした３カラムにしました。本文のサイズは図などがあるため、従来通りとしました（トップページよりも広めです）。
また、トップタイトルが左寄りで、他のコメント行との統一感がありませんでしたのでセンターに移動しました。
ブログサイトの扱いは、以前設けていたデイリートークからの移行です。どちらかといえばジェネラルな話題を中心に、家具インテリア、日曜大工、手作り全般をモチーフにしています。これらのテーマに関心がある方に広く読んでいただければ良いと思っていますが、マイナーなページですので訪問者は伸びませんネ。
テーマごとに振り分けてくれること、アップロードが簡単なことはブログのメリットです。
ＨＰトップは従来から３カラムでしたが、ＨＰ記事本文は擬似３カラムでした。これをきちんとした３カラムにしました。本文のサイズは図などがあるため、従来通りとしました（トップページよりも広めです）。
また、トップタイトルが左寄りで、他のコメント行との統一感がありませんでしたのでセンターに移動しました。
ブログサイトの扱いは、以前設けていたデイリートークからの移行です。どちらかといえばジェネラルな話題を中心に、家具インテリア、日曜大工、手作り全般をモチーフにしています。これらのテーマに関心がある方に広く読んでいただければ良いと思っていますが、マイナーなページですので訪問者は伸びませんネ。
テーマごとに振り分けてくれること、アップロードが簡単なことはブログのメリットです。
