GoogleAnalyticsは携帯では利用できません。これは、Javascriptを使って計測サーバに画面表示情報を送信しているためです。

ですが、携帯からのアクセス時にサーバから直接HTTPリクエストを送信すれば、アクセス数を計測可能になります。しかし、この方法はアクセス数の多いサーバですと、サーバ負荷が増大するのであまりオススメできません。

秒間1000アクセス以上ある場合は、Googleへ携帯端末からアクセス情報を送るためのimgタグを自動生成する方法が望ましいです。

 <%= this.GetGoogleAnalyticsImageTag( "UA-0000-00", "your.domain.mobi" ); >
<script runat="server">
    /// <summary>
    ///
    /// </summary>
    /// <param name="utmac">登録番号 UA-XXXXX-XXXX</param>
    /// <param name="utmhn">ドメイン</param>
    public string GetGoogleAnalyticsImageTag( string utmac, string utmhn ) {
        Random rand = new Random( (int)DateTime.Now.Ticks );

        long win_time = DateTime.Now.ToFileTime();      // 現在時刻
        long unix_time = ( win_time - 116444735995904000 ) / 1000000;   // FileTimeからUnixTimeに変換
        string today = unix_time.ToString();
        string referer = "-";
        if( Request.UrlReferrer != null ) {
            referer = Request.UrlReferrer.AbsoluteUri;
        }
        string utmp = Request.Url.AbsoluteUri;

        string utmn = rand.Next( 1000000000, 2147483647 ).ToString();
        string cookie = Session.SessionID;
        string random = rand.Next( 1000000000, 2147483647 ).ToString();

        string uservar = "-";

        string useragent = "Unknown";
        if( Request.UserAgent != null ) {
            useragent = Request.UserAgent;
        }

        string requrl =
  "http://www.google-analytics.com/__utm.gif?" +
   "utmwv=1" +     // version
            "&utmn=" + utmn +  // 複数送信のブロック
            "&utmsr=-" +
   "&utmsc=-" +
   "&utmul=-" +
   "&utmje=0" +
   "&utmfl=-" +
   "&utmdt=-" +    // ページタイトル
            "&utmcs=-" +    // Character Encoding           
            "&utmhn=" + utmhn +
   "&utmr=" + referer +
   "&utmp=" + utmp +
   "&utmac=" + utmac +
   "&utmcc=__utma%3D" + cookie + // 端末識別
            "." + random + //
            "." + today + // 初回訪問時刻
            "." + today + // 前回訪問時刻
            "." + today + // 現在時刻
            ".2%3B%2B__utmb%3D" + cookie + // 下位互換性維持？
            "%3B%2B__utmc%3D" + cookie +  // 下位互換性維持？
            "%3B%2B__utmz%3D" + cookie +  // 下位互換性維持？
            "." + today +
   ".2.2.utmccn%3D(direct)%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmv%3D" + cookie +
   "." + uservar + "%3B";  // user defined variable          

        return string.Format( @"<img src=""{0}"" width=""1"" height=""1"" />", requrl );
       
    }
   
</script>
 

イメージタグを出力するので、SSLページでは計測できません。SSLページでの計測は、やはりサーバから直接Googleの計測サーバにデータ送信するしかありません。

昨年あたりいくつかのWebサービスが発表されてから国内でも使われる事例が増えてきました。伊藤 将雄さんのSimple APIを先駆けに、いくつも提供されています。Webページスナップショット比較サイト、キャプチャを極める完全ガイド

実際にだしてみるとこんな感じです↓(By HeartRails)

Webページを画像やPDFとして変換する機能への需要は多くあります。外部ページへのリンクにマウスを合わせると飛び先のサムネイルが表示されるなどは、良い使い方だとおもいます。検索エンジンの結果にサムネイルを使っている場合もあります。

動的にリンク先を生成するWebアプリケーションの場合、任意のWebページのスナップショットをプログラムでリアルタイムに生成する必要があります。外部のWebサービスを使うのでは少し不安になります。プログラマであれば、自前プログラムからWebページサムネイルを生成できるようにしたくなります。

Webページサムネイルのプログラム開発アプローチは3通りあります。

方法１
正攻法は、HTMLをPersingして、レンダリングする方法です。ゼロからHTMLレンダリングエンジンを開発するのは、ワクワクと胸が躍ります。しかし、サムネイルを作成するためにだけHTMLレンダリングエンジンを自製してしまうのは、モッタイナイですよね。ですので、GPLで公開されているFireFoxのGecko HTMLレンダリングエンジンを再利用する方法があります。ゼロからスタートしても3ヶ月くらいあれば開発できるでしょう。

方法2
もっと手を抜く方法は、IEコンポーネントを再利用することです。.NetであればWebBrowserコントロール(実体はIEのCOMオブジェクト)を使う方法です。Microsoft社製ですのでソースコードは開示されていませんが、IEのほとんどの機能はCOMインターフェイスを通じてプログラムから制御可能です。パフォーマンスを要求しなければ1週間程度で開発できます。

方法3
さらに手を抜く方法としては、コマンドラインで動くWebページキャプチャツールを使う方法です。例えば、CrenaHtml2Jpgやurl2jpgなどです。こちらで実装した方がいますが、毎分10ページ程度だそうです。これなら半日で作れますね。url2jpgは方法2で作られているので、実際は方法2の手抜きバージョンですね。

ちなみに、HeartRailsでは方法1(Embedding Mozilla)を採用しているようです。

私は、方法2を試してみました。まだ、安定していないのでアプリを公開しませんが、単発で動作させるのは問題ないですが、マルチスレッドで動作させると落ちます。

IEのCOM周りにRe-entrantになっていない部分があるようで、手がでません。IE６、IE7と試してみましたがエラーがでるので、根本的にSTAモデルに対応してない資源管理している可能性があります。マルチプロセスでの処理はまったく問題ないので、どこかスレッドもでるがおかしそうです。 
 

メール送信に利用するSMTPサーバがPOPBeforeSMTPで認証をしているケースが少なくありません。

この場合、POPサーバに対して認証を実施する必要がありますが、Microsoft .NetのSystem.Net.MailはSMTPClientのみで、POPClientがありません。

TCPClientを使って直接POPサーバにメッセージを送信してもよいですが、POPClientの認証ライブラリがほしいところです。

TKMP.dllを使えば解決できるのですが、GPLでしたので再配布する目的では利用できません。

アジルテックでは、自前のPOPClientを利用しています。非商用利用向けにβ公開していますので、ご利用ください。

標準の .Net Frameworkの中にQRコードを生成するライブラリがありません。

最近ではWebサービスでQRコードを生成してくれるサービスもありますが、QRコードの生成機能などは外部サービスを使うよりも、自前のサーバで生成したほうがサーバの信頼性が高まります。

世にあるQRコード生成ライブラリをまとめてみました。いくつも製品・フリーソフトがあるので適切なものを選んでください。 

まとめ：

個人で利用するならばQRGenかQR_Encodeがオススメです。Webアプリケーション用の商用ライセンスが必要な場合は、QRGenをご購入を検討ください。

先日、RFC違反のメールアドレスに関する記事を書きましたが、ASP.NETのライブラリはGlobal基準(またはMicrosoft基準)のため、ガラパゴス進化をしている日本のネット環境と乖離していることがあります。

System.Net.Mailはその中でも際立っていて、海外ではUTF-8 ＆ Qエンコードが主流なため、国内のShift-JIS ＆ Bエンコードという日本のネット環境に適合していません。

悩まれている方も多く、あちらこちらで記事があがっています。

System.Net.Mail問題その3(中の技術日誌)
せっかくsubjectとbodyにはエンコード方式の指定があるにもかかわらず、From, To, Cc, Bcc, ReplyToなどのこのMailAddressクラスにはエンコード方式を指定する方法がありません。

結局、MailAddressクラスのコンストラクタが「送り先氏名 <user@address.com>」という文字列を解釈して処理してくれるにもかかわらず、Qエンコーディングなため、自前でBエンコード処理をして2つ変数をとるコンストラクタ MailAddress( address, displayname) を呼ぶ必要があります。

string from_name = MyBEncode( "株式会社 アジルテック", enc );
string from_address = "user@address.com"; 
msg.To.Add( new MailAddress( to_address, to_name ) );

また、Subject, Bodyのエンコードを指定できますが、iso-2022-jpに指定しても、

Subject: =?iso-2022-jp?Q?=1B$B%5%V%8%'%/%H=1B(B1?=
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 8bit

出力はSubjectはQエンコードされ、BodyのContent-Transfer-Encodingは8bitエンコーディングです。

結局、せっかく自動処理してくれるSubjectもMailMessage.SubjectEncodingは未指定にし、自前でBエンコーディングをする必要があります。

Bodyを7bitにするには、Content-Transfer-Encodingについては、msg.HeadersにAddしても追加されず、AlternateViewを使って7bitエンコーディングを実現する必要があります。

追加されない：
msg.Headers.Add( "Content-Transfer-Encoding", "7bit" );

AlternateViewを利用する：
byte[] buf = enc.GetBytes( body );
MemoryStream mem = new MemoryStream( buf );
AlternateView alt_msg = new AlternateView( mem, new ContentType("text/plain; charset=" + enc.BodyName ) ); 
alt_msg.TransferEncoding  = TransferEncoding.SevenBit;

これまでは上記の方法でも、「content-transfer-encoding: 7bit」と出力するところが、「content-transfer-encoding: sevenbit」となっていたため、正しく送信できなかったのですが、.Net Framework 2.0 SP1で、「[FIX] System.Net.Mime 名前空間または System.Net.Mail 名前空間を使用する Visual Studio 2005 プログラムを実行すると、TransferEncoding プロパティの値が正しくないことがある」修正が含まれたので、SP1以降は送信するこができます。

 参考：
 [.NET 2.0]日本語(ISO-2022-JP) を Content-Transfer-Encoding: 7bit で送信する方法

上記の方法で大部分は問題なく動作するが、まだ問題が残っています。RFC 2047に記述のあるエンコード行の76文字改行規制です。

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
複数の行からなるヘッダフィールドの長さに制限はないが、1つ以上の
  'encoded-word' を含むそれぞれの行は、76文字に制限される。

改行いれた文字列を渡すと、MailMessageのSubjectプロパティもMailAddressクラスコンストラクタもエラーを発生します。

2バイト文字だと40文字越えるとこの制限に抵触します。

=?iso-2022-jp?B?GyRCJTUlViU4JSclLyVIRDkkJCU1JVYlOCUnJS8lSCRAJEgkSSQmJEokayRzJEckNyRnJCYkKyRKIzEjMiMzIzQjNSM2IzcjOCM5IzEjMiMzIzQjNSM2IzcjOCM5GyhCQUJDREVGRxskQiQiJCQkJiQoJCokKyQtJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEghIktcRnwkT0AyRTckSiRqGyhC?=

しかし、上記のような長いエンコード文字列を渡しても大丈夫なSMTPサーバ、メールクライアントも多いようです。Au, Softbankは76文字で区切らなくても表示できる端末があるので、少なくとも両社のSMTPサーバは受け取ります。(ただし、端末によっては表示されない可能性あり）

まとめ：

RFCの作法は守りたいという方は、Socketから直接SMTPサーバと通信してください。

[追記 2008/11/20 ] 弊社より、サブジェクト文字化けとRFC非準拠アドレスに対応したSMTPClientを公開しました。現在、β公開につき無料で利用できます。ぜひお試しください。