作成者別アーカイブ: admin

GIF形式とPNG形式の使い分け

WEB制作でよく使われる圧縮画像形式としては、写真などに高い圧縮率を誇るJPEG形式と、イラストなどの色の少ない画像に最適なGIF形式、PNG形式があります。JPEG形式とGIF、PNGとの使い分けは上に書いた通り、対象が使用色が少ない画像かどうかによって決定することができますが、ではGIF画像とPNG画像の使い分けはどのようにされるべきでしょうか?今回はそれについて纏めてみました。

まず、両形式が普及した背景を眺めてみます。GIF形式の登場は20年以上前で、当時通信速度の遅かったパソコン通信でサイズを減らして画像のやり取りをする必要性から普及しました。通信速度の制限に加え、当時のパソコンの処理速度的な問題から24bitフルカラー画像は扱いにくかったため、GIF画像には最大256色という制限が設けられています。

対するPNGは、GIF形式の特許問題が浮上した15年程前に開発が始められました。フルカラーに対応、透明度の設定が可能などGIFよりも多くの機能を持っていましたが、本格的な普及は2000年代前半以降になります。丁度この頃にGIFの特許の適用範囲が拡大され、一般のWEB制作者にも特許問題が無縁ではなくなってきたため、GIF利用者が流れるようにPNGに移行し、PNGはWEBの標準フォーマットとしての地位を確立するに至りました(現在ではGIFの特許が失効しているため、制作者がGIFを避ける風潮はなくなっています)。

以上が両形式の登場背景ですが、こうした登場背景の違いに由来して、次のような差異が存在します。

  • PNGがフルカラーに対応しているのに対し、GIFは基本的には非対応
  • GIFは初期のWEBブラウザでも対応している。PNGは1997年頃以降からボツボツと対応
  • iモードのブラウザでは(おそらくフルカラー画像によるパケット増大を避けて)PNG不可

一方で両者は規格の性質にも多少の違いがあり、PNGはGIFの単純な上位互換というわけではなくなっています。たとえば、GIF形式は複数の画像をセットにして1ファイルにすることができます。この性質を利用して複数画像をパラパラ漫画のように使ったのがアニメーションGIFですが、PNGはアニメーションをサポートしておらず、機能拡張板であるMNGやAPNGといった規格が別に存在しています。

  • PNGはアニメーションに対応していない

先ほど、GIF形式は基本的にはフルカラーに対応していないと書きましたが、このアニメーション機能を力技的に利用すれば、フルカラーの画像をつくり出すこともできます。フルカラーの画像を256色ずつ数枚の画像に分離して、短い時間間隔で表示する方法です。しかし、本当に初期のブラウザや携帯のブラウザは、そもそもアニメーションGIFに対応していなかったり、表示枚数に制限があったりするので、この技は万能ではないということにも注意する必要があります。

透明部分を持った画像の実現方法にも、興味深い違いを見て取ることができます。詳細については次のエントリに書きますが、後発の規格であるPNGの方が柔軟な方法をとっており、総じて次のようなことが言えます。

  • 透明部分がある画像については、PNGを使っておいた方がなにかと便利である
  • 透明PNGは古いブラウザでは対応していないが、力技的に対応させることが可能である

以上のような判断材料から、GIFとPNGの使い分けを考えればよいということになります。勿論それぞれをサイト上の適材適所で用いればよいのですが、複数の画像フォーマットが混在して画像リンクの設定ミスが起こってしまう(.gifの拡張子のところを.pngにしてしまうなど)ことを避けるために、どちらかの形式に統一しておくということもひとつの考え方です。


近況、便秘がクライマックス!!

とあるプログラムを作ろうとしていて、どのように書いてもある一箇所のせいで動かない。そこで関係ありそうなリファレンスをひたすら調べ回る、そんな1週間を過ごしていました。

処理のためのアルゴリズムが間違っていないのなら、そこから先は言語の仕様との闘いみたいなもので、仕様を把握しているかしていないか、1か0かのデジタルな要因によりプログラムの正否が決まるわけです。つまり、7日間で解決した問題について、6日目に6/7の達成率があったというわけではなく、その時点では0、そんな塩梅です。

だからこそ、0が1になった瞬間というのは感慨もひとしおです。単純な問題に7日間も足を取られていた自分の能力にこそ疑問を持つべきなのでしょうが、それよりも今後同じ処理を組み込むとき、桁違いに少ない時間で実現することができるようになったことがうれしくてたまらない感じです。

この感覚は、便秘が治った時に近いです。故郷(クニ)のお母サンにぜひ伝えてやらねばなりません。『プログラミングとは、便秘であると見つけたり』

今回の便秘もいよいよクライマックスなので、一刻も早く貯まりに貯まった宿便を霧散させてしまえるよう、頑張っていきたいと思います。


サイトC:WordPressをインストール

今回はサイトC(このサイト)にWordPressをインストールするまでの、顛末兼導入ガイドを書きます。MySQLのデータベースは作成してあるという前提(実は今回の事例の場合、契約したサーバRental Orbit SpaceさんがMySQLデータベースは申請を受けて発行という方式をとっていたので、非常に楽でした)かつインストールはウィザードなしで行うという前提で進めます。

まず、何をおいてもWordPressの本体を手に入れなければならないので、日本語版のサイトに行ってダウンロードリンクから落とします。この記事を書いている時点の最新版は2.9.2で、この2.9系のバージョンは日本語文字コードがUTF-8のみに対応しているようです。一方Shift-JISやEUC-JPを使用する際には、過去にリリースされた2.0.x系を利用します。ただし古い系統はメンテナンス期間も終了したようなので、WordPressを使うのならUTF-8環境にする必要があるくらいに捉えておいたほうが良いと思います。

さてローカル環境でファイルを解凍したら、wp-config-sample.phpという名前のファイルを探し、エディタで開きます。このとき、ファイルの中にも書いてありますがメモ帳などのアプリケーションでなく、文字コードを指定して保存できるエディタを使ってください。22行目付近からがMySQLの設定になりますので、あらかじめ用意しておいたMySQLデータベースのデータベース名、ユーザ名、パスワード、ホスト名(web上に公開するならば、契約したサーバのホストネームを入れます。そうでなくローカル環境で使用するなら変更しなくてOKです)をそれぞれputyourdbnamehere、usernamehere、yourpasswordhere、localhostの代わりに入れます。このファイルはwp-config.phpという名前を付けて、選択肢にあればUTF-8N、なければエディタの設定でBOMなしにした上でUTF-8で保存してください(このBOMというのは、UTF-8のファイルの頭につくちょっとした情報ですが、ここでは必要ありません)。

さてこうしてwp-config.phpが加わったフォルダを、ドキュメントルート以下にアップロードします。ブラウザでそのフォルダまでのパスを指定しアクセスすると動きます。以上でインストールの完了です。

このようなインストール手順を、サイトCについては5分程で行えました。以降トラブルもなく動いているので、導入が非常に簡単なCMSであるという印象を個人的に持っています。また、インストール後の画面でどこから手を付けてよいのかが比較的判り易く、はじめてCMSを使う人にもお勧めできるアプリケーションだと思います。

サイトCの制作では、主にWordPress標準のインストール機能で追加ファイルを落としてきて、管理画面上から見た目などを変更するという方法を使います。次回以降はその過程を報告していこうと思います。


プログラム・設定ファイルのコメント書式一覧

個人的によく使うプログラミング言語・設定ファイルのコメント書式を、まとめてメモしておこうと思います。

コメント書式一覧
言語・設定名 コメントの書式 備考
XHTML(HTML)・HTML5 <!‐‐ ここにコメントを書く ‐‐> 複数行も可能です。コメント中の連続したハイフン(‐‐)の使用は禁止されています。
CSS /* ここにコメントを書く */ 複数行も可能です。
PHP // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
#ここにコメントを書く 一行のコメント。複数行はダメ。ShellやPerl形式。
/* ここにコメントを書く */ 複数行も可能です。
JavaScript・ActionScript // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
Objective-C・Swift // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
SQL ‐‐ ここにコメントを書く 一行のコメント。複数行はダメ。
/* ここにコメントを書く */ 複数行も可能です。
php.ini(PHPの設定ファイル) ; ここにコメントを書く 一行のコメント。複数行はダメ。
.htaccess(サーバアプリケーションの設定ファイル) # ここにコメントを書く 一行のコメント。複数行はダメ。

これからもうちょっと複雑なWEB制作を始めたら、表の項目が増えていく可能性もあります。そして、間違っている箇所を発見したら指摘していただけると非常に助かります。


サイトデザイン初歩の初歩

非常に単純なことなのですが、サイトのGUI部品、タイトルロゴなどの青写真を組み立てるとき、頭の中で考えるよりまずブラウザが立ち上がってるスクリーンショットを保存し、画像編集ソフトのレイヤーにする。その上で部品のデザインを行い配置していく。

恥ずかしながらこれに気付くのに結構かかりました。紙にデザインを描いて、実際画面上でラフ画のイメージが再現されないのは自分の技術不足だと勘違いしていたのですね。

携帯を持っているのに電卓を探して部屋中うろうろしていたような、そんな感じです。


cPanelファイルマネージャに対するいくつかの不満点

以前の紹介記事で、cPanelのファイルマネージャはオフライン環境を一掃できるような多機能なアプリケーションだと書きました。しかしながら、使い込んでいくと判る不便なところもあります。今回は一般的なオフラインアプリケーションと比較して、cPanelが劣っている点について書いてみようと思います。

まずはFTPクライアントの代わりとなる、ファイルマネージャの主要部分についてですが、以下のような不満点があります。

  • 同じディレクトリに同じファイル名のファイルを作成しようとしたとき、代替案を出してくれない
  • ローカル環境からのファイルのドラッグ&ドロップに対応していない

まず上の項目についてはなかなか根深い問題のようで、この仕様に関連しているだろうと思われる不具合がたくさんあります。同名の新規ファイルが作れないことの他、同じディレクトリ内に既存ファイルのコピーが作れない(オフラインのFTPクライアントであれば、大抵は既存のファイル名の後ろに数字や文字列をつけた新しいファイルを作ってくれる)、はては別ディレクトリから同名のファイルを移動してくると、勝手に既存ファイルを上書きしてしまうなどの問題が発生します。これではうっかり操作ミスなどをしてしまった場合は一巻の終わりです。

下の項目も非常に不便な仕様で、ローカルのファイルをアップロードする場合面倒くさいだけではなく、フォルダを丸ごとアップする場合に、一度圧縮などで1ファイルに纏めた上でアップローダを使って上げなければならないという制約がつきます(まあ、アップローダと圧縮・解凍ツールは標準でついていますが)。

次に、付属のエディタであるHTML editor/Code editorですが、以下の点が不十分に感じられます。

  • 拡張子が.htmlでないとHTML editorが立ち上がってくれない
  • 指定文字コードでうまく開いてくれない場合がある。開き直さなければならない

前者は拡張子.tplのテンプレートファイルや、phpコードを含んだhtmlファイル(拡張子.php)をエディットする時に不便です。拡張子に関わらず両方のエディタを選択できるようにしなかったのは、どうにも不可解な仕様に思えます。

以上、総括するならば、オフラインのアプリケーションと比べてかなり大味な作りになっているということが言えると思います。オフラインのアプリケーションであれば、環境設定パネルなどでアプリケーションの挙動をかなり変えられるのが普通ですが、このファイルマネージャのsettingメニューには、文字コードについての確認ダイアログを出すか出さないかの一項目しか存在しませんでした。つまり、オフラインアプリケーションの代わりにファイルマネージャを使うためには、相応の忍耐強さと、アプリケーションの挙動についてある程度予測できる洞察力が必要なのかもしれません。

今回は悪い点ばかりを列挙しました。前回便利な点ばかり挙げたエントリと合わせて、サイト作成環境選びの判断材料に使ってもらえれば幸いです。


サブドメイン設定とシンボリックリンクの作成

前の投稿の続きになります。

サイトAにサブドメインを追加することが決まったので、優等生アプリケーションcPanelを使って設定します。cPanelのDomainsのボックスにSubdomainsがあるのでクリック、サブドメイン設定のページに遷移するので、テキストフィールドにサブドメイン名とサブドメインのドキュメントルートを入力して終わりです。ドキュメントルートとは、サブドメインhttp://××.○○○.com/にアクセスされた時に開くディレクトリのことで、今回サイトAのサブドメインhttp://en.○○○.com/のルートにはhttp://www.○○○.com/enというディレクトリを作り指定しました。

さて、前回のエントリで書きました通り、サブドメイン設定後にある問題にぶちあたりました。サイトAではサイトに共通のスタイルシートをhttp://www.○○○.com/cssにまとめて置いていたのですが、http://en.○○○.com/以下のファイルから相対パス指定でアクセスしようとすると、not foundになってしまうのです。サブドメインのドキュメントルートをhttp://www.○○○.com/enにしているわけですから、cssディレクトリ中の例えばsample.cssというファイルにアクセスするには、相対パスで”../css/sample.css”と指定すれば良いと思っていました。しかしエラー表示を見ると、要求したアドレスの頭がhttp://en.○○○.com/になっています。つまり、サブドメインを作成してしまうとそのアドレスのドキュメントルートにどのデイレクトリを指定しているかに関わりなく、アドレス要求の頭がサブドメインになってしまいそれ以上遡れないようになるのです。

調べてみると、この問題を解決するための考え方には以下の3通りがあるようです。

  • ディレクトリ構成を再考する
  • ファイル指定は常に絶対パスで行う
  • サーバのOSであるUNIXのファイルシステム上で設定をいじる

まず一番上のディレクトリ構成の再考ですが、簡単に言うと大前提である一箇所に纏められたcssファイルの使用をあきらめるということになります。サブドメインに個別のcssデイレクトリをつくって、一部の共通スタイルシートは重複して存在させるようにします。この方法であればサブドメインから遡れない箇所にあるファイルにアクセスしなくて済みます。ただ、当然ながら片方のcssファイルに加えた変更はもう片方に反映されないため、サイト全体に関わるスタイルの変更を行う時には、共通ファイルに複数の版が存在してしまわないよう気をつけなければなりません。

次に、絶対パスの使用です。簡単に言うと相対パスを使わず、ファイルを呼び出す時は必ずhttp://から始まるアドレスを入力するという方法です。PHPなどのスクリプト言語が使用できる環境なら、http://www.○○○.com/の部分を定数として定義、cssファイルなどが呼び出されるときに文字列連結するようにすれば、将来的にドメインを移行することになっても修正箇所が少なくて済みます。

最後のひとつ、UNIXファイルシステムの機能を使う方法は、windowsのショートカット、MacOSのエイリアスにあたるシンボリックリンクを使う方法です。今回の解決法にはこれを採用しました。

とは言えUNIXコマンドの知識は皆無だったので、webで調べながらコマンドを打つ方法では操作を間違えてしまった時に何が起こるのか予想もつかないということで、もう少し簡単で安全な方法を探しました(本当はcPanelに標準でついていてほしい機能だったのですが)。すると、どうやらPHP4以降のバージョンにはシンボリックリンク作成のためのsymlinkという関数が搭載されているようです。

symlink関数は、symlink(引数1,引数2)という書式をもち、引数1にはリンク先(上の例でいうならhttp://www.○○○.com/以下のcssデイレクトリ)、引数2には新しく用意するパスを与えます。ただこの際に行うのはあくまでサーバのUNIXファイルシステムに対する操作なので、http://から始まるパスではなく、サーバから提供されたドキュメントルートのパスを与えてやらなければなりません。このサイトAの場合には、/home/ユーザ名/public_html/がドキュメントルート(http://www.○○○.com/でアクセスできる場所)として与えられていたので、symlink(/home/ユーザ名/public_html/css,/home/ユーザ名/public_html/en/css);という命令を実行してシンボリックリンクを作成しました。

さて、こうしたシンボリックリンクを作成の度に手打ちでphpファイルを修正、ブラウザからアクセスという手順を踏むのは面倒です。そこでフォームから与えられたパスでリンクを作ってくれるphpファイルを作成しました(右クリックメニューからからダウンロードを選択してください。あと圧縮ファイルなので実行時には解凍してください)。

Symlinkcreator.rar(2012.6追記:配布終了しました。代わりにソースコードを書き連ねておきます。)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>tool_symlink</title>
</head>
<body>
<p><strong>Create a symboliclink of selected file/directory.</strong></p>
<p>Paths like /home/username/public_html/... are required.</p>
<form action="tool_symlink.php" method="post">
<p>Original to a link : <input type="text" name="linkoriginal" /></p>
<p>Jump from this new path : <input type="text" name="jumpfrom" /></p>
<p><input type="submit" value="create" /></p></form>
<?php
if(!empty($_POST["linkoriginal"]) && !empty($_POST["jumpfrom"])){
if(file_exists($_POST["linkoriginal"])){
if(file_exists($_POST["jumpfrom"])){
echo "ERROR : The name you entered for symboliclink is already used.<br /> ";
}
else{ 
symlink($_POST["linkoriginal"],$_POST["jumpfrom"]);
echo "Symbolic link <strong>".$_POST["jumpfrom"]."</strong> to <strong>".$_POST["linkoriginal"]."</strong> is now available.";
}
}
else{
echo "ERROR : The file/directory you have requested as original is not found.";
}
}
?>
</body>
</html>

ちなみにセキュリティ対策は何も行っていないプログラムなので、外部からアクセスできないデイレクトリに置いて使う必要があります。あとこのプログラムによって引き起こされた損害に対して作者は責任を負いません。実際簡単なプログラムなので、無許可で改変して実用化してもらえればと思います。

解決法に辿り着くまで、それから実際にプログラムを完成させるまでかかった時間を、同じ問題にぶつかった人がこれで短縮できればと思っています。