インターネットでの日本語メール
インターネットでの電子メールのやりとりが標準化されたのは1982年ですが、この時の標準はASCII文字しかやりとりできないなど制約の多いものであったため、様々なローカル規格が生まれてしまいました。そこで、1992年に新しい標準規格であるMIME発表されます。これによって、インターネットのメールに新しい標準ヘッダ、バイナリのエンコードなどの新しい本文記述法などが加わりました。 さらに、MIMEの仕様に基づいて日本語を扱う方法が慶応大学の村井氏らによって発表されました。今日の日本語メールはこれらの仕組みに基づいてやりとりされています。 ※インターネットメールの仕組みや文字化けの解読法を詳しく解説した『プロフェッショナル電子メール』を上梓しました。 SMTP - RFC821,822/2822 MIME - RFC1521,1522 MIMEメッセージ・ヘッダ 日本語メール 半角カナとJIS S
Introduction of MIME
MIME の基礎 IIJ技術研究所 山本和彦 今回は MIME の話をしましょう。 以下では、言語と文字コードを同一視して説明します。 (もちろん両者が違うことは重々承知していますが、 今回は同一視した方が分かりやすいと思います。) テキスト・メールの問題点 MIME が登場した 1992 年以前の RFC822 (現 RFC 2822)で定められたメールは、 テキスト・メールと呼ばれています。 MIME はテキスト・メールの問題を解決するために考え出されました。 ここでは、その問題とは何だったのかをおさらいしておきましょう。 問題その1: テキスト・メールではヘッダが ASCII に限定されていました。 そこで、例えば日本語のような英語以外の文字列を 入れられませんでした。 問題その2: テキスト・メールでは本文も ASCII に限定されていました。 非英語圏では、これはあまりにも不
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だけで表現できない文字や、バイナリデー
お客様を知るためのマニュアル作成 - （旧姓）タケルンバ卿日記避難所
マニュアルを書くのはオススメ。プログラムの世界以外でもかなり有用だよ。 設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ 設計書に書かれた処理の手順なんてのを読んでも機能についてピンとこないが、 ユーザーマニュアルなら分かる。 なぜなら、分かるように書かなくてはならないからだ。 分かりやすくなくては、マニュアルの存在意義に関わる。 設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ こういう要素があるからこそ、書き手にとっていいトレーニングになるんですよ。取り組んでいることへの理解が進むし、ポイントの整理ができる。そして顧客の要望とか、需要なんかをつかみやすくなると思うんですよね。 読む人はプロではない 基本的にですよ、マニュアルというのは説明書なわけですよ。単純に考えてね。でだ、説明書が必要な人ってのは、使い方がわからないわけですな。知識
ルールを徹底する4つの原則 - レベルエンター山本大のブログ
以前のエントリ(ルールメーカーの生産性は、96倍 - 山本大の日記) に対して、コメントをいただきました。 今のPJでは、アサイン当初、まともなルールが無いPJでした。 「おいおい、こりゃまずいんじゃない？？」と思い、 自分が色々とルールを決めてみんなに提示したりしてました。 その結果… ・そのルールに欠陥(抜け)があって、バッシング ・メンバ内で徹底されず、逆に面倒な事に こんな状態でした。 ルールを作り出す事は重要だと思いますし、 必要だと感じれば、柔軟にルールを変える事は大賛成です。 でも、それを周知に徹底させて、実践し、推進していく事も同じく重要だと思わされる事が 今のPJではかなりあります。 周知に徹底させる為には、何が必要でどうすれば実践されると思いますか？ これには僕も覚えがあります。 一例を挙げると、僕が今の会社に入る前、仕事上のやり取りをルール化しようと考え 社内でコミュ
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メールにかけられた呪文「MIME〜前編」