「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
２行に渡るメールヘッダの正しい処理
問題発生 長いメールヘッダの規定 MIMEの規定 正しいメールヘッダ復元の実装 問題発生 ある方より、メール投稿利用時に長い日本語タイトルを付けると、途中に半角スペースが入ってしまうというバグ報告を受けました。 Subject: =?ISO-2022-JP?B?GyRCPmFHKz5hRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hGyhC?= =?ISO-2022-JP?B?GyRCRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hGyhC?= のようにMIMEエンコードが長くなり空白が入ったときに、この空白がデコードされてもそのまま残ってしまうことが原因です。やっつけならこの空白を除去するだけで良いのですが、やっつけプログラムは最低なのできちんと調査してみました。 長いメールヘッダの規定 RFC 2822「Internet
クッキーの最大サイズ制限について
Updated: 2004-01-11 22:26:43+0900 - [ HOME ] はじめに この文書は、クッキーの最大サイズの制限について説明したものです。なぜこんなことを調べ始めたかについては、日記、もじら組のスレッド、および、実際に問題を再現するこちらのページをご覧下さい。 この文書を書くに当たって、もじら組での議論が非常に参考になりました。ありがとうございます。自分は最初クッキーの仕様について勘違いしていて、いろいろ問題のある発言をしていて恥ずかしいのですが……。まだ間違っている個所があるかもしれません。間違いを発見されましたら、ご連絡いただけると嬉しいです。 クッキーの個数 クッキーは、「名前＝値」の1つの組みを1個と数えます。変数1個がクッキー1個に相当します。Netscapeの仕様およびRFC 2109(obsolete)によると、クライアントは1つのホストまたはドメイ
iCalendar仕様
iCalendar 仕様 iCalendar コンテンツの作成にとりあえず役立ちそうな情報の抜書き。（正確な仕様は RFC にあたること） 目次 仕様書 全般 構造 詳細 BEGIN, END VCALENDAR VTIMEZONE VALARM VEVENT テンプレート 実装 仕様書 iCalendar は RFC で定義されている。 RFC2445 (November 1998) Internet Calendaring and Scheduling Core Object Specification (iCalendar) RFC2446 (November 1998) iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Jo
計算機の名前を選択するには
RFC1178-ja-NJT.TXT 本文書は RFC1178 Choosing a Name for Your Computer 計算機の名前を選択するには の日本語訳である。 第1.01版（レビュー待ちバージョン） ※全文翻訳完了しています。 ※みなさまのレビューをお願いします。 ※??? のついているところはかなりあやしいところです。 ※ホスト名の実例には日本語訳もつけましたが不要かもしれません。 Thanks to "Yasuda Shun'ichi" for his review. 著作権表示 なし None 日本語訳についての二次的著作権は： Derivative copyright about Japanese translation: なし None 配布条件 日本語訳の配布条件は英語の原文の配布条件に従う。（無制限） ただし、無保
E-mail header basis
ヘッダあれこれ IIJ技術研究所 山本和彦 前回はテキスト・メールの歴史や書式について解説しました。 今回はヘッダ中のフィールドの意味や使用方法、 そしてよく見受けられる誤解などについて解説していこうと思います。 これはインターネット・マガジンに執筆した原稿を元にしています。 紙面の関係上削られた部分も残っていますので、 既に同誌を読んで下さった方にも役にたつかもしれません。:-) インターネットとプロトコル インターネットはすべての人が活動できるオープンな世界です。 この特徴はインターネットのルールすべてが話し合いによって決定され、 公開されていることが根底となって支えられています。 インターネットでは、データの送受信方法やデータの書式などの取り決めも含む、 技術的なルールをプロトコルと呼びます。 プロトコルは、 RFC(Request For Comments)という通し番号のついた
ドコモ、メールアドレスの仕様を修正 | スラド モバイル
俺の周りにはまだ電話番号@docomo.ne.jpの人もいるし、 俺自身も、途中で@jp-tから@t.vodafoneになったものの、10年間アカウント変えてないです。 これが多数派か少数派かわかりませんが、 メールアドレスなんて変えるもんじゃないと思ってる人が一定数いて、その中に変なアドレスの人が含まれてたら、 「新規に取れなくしました」だけでは変なアドレスはなくならないし、 なくならないと言うことは、結局メールを使うサービスを提供しているほかのシステムがそれに合わせた仕様にせざるを得ないわけで、 じゃぁもう別に新規に取れなくしてくれなくても変わらんと思うのですが・・・ ずいぶん極端な御意見だと思います。 病気の根本原因を取り除いて完治させられないならば、 感染拡大防止や対処療法なんて何の意味も無い、と言い切るぐらいに、 > なくならないと言うことは、結局メールを使うサービスを提供してい
RFC1459: Internet Relay Chat Protocol (IRC)
この文章の取り扱い この文章にはInternet communityのためのExperimental Protocolを定義し、改善のための意見と提案が寄せられています。 このプロトコルと標準化の状況については"IAB Official Protocol Standards"の最新版を参照して下さい。 この文章の配布は自由に行ってかまいません。 <訳者注:>これは原文の取り扱いです。日本語訳についてはセクション13.2 「日本語訳について」に準じます。 また、IRCプロトコルの定義はあくまで原文であることを断っておきます。 概要 最初にBBS上のユーザ間のチャットの方法として使われ初めてから4年間以上にわたって、IRCプロトコルは開発が進められています。 現在、このプロトコルはサーバ／クライアント方式で世界中のネットワークをカバーしています。そして、ネットワークの成長に伴って、プロトコルも
CSVファイルの一般的書式 (RFC4180 日本語訳) - アルプス登山の玄関口・笠井家
2005年10月に公開された、RFC4180「Common Format and MIME Type for Comma-Separated Values (CSV) Files (CSVファイルの一般的書式、およびMIMEタイプ) 」の日本語訳です。謝辞と文献の箇所は原文のままです。 データ交換において頻繁に使われるCSV形式ですが、ベンダの独自仕様が乱立しているのが実情です。 本RFCは、遅まきながら出てきた、最初にして唯一の、「公式(?)」な仕様です。もっとも、区分 (Category) がInformationalのRFCなので、「標準」ではありませんが… 原文は、http://www.ietf.org/rfc/rfc4180.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
