２行に渡るメールヘッダの正しい処理
問題発生 長いメールヘッダの規定 MIMEの規定 正しいメールヘッダ復元の実装 問題発生 ある方より、メール投稿利用時に長い日本語タイトルを付けると、途中に半角スペースが入ってしまうというバグ報告を受けました。 Subject: =?ISO-2022-JP?B?GyRCPmFHKz5hRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hGyhC?= =?ISO-2022-JP?B?GyRCRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hGyhC?= のようにMIMEエンコードが長くなり空白が入ったときに、この空白がデコードされてもそのまま残ってしまうことが原因です。やっつけならこの空白を除去するだけで良いのですが、やっつけプログラムは最低なのできちんと調査してみました。 長いメールヘッダの規定 RFC 2822「Internet
Unicode-LineBreak-2019.001
No new features. ! Makefile.PL GH PR#4: Added timeout to wget call in Makefile.PL by J. Bargsten. CPAN RT#125079: Installation stuck after a wget. Fixed by changing scheme from ftp to https. ! lib/Text/LineFold.pm ! t/04fold.t Fix: Text::LineFold: new() & config() did not allow multiple Prep option ! t/01break.t ! t/02hangul.t ! t/03ns.t ! t/04fold.t ! t/05urgent.t ! t/06context.t ! t/07sea.t ! t/
MIMEマルチパート - 通信用語の基礎知識
一通の電子メールに、異なる種類のデータを混在させるための技術。 MIME(RFC 2045〜2049)の拡張仕様で、RFC 2112として標準化されている。 従来の電子メールはヘッダーと本文とに別れており、その区切りは空行一つである。 MIMEマルチパートは本文を更に複数に分割するための方法を規定したもので、複数に区切るための境界線(boundary)の「入れ方」を標準化している。 こうして境界線で区切られた各部分をパート(part)といい、それが複数存在できるためマルチパート(multipart)と呼ばれるのである。 またMIMEマルチパートは、各パートをさらにマルチパート化することが可能である。その階層の深さについては、RFCでの規定はない。 メールヘッダー内のContent-Typeの媒体型名は「multipart」となり、本文がマルチパートであることを表わす。 また各パートごとにC
RFC日本語化計画
H26/01/15 RFC 7085 既存のドット無しトップレベルドメインを公開 H22/11/20 RFC 2482 言語タグを公開 H22/11/12 RFC 6082 言語タグの廃止を公開 H22/04/03 RFC 5841 パケット気分を公開 H21/10/27 RFC 4042 UTF-9/UTF-18を微修正 H21/04/01 スタイルシートを追加、RFCを番号順に並び替えた H20/12/17 RFC 1922 ISO-2022-CNを更に更新 H20/12/16 あまりにも読みにくかったので、多少構成を改善した RFC 1922 ISO-2022-CNを更新 H20/07/29 IE7での表示がおかしかったので、CSSをなくしてみた。 H18/12/09 訳文を、全てSJISからUTF-8に変更しました。 H18/04/07 RFC 4042 UTF-9/UTF-18を
メール関係 - 日本語化RFC
RFC2142Mailbox Names for Common Services, Roles and Functions 一般的なサービス、役割、機能に対するメールボックス名 その他 RFC 日本語訳 RFC821Simple Mail Transfer Protocol 単純メール転送プロトコル RFC974Mail routing and the domain system メールルーティングとドメインシステム RFC1047Duplicate messages and SMTP 複製メッセージとSMTP RFC1846SMTP 521 Reply Code SMTP 521 返答コード RFC1869SMTP Service Extensions SMTPサービス拡張 RFC1870SMTP Service Extension for Message Size Declaratio
改行の怪 – Justice
たいていのメールソフトは一定の文字数で自動改行するための機能を備えています。その際の禁則処理などについて気になったので、私のパソコンの中に入っているいくつかのメールソフトについて、実際にメールを送信して確かめてみました。 Thunderbirdは送信時に72文字できれいに改行してくれました。禁則処理などは、句読点はぶら下げ禁則で、「っ」などの小文字は追い出し禁則（手前の大文字とセットで次の行に行くように改行）されていて、なかなか見た目はよろしいようです。自動改行するしないの切り替えは特に見当たらず、指定した文字数で常に改行されることになるみたいです。改行したくなければ「1000文字」とかに設定しておけばいいのかもしれません。 PostPet Ver.2.0 の場合には、文字数の設定は見当たらなかったのですが、送信時には72文字で自動的に改行されていました。禁則処理は一切適用されず、句読点や
言語コードと国コード
HTML 4.0（それ以前にRFC2070）で導入されたlang属性、hreflang属性、およびXMLのxml:lang属性[1]は、「言語コード」を指定することで、ドキュメントで使用している言語を明示し、ブラウザの表示に加えてサーチエンジンや音声合成にも役立つような情報を提供します。ここで用いられる「言語コード」はURLの指定などに使われる「国コード」とは異なるもので、日本語は「JA」になります。混乱しやすいので、注意が必要です。 言語コード 国コード Charset ? 言語コード 日本のように国家と言語が（ほぼ）1対1で対応しているとあまり意識しませんが、一つの国で複数の公用語を持っているところもあれば、多くの国で使われる言語もあります。このため、「国コード」とは別に130以上の「言語コード」がISO 639によって定義されています。 主要なものを挙げると： 主な言語コード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://hibinokoto.jp/archives/2007/04/post-143.html