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

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

まとめ：

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

System.Net.Mail.MailAddressクラスは携帯各社が許可している、RFCに準拠しないメールアドレスを渡すことができません。

MailAddress address = new MailAddress( "test...@docomo.ne.jp" );

上記のようなメールアドレスを渡そうとするとFormatExceptionが発生してしまいます。

System.FormatException はユーザー コードによってハンドルされませんでした。
  Message="指定された文字列は、電子メール アドレスに必要な形式ではありません。"
  Source="System"
  StackTrace:
       場所 System.Net.Mime.MailBnfHelper.ReadMailAddress(String data, Int32& offset, String& displayName)

原因：

System.Net.MailAddressがRFCで定められているよりも厳しくメールアドレスの形式をチェックしているため。

実はこのようなRFC準拠していないメールアドレスであっても「"test..."@docomo.ne.jp 」とアカウント部分をエスケープすることでRFC準拠として扱えるのですが、MailAddressクラスはFormatExceptionを発生させます。

解決方法：

ASP.NET開発で携帯メールアドレスを扱うことは多々あり、「RFC非準拠アドレスにメール送信できないのは仕様です」といっても発注元が検収してくれません。

そこで、簡単な逃げ道としては.Net Framework 1.1で使われていたSystem.Web.Mailを利用する方法があります。

MailMessage msg = new MailMessage();
msg.To = "test...@docomo.ne.jp";

MailMessageクラスのToプロパティはstring型でメール形式をチェックしません。どんな文字列でも渡すことができます。また、OSが日本語環境であれば、デフォルトのエンコーディングはiso-2022-jp かつ Bエンコードになるので、特に設定せずとも各携帯キャリア対応です。

いいことずくめに思えますが、下記のような問題点があります。

1. 実行環境依存が発生する
2. CDOモジュールが.Netプログラマにわかり難い
3. HTMLメール送信機能が不十分
4. SMTP/SSLが使えない

ひとつひとつ詳しく解説します。

1 実行環境依存が発生する

System.Web.Mailのメール送信はMicrosoft CDO for Exchange 2000のモジュールを利用しているため、実行環境によって挙動が変化します。本番環境でモジュールがなくて動かない・・・ということもありえます。

アプリケーションの実行アカウント権限がCDOオブジェクトにアクセスできないとアウトです。あちらこちらの掲示板で質問があがっては未解決という状態です。

特定のVersionのVisual Studioをインストールしたり、Exchange Serverをインストール＆アンインストールしていると症状がでるといった報告もあります。

 参考：
 [MSDN] CDO.DLL ファイルが存在しない

2 CDOモジュールが.Netプログラマにわかり難い

この自由度の高かった1.1のSystem.Web.Mailが2.0でSystem.Net.Mailに置き換えられているのは、基本的にSystem.Web.MailはExchangeモジュールの.Net用ラッパークラスにすぎないためです。細かい制御は全て、CDOに対するメッセージを付加する必要があります。たとえば、portを25番以外に変更する場合には、MailMessageのFilesプロパティにCDOの設定をメッセージとして追加する必要があります。

msg.Fields[
"http://schemas.microsoft.com/cdo/configuration/smtpserverport"] = 25;

また、CDOのエラーメッセージが不親切で、原因の切り出しがし難い点があります。

 参考：
 「CDO.Message」を作成しなかったための」エラー メッセージのトラブルシューティング方法

3 HTMLメール送信機能が不十分

msg.BodyFormat = MailFormat.Html;

上記のプロパティを設定することでHTMLメールを送信することができるのですが、機能的に不十分です。携帯のデコメール等はimgタグで指定するsrc属性を外部リソースを指定することができません。そのため、添付ファイルを表示するためにContentIdを指定したいのですが、System.Web.Mail.MailAttachmentにはContentIdを指定できません。をまた、HTMLメールを指定した際の、Textメールは自動生成なので、HTMLとTextメールをそれぞれ整形して指定できません。

 参考：
 DoCoMo デコメ
 KDDI デコメ
 SoftBank

4 SMTP/SSLが使えない

SMTP/SSLをサポートしていないようです。CDOの設定を探せばあるのかしれませんが、ドキュメントを発掘できません。SMTPAuthはサポートしているのですが、平文 or NTLM(=CRAM-MD5 )となり、ベストエフォート設定はできません。ちなみにSMIME署名はCAPICOMを使うのが常道なので、1.1、2.0いずれのVersionでもサポートしていません。

 参考：
 [Microsoft]System.Web.mail を使用している 有効 SMTP 認証の方法
 [MSDN] リファレンス http://schemas.microsoft.com/cdo/configuration/

総括：

「入会案内程度のメールであればSystem.Web.Mailは利用に耐える」、セキュリティに執着しない顧客で、メルマガのようにHTMLメールが不要なケースであればSystem.Web.Mailでも十分です。しかし問題点1で指摘したように、テスト環境では動いてたものが、本番環境によってCDOモジュールが見つからないというエラーがでて顧客のクレームを浴びることもありえます。必ず、CDOモジュールが動作するかミニプログラムを本番サーバで動かして確認してください。

弊社ではSMTPは、System.Net.MailもSystem.Web.Mailのどちらも使うことを辞め、自前で実装したSMTPクライアントを利用しています。顧客からの要望に細かく対応できるので便利です。

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

例：
ASPXファイルの記述
<asp:TextBox istyle="3" ID="TB_Mail" runat="server" />

原因：
 Up.BrowserのVersion6以降では、HTMLレンダリングにSystem.Web.UI.XhtmlTextWriterが用いられているため、istyleなどの非正則属性を除去してしまう。

対策：
 Html32TextWriterもしくはChtmlTextWriterを利用するように設定する。
VS2005以降で開発しているのでしたら、App_Browsersフォルダを追加して、KDDI AU用の定義ファイルを作成してください。

例： <browsers / / /> <browser refid="Up" / / /> <capabilities> <capability name="supportsInputIStyle" value="true" /> </capabilities> <controlAdapters markuptextwritertype="System.Web.UI.ChtmlTextWriter" /> </browser> </browsers>

デフォルト定義されている%Windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\ 内部のopenwave.browserファイルの407行目を直接編集した場合は、コマンドプロンプトから「aspnet_regbrowsers.exe - i」を実行してください。

<controlAdapters markupTextWriterType="System.Web.UI.XhtmlTextWriter" />
↓変更
<controlAdapters markupTextWriterType="System.Web.UI.ChtmlTextWriter" />

参考情報： 

 MSDN ブラウザ定義ファイルのスキーマ

      <globalization requestEncoding="UTF-8" responseEncoding="UTF-8"/>

PC向けのサイトではなにも考えずにUTF-8でサイトを構築してもいいのですが、携帯向けサイトですと、SHIF-JISでエンコードする必要があります。

      <globalization requestEncoding="Shift-JIS" responseEncoding="Shift-JIS"/>

この場合、ASP.NETのサーバオブジェクトは、クライアントからのポストデータをShift-JISエンコードとして自動処理します。

単一のページで、PCと携帯の両対応を目論む方の中には、「PC向けにはUTF-8で、携帯向けにはShift-JISで表示したい」と考えるかもしれません。(迷信ですが、SEO的にUTF-8のほうが良いと言われているため)

この場合、globalizationではUTF-8を指定しておき、UserAgentから携帯電話端末を識別して、Responseオブジェクトに1行追加するだけでShift-JISにすることができます。

      Response.ContentEncoding = System.Text.Encoding.GetEncoding( "Shift-JIS" );

ただし、これを行うと、Softbank＆Vodafone端末で文字化けがおこります！

理由は、.NET FrameworkはDoCoMoとKDDIとJ-PHONEはご存知なのですが、「Vodafone？Softbank？だれそれ？」状態です。ですので、browser情報を追加する必要があります。

ASP.NETフォルダの追加からApp_Browsersフォルダを追加して、その中にVodafoneとSoftbankのための情報を追加してください。特に重要なのは下記の1行です。

        <capability name="preferredResponseEncoding"           value="shift_jis" />

アプリケーション単体ではなく、サーバ自体に設定を追加する場合は、こちらの記事を参考にしてください。

以上、ASP.NET 2.0の話です。ASP.NET 1.1の環境ではBrowser Capsで対応してください。

その他資料：

MSDNブラウザファイルのスキーマー

Content-Disposition: attachement; filename=<ファイル名>

しかし、ダウンロードファイルに日本語や記号を含む場合、なにもしないと文字化けが発生します。
これは、各社のブラウザがContent-Dispositionのフォーマットに関する実装をRFC通りに実装していなため、英語圏以外で問題が発生しています。

ファイルをダウンロードする ASP.NET Web ページで日本語ファイル名が文字化けする
原因
Internet Explorerでは、Content-Disposition ヘッダが送信された場合、送られてきたコンテンツをそのままブラウザで開かずにファイルダウンロードダイアログを表示するようになっています。その際にこのヘッダの filename パラメータを利用している場合、このパラメータで渡されたファイル名をファイルの保存時の既定のファイル名にします。ただし、クライアントコンピュータのロケールを日本語にしている場合、Internet Explorer ではこのパラメータで渡された文字列 (ファイル名) を Shift-JIS でエンコードされているものとして処理します。
また、ASP.NET および .NET Framework では、構成ファイル globalization エントリ responseEncoding 属性の設定に関わらず、HTTP ヘッダを UTF-8 でエンコードして送信します。Internet Explorer では、UTF-8 でエンコードされたファイル名を Shift-JIS でエンコードされているものとして処理するため、ファイル名を正しく表示できません。
Content-Disposition ヘッダのパラメータの文字コードのエンコード方式に関しては、RFC2231 に基づくべきですが、現行の Internet Explorer はこのエンコード方式をサポートしていません。 RFC2231 につきましては、以下の URL をご参照ください。

Microsoftではファイル名をURLエンコードして回避するようにと記載していますが、これですとFireFoxなどほかのブラウザで文字化けをしてしまします。

ブラウザ毎にContent-Dispositionの記載を変更できるのであれば、IE向けにはURLエンコードをし、FireFoxにはなにもしないという対処もあります。

ASP.NET環境であれば下記の対応をするのがもっともシンプルかとおもいます。

Response.HeaderEncoding  = System.Text.Encoding.GetEncoding( "SHIFT-JIS" );

IE用に強引にSHIFT-JIS送信してあげればいいわけです。
ただし、これでは一部文字がまだ文字化けします。化けるのは2バイトコードで考えた場合、下位バイトが「５C」、「７C」の場合です。
「予 (0x975c)」→「誉 (0x975f)」　「表 (0x955c)」→「廟 (0x955f)」

これを避けるためには、該当する文字をURLエンコーディングしてあげます。(すべてURLエンコーディングしないのは、一定以上の文字列長になった場合にファイル名を省略するのを避けるためです)

そのほか参考情報

ダウンロード時に日本語ファイル名が文字化け

MSDNフォーラム日本語ファイルのダウンロードについて

FIX: ASP.NET で Response.Addheader 方法を使用する場合、応答ヘッダーが UTF-8 として常にエンコードされます。

.Net 1.1にはサービスパックがでています。

private void Page_Load(object sender, System.EventArgs e) {
               string filename="<Some Korean Characters>.txt";

               Response.ContentType = "text/plain";
               Response.Clear(); 
               byte[] buffer={65}; 
               Response.AddHeader("Content-Disposition","attachment;filename="+filename); 
               Response.BinaryWrite(buffer);
               Response.Flush();
               Response.End();
 }

本当にこれで文字化けしないのかは未確認です。
このFIXがあがったのと、前述の引用ページの日付をみるとこちらのほうが古いんですよね・・・。

(追記 2008/9/5)

文字化けとは別に、ファイル名が途切れる問題が存在します。

こちらが発生する原因は、IEではダウンロードファイルをキャッシュフォルダに一時保存するのですが、そのときに「フォルダパス名 + ファイル名」が255文字を越えると途中で途切れます。

C:¥Documents and Settings¥(ユーザ名)¥Local Settings¥Temporary Internet Files¥Content.IE5¥ｘｘｘｘｘｘｘｘｘ[0].zip

ユーザ環境によって発生条件が変わるのがいやらしい現象です。これといった解決方法はないので、あきらめて短めのファイルをアップ・ダウンするしかないのが現状です。