Japanese Filename｜RFC2231の誤り
目次 はじめに MIME ヘッダ ファイル名の記述方法 現状の Windows のメイラーにおける日本語ファイル名の取り扱い RFC 2231 RFC 2231 の誤り はじめに Windows のメイラーでは日本語のファイル名の付いた添付ファイルを扱えるものがほとんどであるが、その実装は正しいのであろうか？ 実はほどんどが誤りである。しかし、誤りではあるが同じ方法を実装していれば相互間の運用にはそれほど不都合はないため、Windows しか使っていないユーザーは誤りであることに気が付かないことが多い。定義されていない実装であるから当然のことながら、正しい実装をしている IMAP サーバやメイラーではそのファイル名を認識できない。本末転倒である。そこで、ここでは添付ファイルにおける日本語のファイル名について考察を行っていくことにする。 MIME ヘッダ まず、この文書を理解するために必要な
ＲＦＣ日本語版リスト
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
RFC
拡張されたメールシステムステータスコード 簡単な解説 RFC 3030 大きなバイナリのMIMEメッセージを送信するためのSMTPサービスの拡張 この文書はSMTP(単純なメール転送プロトコル)サービスに2つの拡張を定義す る。最初の拡張により、DATAコマンドの代わりに、効果的に大きな MIME(Multipurpose Internet MailExtensions)メッセージを送るための"BDAT" と呼ばれるものを利用することをSMTPクライアントとサーバが取り決めること ができる。2つ目の拡張では、バイナリ送信エンコーディングを用いるMIMEメッ セージ送信が取り決められるようになり、BDATコマンドに優位性を与える。こ の文書はRFC 1830の更新と無効化を意図する。 RFC 3251 Electricity over IP この文書は、IP上で送電するためのアーキテクチャで
Japanese - The Joel on Software Translation Project
[edit] カリフォルニア 2007年10月5日 [edit] FogBugz On Demand 2007年7月9日 [edit] マネジメントの本 2007年6月29日 [edit] 記憶に残るようなカスタマサービスへの7ステップ 2007年2月19日 [edit] ファウンダーズ アット ワーク 2007年1月30日 [edit] Copilot 2.0リリース! 2007年1月26日 [edit] ビッグピクチャー 2007年1月21日 [edit] 新年の抱負: もっといい仕事につくこと! 2006年12月20日 [edit] 50万件のバグ! 2006年12月20日 [edit] 新作! 2006年12月18日 [edit] エレガンス 2006年12月15日 人々がソフトウェアをいじるのは、多くの場合、それで遊びたくてそうしているわけではない。彼らがソフトウェアを使うの
サルでもわかる 逆引きデザインパターン 第3章 逆引きカタログ J2EE編 Facade（ファサーﾄﾞ）
イントロダクション みなさんのサーブレット（Strutsを使用している場合はアクションクラス）の行数は、平均どれくらいでしょうか？ データベースアクセスや業務処理など、すべての処理をサーブレットに詰め込もうとして、あっという間に1000行を越すような「太ったサーブレット」を作ってしまったことありませんか？ サーブレットを初めて書いたときは筆者もそうでした。 このような「長く」「すべての処理が入った」サーブレットのことをすべてのことを行う魔法のようなサーブレットということで「マジックサーブレット」と呼びます。 マジックサーブレットは保守や機能拡張が難しいのはもちろんのこと、「アプリケーションが提供する機能」を把握することが難しくなるという弊害があります。 機能を把握できないと「あの機能ってどこにあったっけ？」という状況を生み出しがちになります。 そのような状況を避けるためにも、「サービスを提
Super Agile Struts
Welcome to the "Super Agile Struts" project. Super Agile Struts(以降SAStrutsと省略)は、Strutsを使った開発をSuper Agileに行なうためのフレームワークです。 Strutsで開発する場合に困ることは、設定ファイルをたくさん書く必要があったり、 設定ファイルやJavaのコードを修正するたびにアプリケーションサーバを再起動する必要があることでしょう。 SAStrutsを使えば、設定ファイルを書く必要はなく、 スクリプト言語のようにファイルを保存する(保存と同時にコンパイルするような設定になっている場合)と、 すぐにその内容をアプリケーションサーバの再起動なしで認識することができます。 スクリプト言語のように「さくさく開発」ができ、 EclipseなどのIDEによるコードの自動補完などで、 さらに生産性を高めるこ
サルでもわかる 逆引きデザインパターン 第3章 逆引きカタログ J2EE編 DAO（Data Access Object）
イントロダクション 私たちが作るアプリケーションのほとんどは、どこかで永続的なデータを扱うことになります。 そのデータの保存先は、リレーショナルデータベースやテキストファイル、他システムなどになるでしょう。 そして保存されたデータへのアクセスで使用するAPIは、保存先によって変わっていきます。 例えば、リレーショナルデータベースだとJDBCを使用します。 ファイルだとjava.ioパッケージあたりを使用したりします。 また、リレーショナルデータベースのみに焦点を当ててみても、ベンダやバージョンによって発行するSQL文を変えなければなりません。 ファイルに永続的なデータを保存していて、その保存先がデータベースに変更されたときのことを想像してください。 ビジネスロジック（業務ロジック）の中にデータアクセスにまつわるコードを書いている場合、保存先の変更が容易ではありません（同様のことが、データベ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.rfc-editor.org/rfc/rfc5322.txt
https://www.rfc-editor.org/rfc/rfc5321.txt
http://www.puni.net/~mimori/rfc/rfc2822.txt
InfoQ: コードカバレッジには要注意