と、そんな話はここでお終いにして…。
バージョン3になってやっとMac版のFirefoxは、カラー調整したモニタで見てもsRGBの色空間で表示されるようになったような気がするのですが、気のせいでしょうか？

で、今回それだけではなくチロチロッとコンフィグをいじってあげると、写真の中に特殊なカラープロファイルが埋め込まれていればそれを有効にして表示してくれるようですので、仕事にもなんとなく関わることですし早速実験してみました。

まずは、カラーマネジメントが無効であるデフォルトの状態でAdobe RGBのカラープロファイルが埋め込まれた写真を表示してみます。

これはJPGファイルの中に埋め込まれたプロファイルを無視した状態ですね。WindowsのSafari以外で見ると（このページ）、なんとなくこんな色味に近い状態で出てるのではないかと思います。

で、早速カラーマネジメントの機能を有効にしてみましょう。
アドレスバーに「about:config」って入力してコンフィグの画面を呼び出し、上にある空欄に「color」とか打ってカラーマネジメントの機能を有効にするための「gfx.color_management.enabled」の項目を探します。
※後述してますが、この状態ではカラーマネジメントが有効かつモニタのプロファイルが有効な状態になります。

その項目をダブルクリックすると「false」が「true」に変わってカラーマネジメントの機能が有効になります。一度リスタートしないと反映されません。

そうすると写真の中に埋め込まれたカラープロファイルで写真が表示されます。
この画面にある写真の場合は、ダウンロードして加工する人のためにわざとAdobe RGBのプロファイルを埋め込んでいるので、色の再現領域がsRGBより広いためこんな感じで派手めな感じで表示されます。ま、なんとなくこんな感じで（Photoshopとかでファイルのカラープロファイルを有効にして開いた状態ですね）。

Safariはもともとカラープロファイルを認識するので、同じように表示されるかチェックしてみました。その結果が下の画面になります。

いかがでしょうか。ほぼ一緒というか同じですね。

といっても、単純にこれを有効にするだけではサイト全体の色味にも影響するようですのでご注意下さい、というか対処方法はこの辺りに書いてあるようです。

具体的には、同時に「gfx.color_management.display_profile」をダブルクリックして、iccカラープロファイルの場所（例えばOS XでsRGBにしておきたければ、/Library/ColorSync/Profiles/sRGB.iccとかね）を指定するようです。sRGBにしておくか、モニタのプロファイルにしておくか（何も指定しない状態）でもまたサイト全体の色味が変わってきますからね。あー、こりゃこりゃって感じです…。色の話は面倒ですね。ややこしやー、ややこしや。

A string containing the full path to an ICM profile for output. Default is an empty string in which case the systems global profile is used. If no global profile can be found a default sRGB profile is used.

ってな感じで、空にするとシステムで設定してるiccカラープロファイルが用いられるけど、それがなければsRGBのプロファイルになるよって感じでしょうか。

結局この記事を書きながらアレコレ試してみて、どうしておくのが一番かって何もしないのが一番かもね、って結論に達しつつカラープロファイルだけ有効にしてます（かつモニタのプロファイルが有効な状態）。このカラーマネジメントの機能を有効にした方が良いかどうかは判断に迷うとこですが、そんなのが隠されているよっていう話でした。

「about:config」いじるのがあれなら「Color Management」ってアドオンもあるようです。

＃余談ですが、スムーズスクロールが気持ちいいです。

＃あ、あとサイト毎に文字サイズの変更が保存されてるようです。「Content Preferences」がいらなくなりました。文字の拡大縮小はデフォルトでズームの挙動なので、画像サイズをそのままにしたければ「テキストのみ（日本語でどう書いてあるか知りませんが）」を有効にしましょう。

追記（2008.06.20）: OS XのFirefoxでここにsRGBを明示すると、AdobeRGBの含まれた写真もsRGBになってるなぁ…。とりあえず何も指定しないでおこうっと。

※ココよりもこちらに紹介しているページの方がはるかに参考になります。

よって、またしても異常に長い文章になっています…。Safariの開発メニューの使い方含め、その辺に興味のある方だけ先にお進み下さい（笑）。

Safari 3.1から誰でも使える「開発」メニュー

実はSafari 3.1になってから初期設定を開いて「開発」メニューを有効にすることで、いろいろな情報を見たりユーザーエージェントを変更したりできるようになっています（もともとDebugメニューとして今までも使えたのですが、実は隠されてました）。
これはもちろんWindows版でも有効にできます。

実はこのメニューにある項目のそれぞれが使えるヤツらで、JavaScriptのエラーの箇所をチェックしてみたりCSSの内容をみてみたりといった、Firefoxではアドオンの類を追加しないとできないようなことも簡単にできるのです。あ、HTMLのバリデートも自動的にやってますね、そういえば。

で、中でも「ネットワークタイムライン」では配信データの容量というのが確認できます。時には「！」が付いて「このデータは圧縮して送ったらサイズもちっちゃくなるよ」みたいな吹き出しが出たり、この「Webインスペクタ」ウィンドウ全体では、スクリプトにエラーがあると赤いマークでお知らせ&該当箇所の表示とかも可能です。

実際にこのブログが配信してるデータを見るとこんな感じです。これはうちのサーバからだけでなく外部のソースも込みになりますが、単純に足し算すれば「テキスト: 28.36KB」「CSS: 12.29KB」「JavaScript: 43.32KB」の画像以外のデータが送られてるということが、下にある合計値をみるとわかります。

塵も積もればなんとか、なのでデータの圧縮を試みる

WordPressはPHPなので、設定ファイル「php.ini」の「zlib.output_compression」を「On」にすれば、zlibで透過的に圧縮されてコンテンツが送り出されます。しかし、これだけではCSSやJavaScriptのファイルとかは当然対象外です。WordPressだといってもこれらは外部ファイルですし、そのまま普通に配信されます。実際には、コンテンツのテキストよりもそっちの方がでかいってこともざらにあるでしょう。

ここで例えばPHP側の圧縮を有効にしてみるとこんな感じになります。これだけでも確かにDocumentのデータは半分以下になってますが、それ以外は何も変わりません。

これじゃ効果も薄いかなってことで、今回はApache側でも画像以外のデータを全部圧縮して送りつけてやることにしました。まず、Apache（うちは2なので）のモジュール「deflate」を有効にします。a2enmodコマンドを使ってdeflateが使えるように以下のような感じで入力して、Apacheさんを強制的にリロードします。
（※a2enmodは特定のモジュールを有効にします。無効にする時はa2dismod）

# a2enmod Which module would you like to enable? Your choices are: （ここにだらだらと使えるモジュールが出てくる） Module name? deflate　←deflateって入力してリターン Module deflate installed; run （ここにコマンドが出てくる） to enable. # /etc/init.d/apache2 force-reload　←こんな感じでリロード

んでもって、apache2.confとかに以下の記述を追加します。 今回はApache2のマニュアルにある記述をそっくりそのまま拝借しました（笑）。

<IfModule mod_deflate.c> SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary </IfModule>

マニュアルにあるコメント行とかなくすとこんな感じ。
で、保存して再起動すると圧縮が有効になります。その結果が下の図です。
ちなみにApache2でdeflateを上のようにして有効にすると、PHP側の圧縮は有効にしなくても圧縮されてます。ダブルパンチだと二重で潰れてるようですね。

という風に内部のデータだけでも圧縮してあげることで「テキスト: 12.71KB」「CSS: 3.76KB」「JavaScript: 36.17KB」まで減りました。「最初からちゃんとやれよ、お前」的な話ではあるのですがね…。久しぶりにApacheの設定見ましたよ（笑）。
まぁ、こんな風にSafariの開発メニューは使えるよってことが主題ですから（謎）。

たまには自分のサイトも見直してみましょう

圧縮するしないはともかくとして、こうやって一度ぐらいは自分のサイトや作っているサイトの様子でも見てみると良いですよ。本人は気付いてないだけでJavaScriptが何百KBとかあるかもしれませんからね…（ホントにそれって必要？みたいな）。携帯のフルブラウザで見る時は、そんなサイトでげんなりしています（笑）。

Web屋さんのブログでもHTMLのバリデートにバシバシひっかかってますね…、フフフ。

Apacheセキュリティ

posted with amazlet at 08.05.01

アイヴァン リスティク
オライリージャパン
売り上げランキング: 66160

おすすめ度の平均:

まずこれを買おう

Amazon.co.jp で詳細を見る

「何やら最近の日付のバックアップファイルを発見！」

と思ってとりあえず解凍を試みるも、こないだあまりにも長いので途中でぶった切ってたもんだからちゃんとしたファイルになってなくて解凍できず（笑）。

良い機会なので、こないだバタバタとサーバをアップデートしてそのまま放置していたMySQL関係の件をちゃんと見直すことに。やはり4.xから4.1を素通りして5.0になってしまったのを、いくら自分のサーバだからとそのままじゃイカンだろうと思い直しました。

とりあえずこのあたりのアップグレードに関しての問題は、日本語が含まれるデータがあることによるサーバとクライアント間の文字コードの変換処理です。まぁ、パッケージで楽して入れてるからそのまんま何もしなけりゃLatin1になってますわな…。

ということで、他で動いてるものを考えてもutf-8で問題ないだろうということで、何が何でもutf-8になるようにMySQLまわりの設定を変えてみました。
以下の記述を「my.cnf」に追加してからMySQLを再起動。

[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8
skip-character-set-client-handshake
[mysql]
default-character-set=utf8
[mysqldump]
default-character-set=utf8

ま、何か問題があったらそん時考えますわ（笑）。

＃で、こそこそこんなことしてたらモダシンさんのコメントやらかしちゃいました…。ごめんなさい。

追記: そういえば、WordPress 2.5.1が出てるのですが、どうやらユーザ登録とかを可能にしてると2.5以前のWordPressはホニャララできるようですね（28日付のとか）。WordPress本体以外にプラグイン周りでもいろいろとあるようなので、使ってる方は2.5.1にしておいた方がよいかもしれません。詳しくはSecuniaを。
→http://secunia.com/search/?search=wordpress