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.

UserAgent type that is, a Browser Name of CGI environments which is sent by a mobile phone to a web server.
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.
Screen Size of each mobile phone, especially the size of width, which would be found in a CGI environment UserAgent in the latest phones
Image Format such as JPEG, PNG and GIF supported by each mobile phone
Maximum Size of Receiving Bytes per a page
Difference of Handling Colors in each mobile phone
Difference of Smilies (Picture Icons) both in each mobile phone and operator
Name Convention of an E-mail Address in each operator (Japanese i-mode e-mail system violates RFC).
Available Character Set in each operator (Shift-JIS, UTF-8 in Japan)
Available Character Types in each operator (such as ZENKAKU, HANKAKU in Japan)
Available Input Method in each operator (Access-key concept in CHTML)
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)
Difference in between Official Sites and Unofficial Sites (The acquiring information is different)
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.

UserAgent type that is, a Browser Name of CGI environments which is sent by a mobile phone to a web server.
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.
Screen Size of each mobile phone, especially the size of width, which would be found in a CGI environment UserAgent in the latest phones
Image Format such as JPEG, PNG and GIF supported by each mobile phone
Maximum Size of Receiving Bytes per a page
Difference of Handling Colors in each mobile phone
Difference of Smilies (Picture Icons) both in each mobile phone and operator
Name Convention of an E-mail Address in each operator (Japanese i-mode e-mail system violates RFC).
Available Character Set in each operator (Shift-JIS, UTF-8 in Japan)
Available Character Types in each operator (such as ZENKAKU, HANKAKU in Japan)
Available Input Method in each operator (Access-key concept in CHTML)
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)
Difference in between Official Sites and Unofficial Sites (The acquiring information is different)
Session Management because we cannot use cookie in i-mode phones

Posted on 2007-05-21 by yas |

Linux で、postfix を使ってイントラネットからメールを送信する方法

Fedora Core 6 の場合、デフォルトの MTA (Mail Transfer Agent) は sendmail となっている。で、実験用 Linux サーバをイントラネットに置いてメールを出そうとしたら、Connection Refused というエラーメールが返ってきてしまった。どうもイントラネットから外へのポート 25　がふさがっているから外部のホストにつながらないらしい。そこで sendmail の設定をいろいろと調べてはみたものの、やっぱり sendmail.mc とか sendmail.cf は呪いたくなります。結局挫折。今までの人生の中で何度か sendmail を設定する機会があったが、いずれもよくわからなかった。Fedora Core 6 の場合、デフォルトの MTA (Mail Transfer Agent) は sendmail となっている。で、実験用 Linux サーバをイントラネットに置いてメールを出そうとしたら、Connection Refused というエラーメールが返ってきてしまった。どうもイントラネットから外へのポート 25　がふさがっているから外部のホストにつながらないらしい。そこで sendmail の設定をいろいろと調べてはみたものの、やっぱり sendmail.mc とか sendmail.cf は呪いたくなります。結局挫折。今までの人生の中で何度か sendmail を設定する機会があったが、いずれもよくわからなかった。

Posted on 2007-02-02 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エンコード・デコードする（Perl メモ）

メール送信時に日本語をサブジェクトに書いて送るには、この部分は 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エンコード・デコードする（Perl メモ）

Posted on 2006-07-23 by yas |

Perl で、Base64 のファイルをデコードして元のバイナリファイルに戻す方法

メールに添付されてきた .pdf ファイルが巨大すぎてメールサーバによって分割されて自分のところに配信された結果、Base64 のデータがバラバラに届いたケースを考える。このような場合は Perl が活躍する。まず、バラバラになった Base64 のファイルは仕方がないのでエディタを使って手作業でくっつけて 1つのファイルにする。そのあと、以下のコマンドを実行すればよい。


使用するモジュール
use MIME::Base64;

perl -MMIME::Base64 -ne 'print decode_base64($_)' 
< くっつけたBase64ファイル名.txt > 出力ファイル名.pdf

（上は、すべて1行に書く）

MIME::Base64 - base64文字列のエンコードとデコード (perldoc.jp)

メールに添付されてきた .pdf ファイルが巨大すぎてメールサーバによって分割されて自分のところに配信された結果、Base64 のデータがバラバラに届いたケースを考える。このような場合は Perl が活躍する。まず、バラバラになった Base64 のファイルは仕方がないのでエディタを使って手作業でくっつけて 1つのファイルにする。そのあと、以下のコマンドを実行すればよい。


使用するモジュール
use MIME::Base64;

perl -MMIME::Base64 -ne 'print decode_base64($_)' 
< くっつけたBase64ファイル名.txt > 出力ファイル名.pdf

（上は、すべて1行に書く）

MIME::Base64 - base64文字列のエンコードとデコード (perldoc.jp)

Posted on 2006-06-24 by yas |

Requirements for Mobile Phones (English)

Linux で、postfix を使ってイントラネットからメールを送信する方法

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

Perl で、Base64 のファイルをデコードして元のバイナリファイルに戻す方法

本日の上位：

総合の上位：

最近の参照：