ホーム
warning: Creating default object from empty value in /var/www/drupal-5.23/modules/taxonomy/taxonomy.module on line 1418.

Perl で、画像のサムネイルを作成してブラウザから表示させる方法

以下のサンプルファイルを image.cgi と名前を付けて保存、アクセス権を chmod +x image.cgi とかして ブラウザから https://yourname.com/image.cgi とかにアクセスすればよい。 注意点としては、このスクリプトは画像しか表示できないことである。これと一緒に HTML ファイルを表示しようと思っても、HTTP プロトコルの仕様上不可能である。なぜかというと HTTP プロトコルを通して画像を表示する場合は、すでにこのスクリプトが HTTP ヘッダとして Content-type: image/jpeg を最初に出力してブラウザが受け取っているからで、このスクリプトの中で同時に（画像を表示した後に） HTML 文書を表示させようとて Content-type: text/html を出力（print "Content-type: text/html\n\n）してもブラウザは受け付けてくれないのである。 #!/usr/bin/perl use GD;
以下のサンプルファイルを image.cgi と名前を付けて保存、アクセス権を chmod +x image.cgi とかして ブラウザから https://yourname.com/image.cgi とかにアクセスすればよい。 注意点としては、このスクリプトは画像しか表示できないことである。これと一緒に HTML ファイルを表示しようと思っても、HTTP プロトコルの仕様上不可能である。なぜかというと HTTP プロトコルを通して画像を表示する場合は、すでにこのスクリプトが HTTP ヘッダとして Content-type: image/jpeg を最初に出力してブラウザが受け取っているからで、このスクリプトの中で同時に（画像を表示した後に） HTML 文書を表示させようとて Content-type: text/html を出力（print "Content-type: text/html\n\n）してもブラウザは受け付けてくれないのである。 #!/usr/bin/perl use GD;
Posted on 2007-12-07 by yas |

Requirements for Mobile Phones (English)

I would like to propose the unique requirements for mobile phones. The following items are significant considerations under mobile site development, especially in i-mode phones.
  1. UserAgent type that is, a Browser Name of CGI environments which is sent by a mobile phone to a web server.
  2. Range of IP addresses in each mobile operator, which is required to judge whether a user is using a mobile phone or a PC in order to support both of them in the web site. In Japanese mobile phone operators, they are using their specific proxy servers, which are accompanying with the specific range of IP addresses.
  3. Screen Size of each mobile phone, especially the size of width, which would be found in a CGI environment UserAgent in the latest phones
  4. Image Format such as JPEG, PNG and GIF supported by each mobile phone
  5. Maximum Size of Receiving Bytes per a page
  6. Difference of Handling Colors in each mobile phone
  7. Difference of Smilies (Picture Icons) both in each mobile phone and operator
  8. Name Convention of an E-mail Address in each operator (Japanese i-mode e-mail system violates RFC).
  9. Available Character Set in each operator (Shift-JIS, UTF-8 in Japan)
  10. Available Character Types in each operator (such as ZENKAKU, HANKAKU in Japan)
  11. Available Input Method in each operator (Access-key concept in CHTML)
  12. Support of Native Functions of a mobile phone (i.e. switching a browser screen to an e-mail application with 'mailto:' in CHTML at a single screen of a mobile phone, launching Java application, and directly calling to someone with 'tel:' in CHTML, etc)
  13. Difference in between Official Sites and Unofficial Sites (The acquiring information is different)
  14. Session Management because we cannot use cookie in i-mode phones
I would like to propose the unique requirements for mobile phones. The following items are significant considerations under mobile site development, especially in i-mode phones.
  1. UserAgent type that is, a Browser Name of CGI environments which is sent by a mobile phone to a web server.
  2. Range of IP addresses in each mobile operator, which is required to judge whether a user is using a mobile phone or a PC in order to support both of them in the web site. In Japanese mobile phone operators, they are using their specific proxy servers, which are accompanying with the specific range of IP addresses.
  3. Screen Size of each mobile phone, especially the size of width, which would be found in a CGI environment UserAgent in the latest phones
  4. Image Format such as JPEG, PNG and GIF supported by each mobile phone
  5. Maximum Size of Receiving Bytes per a page
  6. Difference of Handling Colors in each mobile phone
  7. Difference of Smilies (Picture Icons) both in each mobile phone and operator
  8. Name Convention of an E-mail Address in each operator (Japanese i-mode e-mail system violates RFC).
  9. Available Character Set in each operator (Shift-JIS, UTF-8 in Japan)
  10. Available Character Types in each operator (such as ZENKAKU, HANKAKU in Japan)
  11. Available Input Method in each operator (Access-key concept in CHTML)
  12. Support of Native Functions of a mobile phone (i.e. switching a browser screen to an e-mail application with 'mailto:' in CHTML at a single screen of a mobile phone, launching Java application, and directly calling to someone with 'tel:' in CHTML, etc)
  13. Difference in between Official Sites and Unofficial Sites (The acquiring information is different)
  14. Session Management because we cannot use cookie in i-mode phones
Posted on 2007-05-21 by yas |

Perl で、メールのサブジェクト (Subject) を文字化けしないで送信するには？

メール送信時に日本語をサブジェクトに書いて送るには、この部分は Base64 にエンコードした JIS でなければならない。要は、見た目が Subject: =?ISO-2022-JP?B?GyRCJTUlViU4JSclLyVIJE4lRiU5JUgkRyQ5GyhC?= のようにBase64 でエンコードされていることである。 それでは Perl でサブジェクトを Base64 処理してメールを送るにはどうしたらいいだろう？ズバリ、「Base64エンコード・デコードする」が詳しい。より具体的には、リンク先のページを少し下にいったところの、add_econde_word という関数である。しかしこのモジュールは jcode.pl を使う。 Perl 5.8 以上であれば、use Encode; とできそうだが、このモジュール、個人的にはあまり完成度が高くないと思っている。完成度なら Unicode::Japanese の方がスマートだし使いやすい。従って以下にjcode.pl の部分を、Unicode::Japanese で置き換えた例を示す。 使用するクラス use Unicode::Japanese; use MIME::Base64;
#!/usr/bin/perl

use Unicode::Japanese;
use MIME::Base64;

sub add_encode_word {

    my($str, $line) = @_;
    my $result;

    my $ascii = '[\x00-\x7F]';
    my $twoBytes = '[\x8E\xA1-\xFE][\xA1-\xFE]';
    my $threeBytes = '\x8F[\xA1-\xFE][\xA1-\xFE]';

    # この次の while 以下は EUC の文字列を対象に処理することになっているため
    $str = Unicode::Japanese->new($str, 'auto')->euc;

    while (length($str)) {
        my $target = $str;
        $str = '';
        if (length($line) + 22 + ($target =~ /^(?:$twoBytes|$threeBytes)/o) * 8
            > 76) {

            $line =~ s/[ \t\n\r]*$/\n/;
            $result .= $line;
            $line = ' ';
        }

        while (1) {

            # EUC を JIS に直す
            $target = Unicode::Japanese->new($target, 'euc')->jis;

            my $encoded = '=?ISO-2022-JP?B?' .
            encode_base64($target, '') . '?=';
            if (length($encoded) + length($line) > 76) {
                $target =~ s/($threeBytes|$twoBytes|$ascii)$//o;
                $str = $1 . $str;
            } else {
                $line .= $encoded;
                last;
            }
        }
    }
    $result . $line;
}

print add_encode_word('サブジェクトのテストです', 'Subject: ');

1;
これを実行すると、以下の文字列が得られる。 Subject: =?ISO-2022-JP?B?GyRCJTUlViU4JSclLyVIJE4lRiU5JUgkRyQ5GyhC?= わざわざ Subject: というヘッダを含めて add_encode_word 関数に渡している理由は、メールの場合は Subject: ヘッダに日本語が来る場合、Base64 でエンコードするにしても 1行は 76バイト以内と決まっているためで、この 1行とは、ヘッダ名の Subject: 自体の文字数（9バイト）を勘案する必要があるためだ。
メール送信時に日本語をサブジェクトに書いて送るには、この部分は Base64 にエンコードした JIS でなければならない。要は、見た目が Subject: =?ISO-2022-JP?B?GyRCJTUlViU4JSclLyVIJE4lRiU5JUgkRyQ5GyhC?= のようにBase64 でエンコードされていることである。 それでは Perl でサブジェクトを Base64 処理してメールを送るにはどうしたらいいだろう？ズバリ、「Base64エンコード・デコードする」が詳しい。より具体的には、リンク先のページを少し下にいったところの、add_econde_word という関数である。しかしこのモジュールは jcode.pl を使う。 Perl 5.8 以上であれば、use Encode; とできそうだが、このモジュール、個人的にはあまり完成度が高くないと思っている。完成度なら Unicode::Japanese の方がスマートだし使いやすい。従って以下にjcode.pl の部分を、Unicode::Japanese で置き換えた例を示す。 使用するクラス use Unicode::Japanese; use MIME::Base64;
#!/usr/bin/perl

use Unicode::Japanese;
use MIME::Base64;

sub add_encode_word {

    my($str, $line) = @_;
    my $result;

    my $ascii = '[\x00-\x7F]';
    my $twoBytes = '[\x8E\xA1-\xFE][\xA1-\xFE]';
    my $threeBytes = '\x8F[\xA1-\xFE][\xA1-\xFE]';

    # この次の while 以下は EUC の文字列を対象に処理することになっているため
    $str = Unicode::Japanese->new($str, 'auto')->euc;

    while (length($str)) {
        my $target = $str;
        $str = '';
        if (length($line) + 22 + ($target =~ /^(?:$twoBytes|$threeBytes)/o) * 8
            > 76) {

            $line =~ s/[ \t\n\r]*$/\n/;
            $result .= $line;
            $line = ' ';
        }

        while (1) {

            # EUC を JIS に直す
            $target = Unicode::Japanese->new($target, 'euc')->jis;

            my $encoded = '=?ISO-2022-JP?B?' .
            encode_base64($target, '') . '?=';
            if (length($encoded) + length($line) > 76) {
                $target =~ s/($threeBytes|$twoBytes|$ascii)$//o;
                $str = $1 . $str;
            } else {
                $line .= $encoded;
                last;
            }
        }
    }
    $result . $line;
}

print add_encode_word('サブジェクトのテストです', 'Subject: ');

1;
これを実行すると、以下の文字列が得られる。 Subject: =?ISO-2022-JP?B?GyRCJTUlViU4JSclLyVIJE4lRiU5JUgkRyQ5GyhC?= わざわざ Subject: というヘッダを含めて add_encode_word 関数に渡している理由は、メールの場合は Subject: ヘッダに日本語が来る場合、Base64 でエンコードするにしても 1行は 76バイト以内と決まっているためで、この 1行とは、ヘッダ名の Subject: 自体の文字数（9バイト）を勘案する必要があるためだ。
Posted on 2006-07-23 by yas |

ケータイサイト構築のポイント

以下に、ケータイのサイトを開発する上で、ケータイならではの考慮すべきポイントを簡単に挙げてみた（リンクはこのサイト内での技術情報）。
  1. ケータイからサーバに送られてくる、CGI 環境変数の UserAgent の種類（ブラウザ名）
  2. 各ケータイキャリア毎の IP アドレス（PC と連携するときに、ケータイからサイトにアクセスしてきたか、PC からアクセスしてきたかサーバ側で判別するのに必要）
  3. 各ケータイの機種ごとの画面サイズ（特に横幅、これは最近の機種であれば UserAgent から取得できる）
  4. サポートする画像形式（JPEG / PNG / GIF）
  5. 1 画面の最大受信サイズ（バイト数）
  6. 機種ごとに使えるカラーの違い
  7. 各キャリアの絵文字の違い（同一キャリアだとしても、ケータイの世代ごとに使える絵文字が違います）
  8. 各キャリアのメールアドレス体系（iモード / i-mode メールは RFC に準拠していません）
  9. 使える文字コード（シフトJIS、UTF-8 など）
  10. 使える文字の種類（全角、半角）
  11. ケータイのキーパッドでも入力しやすくする工夫（PC にはない、アクセスキーの考え方のこと）
  12. ケータイネイティブ機能との連携（mailto: でメーラーが起動するとか、Java アプリが起動できるとか、tel: で電話の発信ができるとか）
  13. 公式サイトと勝手サイトの考え方、取得できる情報の違い
  14. セッション管理（ケータイは基本的に cookie が使えないから）
最近は、パケ放題などのプランが出てきたので以前ほどは、ページ内のパケットを減らす努力（改行はケータイに送らない、コメントは入れない、など）はしなくてもよくなってきたのではと思う。 このノウハウは、拙作の 「ケータイをシステム手帳にバージョンアップする」 サイト i-Services の構築から得られたノウハウである（このサイトのメインのターゲットはケータイだが、ケータイと PC 両方からアクセスできるように作ってあるので、両方で試してみて欲しい）。ノウハウとしては、かなり凝縮されている。
以下に、ケータイのサイトを開発する上で、ケータイならではの考慮すべきポイントを簡単に挙げてみた（リンクはこのサイト内での技術情報）。
  1. ケータイからサーバに送られてくる、CGI 環境変数の UserAgent の種類（ブラウザ名）
  2. 各ケータイキャリア毎の IP アドレス（PC と連携するときに、ケータイからサイトにアクセスしてきたか、PC からアクセスしてきたかサーバ側で判別するのに必要）
  3. 各ケータイの機種ごとの画面サイズ（特に横幅、これは最近の機種であれば UserAgent から取得できる）
  4. サポートする画像形式（JPEG / PNG / GIF）
  5. 1 画面の最大受信サイズ（バイト数）
  6. 機種ごとに使えるカラーの違い
  7. 各キャリアの絵文字の違い（同一キャリアだとしても、ケータイの世代ごとに使える絵文字が違います）
  8. 各キャリアのメールアドレス体系（iモード / i-mode メールは RFC に準拠していません）
  9. 使える文字コード（シフトJIS、UTF-8 など）
  10. 使える文字の種類（全角、半角）
  11. ケータイのキーパッドでも入力しやすくする工夫（PC にはない、アクセスキーの考え方のこと）
  12. ケータイネイティブ機能との連携（mailto: でメーラーが起動するとか、Java アプリが起動できるとか、tel: で電話の発信ができるとか）
  13. 公式サイトと勝手サイトの考え方、取得できる情報の違い
  14. セッション管理（ケータイは基本的に cookie が使えないから）
最近は、パケ放題などのプランが出てきたので以前ほどは、ページ内のパケットを減らす努力（改行はケータイに送らない、コメントは入れない、など）はしなくてもよくなってきたのではと思う。 このノウハウは、拙作の 「ケータイをシステム手帳にバージョンアップする」 サイト i-Services の構築から得られたノウハウである（このサイトのメインのターゲットはケータイだが、ケータイと PC 両方からアクセスできるように作ってあるので、両方で試してみて欲しい）。ノウハウとしては、かなり凝縮されている。
Posted on 2006-03-20 by yas |
123次 ›最終 »