MAIL RFCs – ttkzw's siteRFC-MAIL.pdf (ODF) - MAIL RFCs (2017-07-02) (c) 2014-2017 Takashi Takizawa Mail RFCs by https://emaillab.jp/mail/mail-rfc/ is licensed under a Creative Commons Attribution 4.0 International License.
ヘッダあれこれ
前回はテキスト・メールの歴史や書式について解説しました。今回はヘッダ中のフィールドの意味や使用方法、そしてよく見受けられる誤解などについて解説していこうと思います。これはインターネット・マガジンに執筆した原稿を元にしています。紙面の関係上削られた部分も残っていますので、既に同誌を読んで下さった方にも役にたつかもしれません。:-) インターネットとプロトコル インターネットはすべての人が活動できるオープンな世界です。この特徴はインターネットのルールすべてが話し合いによって決定され、公開されていることが根底となって支えられています。インターネットでは、データの送受信方法やデータの書式などの取り決めも含む、技術的なルールをプロトコルと呼びます。 プロトコルは、RFC(Request For Comments)という通し番号のついたオンライン・テキストとして公開されています。その名前が示すように、
ブログのヘッダーを春モードに変更しました
新潟県南魚沼市はすっかり春になり桜の開花がどんどん進んでいますが、このブログのヘッダー画像は駒ケ岳の雪景色のままでしたので、春らしく桜のヘッダー画像に差し替えてみました。 また、今までは画像編集ソフトを使ってブログタイトルが表示される位置に枠を合成したものをヘッダー画像として使用していましたが、ヘッダーの差し替えのたびに枠を合成するのは手間がかかるので、今回からスタイルシートを使って枠を表示するやり方に変更しました。 枠を表示するためにスタイルシートに追加したのは以下の行です。 box-shadow: 0px 0px 10px #999; 指定内容の説明は以下の通りです。 1番目の 0px ：右方向(x方向)にどれだけ影をずらすか 2番目の 0px ：下方向(y方向)にどれだけ影をずらすか 10px ： 影をどれだけぼかすか #999 ： 影の色 ちなみに、Internet Explore
SwiftMailerでJIS(iso-2022-jp)のメールを送る件 - uzullaがブログ
メールフォーマーとしては「そろそろUTF-8で受信できないメーラーは絶滅したんじゃないか？」と度々おもいますが、思い出したようにお客様よりクレームがはいり、結局iso-2022-jpで送るように修正する事になります。 有象無象のうさんくさい古びたメーラーや、うさんくさい変換処理をおこなうレガシープロバイダのMTA相手にメールを送るなら、鉄板はいまだqdmailですが、流石にもうしんどい*1ので、SwiftMailerを使いたい、というのが正直な所ですね。 ２〜３年位前まではSwiftMailerはUTF-8以外は結構無理ゲーで、jisで送るのは結構面倒だったと記憶していますが（２年も前！というべき？）、最近はちゃんと対応され、楽になっています。 で、まあ、今日久々にSwiftMailerでjis対応したメールフォーム書こうとググったら、予想以上に昔の情報にばかり行き着いたので、メモです。
PHPのマルチバイト文字列関数で”ISO-2022-JP”, “JIS”, “ISO-2022-JP-MS”の違い | おふろめ
PHPのマルチバイト文字列関数で”ISO-2022-JP”, “JIS”, “ISO-2022-JP-MS”の違い PHP5.2.1ぐらいから”ISO-2022-JP-MS”というのも使えるそうなので”ISO-2022-JP”,”JIS”とどう違うか試してみました。 <?php /* UTF-8からISO-2022-JP, JIS, ISO-2022-JP-MSに変換してみる */ setlocale( LC_ALL, 'ja_JP.UTF-8' ); /* ダメ元で☎ ☃なども */ $str = 'ｱｲｳｴｵ ㈱ ㈲ ① ② Ⅰ Ⅱ ℡ ㎏ ㎎ 﨑 髙 神 ☎ ☃'; header( 'Content-Type: text/plain; charset=ISO-2022-JP' ); printf( "%sn", 'PHP' . PHP_VERSION ); $encodings =
mb_convert_encodingのJISとISO-2022-JP | UCWD-Studio
知り合いが勤めている会社が運営するASPサービスの機能追加や保守をお手伝いする仕事が最近入りまして、ちょっとバタバタしていました。ら、ブログの投稿間隔が結構空いてしまいましたね。 そのASPサービスは主にPHPで作成されているのですが、そのサービスの要改善点の一つに、機種依存文字が含まれたテキストをメール送信した際に機種依存文字が文字化けするという、まぁありがちな問題が含まれていたので、ちょっと調べてみて見つけた記事です。 れぶろぐ – [PHP] mb_convert_encoding 関数の ISO-2022-JP と JIS の違い mb_convert_encoding() 関数でエンコーディングを指定する際、ISO-2022-JP と JIS では意味が違うというのはご存知でしょうか？ PHP のソースコード (mbfilter_jis.c) を見てみると、それぞれのエンコーディ
mb_convert_encodingのautoが危険な理由 - Qiita
mb_convert_encoding ( string $str , string $to_encoding [, mixed $from_encoding ] ) は文字エンコーディングを変換する関数です。 mb_convert_encodingに潜む問題 第3引数の $from_encoding には変換前の文字エンコーディング名を指定しますが、ここを"auto"と指定しておくと、環境によっては Warning: mb_convert_encoding(): Unable to detect character encoding のようなエラーが発生し、文字エンコーディングの変換が失敗する場合があります。 ですので、"auto" は極力使わず、文字エンコーディングを指定することをおすすめします。 autoとphp.iniの依存関係 なぜこのようなエラーが発生するかというと、autoは
Docs | ZiSTA
これまでなんとなくの理解で使ってきたPHPで日本語のメールを送る方法についてまとめてみます。設定を正しく理解して日本語のメールが文字化けせずに送信できるようにします。 日本語のメールを送信するサンプルコード $to = 'to@example.com'; $from = 'from@example.com'; $subject = "日本語の件名"; $body = "日本語の本文です"; $header = "From:".$from; mb_send_mail($to,$subject,$body,$header); このシンプルなコードで文字化けしないメールを送る事が出来ます。しかし、このコードを見て次のような疑問が生じると思います。 文字コードの指定が全く無い どの文字コードでメールが作成されるのか？ サンプルコードで文字化けしない設定 実はこのサンプルコードで文字化けする可能性が
インターネットメールの基礎
まずメールそれ自体です。 メールは基本的にはテキストファイルであり、ヘッダ (header) と ボディに分かれています。ヘッダの書式は規格がありかなり厳密に 決められていますが、ボディにはありません。たとえば以下が生の メールの例です。 Return-Path: <ruby-list-admin@ruby-lang.org> Received: from helium.ruby-lang.org (localhost [127.0.0.1]) by helium.ruby-lang.org (Postfix) with ESMTP id 4EEF9165; Wed, 12 Dec 2001 07:05:58 +0900 (JST) Received: from doraemon.edit.ne.jp (doraemon.edit.ne.jp [210.141.234.1]) by hel
メールヘッダの一覧
メール転送時に転送者アドレスを含める。この場合、FromはオリジナルのFromのままになる。ただし、あまり実装されている例はないようだ
RFC 2045(対訳)多目的インターネットメール拡張 パート1 - RFCの部屋
Network Working Group Request for Comments: 2045 Obsoletes: 1521, 1522, 1590 Updated by: 2184, 2231, 5335, 6532 Category: Standards Track N. Freed Innosoft N. Borenstein First Virtual November 1996 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [多目的インターネットメール拡張] (MIME) パート1: インターネットメッセージ本文のフォーマット This document specifies an Internet standards track protocol
Multipurpose Internet Mail Extensions - Wikipedia
Multipurpose Internet Mail Extension（多目的インターネットメール拡張）は、規格上US-ASCIIのテキストしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格である。通常はMIME（マイム）と略される。RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289[1]、RFC 2049 で規定されている。 概要[編集] インターネットでメールの書式を定めている RFC 5322 (旧 RFC 822、RFC 2822)では、英数字といくつかの記号を7 ビットで表現する「US-ASCII」と呼ばれる文字コードを利用し、1行あたり1000 バイト(改行を含む)のテキストデータしか許していない。そのため、規格に不適合になるような長い行、US-ASCIIだけで表現できない文字や、バイナリデー
転職Q&A「【ビジネスマナー】「御社」「貴社」どちらを使えばいいの？」｜【エンジャパン】のエン転職
応募先の企業を呼ぶ際、「御社」「貴社」どちらを使った方が良いといったことはありますか？ また、一般的な企業でない場合（銀行や自治体など）もこの呼び名を使ってよいものでしょうか。何か適切な呼び方があれば、ぜひ教えてください。 口頭では「御社」、書面上やメールでは「貴社」として使い分けると良いです。それぞれ「おんしゃ」「きしゃ」と読みます。 また、応募先をどのように呼ぶのかについては、業種ごとに下記にまとめてみましたので、ぜひご参考にしてください。 業種 口頭上の呼び名（書面上の呼び名） ========================================== 一般企業 御社（貴社） 病院 御院（貴院） 協同組合 御組合（貴組合） 銀行 御行（貴行） 信用金庫 御庫・御金庫（貴庫・貴金庫
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFCヘッダの必須項目
http://www.cpa-lab.com/tech/0153
メールにかけられた呪文「MIME〜前編」
メール例文.com【ビジネスメール書き方文例】