メルマガで一番手間がかかるのが、HTMLメール（※１）の準備ではないでしょうか？ ベビー服ネットショップ『べびちゅ』でも、2016年12月までのメルマガはHTMLメールが中心でした。 テキストメールは、HTMLメールを受信できない人や簡易な内容のメールを送る際に利用する補助的な位置づけでした。 しかし、2016年12月前半に配信した31回のメルマガでABテストを実施したところ、 平均クリック率（※２）がHTMLメール3.85％なのに対し、テキストメールは7.1％でした。 なんと、1.86倍です。 しかも、最も差が大きいメルマガで４倍以上の開きがありました。 みなさんも予想外だと思いますが、テキストメールのほうがHTMLメールよりクリック率が高いという結果が出たのです。 ※１ HTMLメールとは、メール本文をHTML言語で記述した形式のメールのことです。 フォントサイズを変更したり、レイアウ
前置き メールの決まり事って言っても「目上の人に対してお疲れ様です。」を言わない、「ちゃんと、冒頭で名乗る」とかそういうことじゃなく。。。 電子メールは1970年ごろに開発されてから色々と仕様をインターネットを作ってきた偉い人達があれやこれやと決めてきました。 その、仕様をちゃんと守ってメールを作りましょうね。という話を書きます。 一括送信ガイドライン - Gmail ヘルプ にも、そのことは明記されています。相変わらずごちゃごちゃと書いていますので、話を抽出すると。 RFC5322に従ってね HTML規格に従ってね メールには Message-IDを付けてね メールヘッダに Precedence: bulk って付けて一括送信メールって教えてね リンク先ページやメールの送信者を隠蔽しないでね 本文に関係のある件名を付けてね ドメインは正しく書いてね という感じです。 いつものように一つ一
Welcome to Go spin 123, silakan menggunakan tombol login untuk memasuki laman utama atau tombol livechat di bawah untuk menghubungi support 24x7 online setiap saat di Gospin123! Gospin123: Inovasi Program Pemerintah untuk Mengatasi Kemiskinan Melalui Game Online dengan Hadiah Tertinggi di Indonesia | Gospin 123 Pemerintah Indonesia meluncurkan Gospin123 sebagai inisiatif inovatif untuk mengatasi k
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
OS X 10.7 Lion以降のMailは、ケータイのアカウント宛にケータイのエンコーディングで絵文字を送ることができる（LionのMailはケータイと絵文字のやりとりができるよ！）。OS X 10.8 Mountain Lionでは、その仕様が変更された。良くなったのか、悪くなったのか。 下図の例では、LionもMountain Lionも、ドコモのアカウント（@docomo.ne.jp）に対して、太陽の絵文字をドコモのShift_JISで送っている。iモードにはないバラの絵文字がメッセージに含まれるとき、Lionはメッセージ全体をcharset=utf-8で送信する。太陽とバラの両方がメッセージに含まれる場合、Lionでは（バラを含むために）charset=utf-8となり、iモードにある太陽の絵文字まで「・」になってしまう。一方Mountain Lionは、iモードにはないバラの絵
これちょっとマズいんじゃないかなあ。 Kampa! の人である佐田さんが見つけて教えてくれたんだけど、 Facebook のメッセージは割と簡単に他人になりすまして送れるみたい。 以下、すべて送信者と受信者の自発的な協力を得て試してみた結果です。 起きること Facebook ではユーザーに @facebook.com のメールアドレスが与えられています。 個人ページが www.facebook.com/namaewo の人なら [email protected] という具合に。 そのアドレス宛にメールを送ると、 アドレスの所有者に Facebook 上のメッセージとして届きますね。 この時、そのメールの送信元メールアドレスが 別の Facebook ユーザーによって登録されているアドレスであった場合 Facebook では、そのユーザーから送られたメッセージとして扱われます。 電子
昨日のエントリ（「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ）読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね？ うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と？ いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ？ 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「･」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
前回の続き。やや細かい話になるが、SoftBank iPhoneのShift_JISによって具体的にどのような文字化けが引き起こされるかを見ていくこととする。 SoftBank iPhoneのMailは、Windows外字をcharset=Shift_JISで送信する。これを表示できるかどうかは受信側のメーラーによる*1。下図は、件名と本文に「iPhoneから①」と入力したメッセージをSoftBank iPhoneのMailから送信し、LionのMailで受信した例。MacのMailは（SoftBank iPhoneのMailとは逆に）charset=Shift_JISを比較的厳密に解釈し、「①」という「Shift_JISに含まれないはずの文字」が存在することで、そのメッセージをShift_JISとしてデコードするのをやめてしまう。その結果、英数字以外のすべての文字が化けている。このような
iPhone Mailで@me.comや@gmail.comなどの（@i.softbank.jp以外の）アカウントからプレーンテキスト（標準テキスト）のメッセージを送信すると、Windows外字はcharset=Shift_JIS（実際にはWindows-31J）で符号化される。 下図は、Windows外字の符号表。漢字に関しては、ピンク地と黄色地の領域が（レパートリも並び順もまったく同じで）重複している。 で、UnicodeをWindows-31Jに変換する際、iPhone Mailは、どちらの領域を使うのか。その選択によって、送信したメッセージをApple Mailで受信したときの化け方*1が変わってくる*2。 下図は、iPhone 4によるテスト結果。iPhone Mailの送信するcharset=Shift_JISのメッセージでは、色地の文字が使われるようだ*3。つまり、字種によっ
たとえば「あ〜」という件名のメールをMail 4.3（Mac OS X 10.6 Snow Leopard）で送信すると、U+301Cだったはずの「〜」がU+FF5Eに変わって届く件。 Mail 4.3は、Windows/Macでマッピングに揺れのある文字（下図）が含まれている件名を、UTF-8で送信する。このうちMac式のマッピングで使われる文字（黄色地）を自分宛に送信して受信すると、Windows式のマッピングで使われる文字（白地）に変わっている。テーブル変換の不要なはずのUTF-8で送信していながら符号位置が変わるというのが不気味だ。 送信済みメールボックスに残っているコピーを見ると、件名はISO-2022-JPで符号化されており、実際に送られたメールと一致しない。おそらく、一度Mac式のテーブルでISO-2022-JPに変換してから（この段階のものが、送信済みメールボックスのコピー
前回（iPadでHTMLメールを送信する方法）のコメント欄に思いつきで書いたことなのだけれど、悪くないやり方なんじゃないかという気がしてきたので、改めてやや詳しくメモしておく。 iPhone/iPadから送信したHTMLメールがWindowsメールやOutlookで化ける問題を回避するには、2つのアプローチが考えられる。1つ目は「HTMLメールを送らない」という方法。前回のコメント欄でTAMAさんが書かれているように、テキストを一度エディタにペーストした上で再度コピーしてMailに戻すことで、標準テキストのメッセージを送信することができる。 この方法は安全だが、ちょっと手間がかかる。個人的には、Macならこの程度の操作は苦にならないけれど、iPadでやるのは面倒だなあというかんじ。また、当然だが、HTMLメールを送りたいときには使えない。 というわけで、2つ目は「charsetを揃える」方
公式のマニュアルにそう書いてあるわけではないので自信がないのだが、iPhone/iPadのメールでは、作成中のメッセージに既存のドキュメントからテキストをコピーすると、HTMLメールとして送信されるようだ。プレーンテキストのメールから文字をコピーしただけでも、自動的にHTMLメールになる。そんなわけで、iPhone/iPadはHTMLメールを送信することが多い。 iPhone/iPadの送信するHTMLメールにはテキストパートとHTMLパートが存在する。そして、テキストパートのcharsetがISO-2022-JPである場合、HTMLパートはISO-2022-JPではなくUTF-8となる。下図は、iPadから送信したHTMLメールをSnow LeopardのMail 4.3で表示したもの。 下図は、そのソース。 で、このような（テキストパートとHTMLパートのcharsetが一致しない）メ
iPhoneから送信したメールの文字化けについて、ある程度のことがわかったので、まとめ。ただし、わたしはiPhoneを持っていない*1。ここに書くことは、限られたサンプルの観察から推定したものであることに留意していただきたい。 iPhoneのメールには下図のような種類がある。このエントリでは、@me.comや@gmail.comなどの「プロバイダメール」と@i.softbank.jpの「Eメール(i)」について検討する（以下、すべて標準テキストメールという前提で）。個人的には「プロバイダメール」というSoftBankの用語はどうもしっくりこないのだけれど、他に適当な呼称も思い浮かばないので、以下これを用いる。 まず、@me.comや@gmail.comなどのプロバイダメールについて。下図は、iPhone OS 3、iOS 4 for iPhone 、iOS 4 for iPod touch
前回のエントリで述べたように、Thunderbird 3とApple Mail 4.2は、ともにRFC 2231をサポートしているが、その方法に若干の違いがある。 長いファイル名をRFC 2231でエンコードする際、Thunderbirdは複数行に分割し、Apple Mailは分割しない。下図は、「あいうえおあいうえおあいうえお.png」というファイルを添付して送信した例。Apple Mailがエンコードしたfilenameパラメータには、（図ではウインドウの幅の制限により折り返し表示されているが）改行コードは入っていない。 RFC 2231で複数行にする方法が規定されている以上、1行あたりの文字数の制限が存在するものと思われる。以下に引用するRFC 5322の一節がそれだろうか。 Each line of characters MUST be no more than 998 chara
メールの添付ファイル名をめぐる問題について、Mac OS Xユーザの視点でまとめてみる。 添付ファイルを送信する際、その名前はどこに書かれるのか。RFC 2183では、添付ファイル名はContent-Dispositionフィールドのfilenameパラメータに記述することになっている。ただし今回調べたメーラーまたはメールサービスはすべて、filenameパラメータだけでなく、Content-Typeフィールドのnameパラメータにも添付ファイル名を記述する。後述するが、nameパラメータは互換用として機能している。 添付ファイルを送信する際、その名前はどのような方法でエンコードされるか。非ASCII文字列を添付ファイル名として扱う方法は、RFC 2231で定義されている。しかし、OutlookやWindows MailなどはRFC 2231をサポートしておらず、代わりにMIME Bエンコ
Mac OS X 10.6 Snow Leopardでは、Apple Mail（Mail.app）のテキストエンコーディングに関する仕様が変更された。下図は、Tiger、Leopard、Snow Leopardの違いをまとめたもの。検証に用いたSnow LeopardのMailはバージョン4.1（1076）。 TigerおよびLeopardのMailはcharset=CP932のメールを送信することがあったが（図、黄色地）、Snow LeopardではISO-2022-JPの範囲外の文字を含むメールのテキストエンコーディングは、基本的にUTF-8に統一された。この変更は歓迎できる。 ただし、半角カタカナは例外。Leopardでは半角カタカナは（それ以外の文字がISO-2022-JPの範囲内であれば）全角に変換した上でcharset=ISO-2022-JPで送信する仕様だった。Snow Le
Webページをメールクライアントソフトから閲覧できるサービス「WebToMail」を利用すれば、アクセスフィルターではじかれたページもテキストを閲覧できる。 職場のPCからWebサイトにアクセスしようとしたら、アクセス制限に引っかかって閲覧できなかった――なんて経験はないだろうか。オフィスのネットワークに導入するアクセスフィルターは、就業中に業務と無関係なサイトの閲覧を防ぐためのものだが、ときおりどうしても閲覧が必要なWebページまではじいてしまうことがある。 そんなときに利用したいのが、Webページをメールクライアントソフトから閲覧できるWebサービス「WebToMail」だ。 使い方は実にシンプル。閲覧したいページのURLをメールの件名にして、send@webtomail.co.ccというアドレス宛てにメールを送るだけだ。本文にテキストを記入する必要はなく、空でいい。 数分待つと、自分
メールフォームを作るのに大掛かりなアプリケーションは必要ない。個人的にはこうしたときにもっとも便利なのはPHPだと思う。手軽にWebアプリケーションが作成できるのが便利だ。 だが、単なるメールフォームではユーザの満足は得られない。ちょっと工夫したフォームこそ受けがいい。 今回紹介するフリーウェアはAjaxMail、Ajaxを使ったメールフォームスクリプトだ。 AjaxMailは日本人エンジニアのアプリケーションで、日本語が問題なく扱えるのが魅力だ。提供されるスクリプトも、シフトJIS、EUC-JP、UTF-8と各種エンコード向けが作られている。 Ajaxを使っているので、画面遷移がなくスムーズに操作できるのが魅力だ。郵便番号補完機能もあって、郵便番号を入力してフォーカスを移動すると、自動的に住所の文字列が入力される。入力エラーも画面遷移せずに評価されるので、ストレスが感じづらくなっている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
