スキップしてメイン コンテンツに移動

Outlookで自動改行させないための設定 ~もういい加減 UTF-8 / base64 でよくね?~

Outlookで勝手に「自動改行」させないための設定、正解は、[ファイル] - [オプション] - [詳細設定] の「文字設定オプション」で「送信メッセージで優先使用するエンコード方法(E):」を『Unicode (UTF-8)』にする

こうすることで、テキスト形式のメールは
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
として送信されるので、受信側でメールを表示すると
 閲覧環境にあわせて適切に「折り返し」
 送信者の意図した位置で「改行」
される。


送ったメールの「ソース」を受信側で表示するとこんな感じ。
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Language: ja

44CA44KE44GB44CBDQrjgIDjgZPjgozjgpLoqq3jgpPjgafjgYTjgovjgajjgYTjgYbjgZPjgajj
ga/jgIFiYXNlNjTjgqjjg7PjgrPjg7zjg4njgZXjgozjgZ/mloflrZfliJfjgpLjg4fjgrPjg7zj
g4njgZfjgZ/jga7jga3jgIHjgZnjgbDjgonjgZfjgYTvvIENCg==  
base64エンコードすると、76文字で「改行」していることがわかるよね。


っていうかさ、違うんだよ。いつも、もやーっとするのね。

『Unicode (UTF-8)』って、Unicode という「符号化文字集合(character set)」を UTF-8 という「文字符号化方式」で「エンコード」してるんであって、「メールのエンコード方法」じゃないんだよね。

本来なら
  1. 符号化文字集合は何を使いますか?
  2. 文字符号化方式は何を使いますか?
  3. メールのエンコードはどうしますか?
と3つ聞かないといけないんだけど、メールのヘッダには「符号化文字集合」を表すヘッダがないから(というか、世の中そうなんだけど)、1.と2.が「セット(UTF-8と言えばUnicode)」になってて、3.はそれに従う(8ビット符号単位のセットならbase64、7ビット符号単位のセットなら7bit)」っていうことを、いろんなシステムが「裏」でしちゃうから、自称「SE」さんたちもこの辺のいわゆる「文字コード」について誤解っていうか、理解せずにいるんだよね。おれより高給取りのくせに。

しかも、文字セットは受信側に依存するし、表示フォントでも変わるし、なんなら、送信側のフォントによっても、メールを書いているときに「入力できる/できない=表示できる/できない」から、「送信メッセージで優先使用するエンコード方法(E):」っていう設定項目の見出しそのものがおかしくて、


送信メッセージの文字符号化方式:
○ ISO-2022-JP
○ Shift_JIS
⦿ UTF-8

メール転送符号化方式 (Content-Transfer-Encoding):
○ 7bit
○ 8bit
○ binary
○ quoted-printable
⦿ base64


とするのが本来だと思うんだ。
「送信メッセージの文字符号化方式 :」の注意書きとして「あなたが入力した件名と本文をこの方式で再符号化します。その結果、あなたには見えている件名と本文が、受信側では見えなくなることがあります。これは、UTF-8を選択すること回避できます。」ぐらい表示してさ。

そのうえで、両方の組み合わせがおかしくならないように選択肢を制御すればいいと思うんだけどね。

もういい加減、UTF-8 + base64 をデフォルトにすれば、このWindows 95の時代から続く「改行(折り返し)問題」が解決するんだけどな~

いまだにいるんだよね。40以上のSEさんとそいつらに育てられた若手か、ネットに転がっているサンプルを適当に取ってきて、

ISO-2022-JP + 7bit

でメール送るPG作るヤツ。

コメント

このブログの人気の投稿

Chatの「メッセージは投稿者によって削除されました」を非表示にする方法

Chrome拡張機能を自作してやってみよう! ♪できるかな できるかな ・・・ 無理ぽ (´・ω・`) iframeの中に、実際のメッセージのやり取りが表示されるので、 $(function(){ $('iframe[name^="spareFrame"]').contents().find('[data-is-tombstoned="true"]').hide(); }); って書いたけど An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. って言われてダメだったよ・・・

cron で実行されたコマンドから出力されたメッセージをメールで送信する方法

本題に入る前に、まずは、sh/bash系のシェルで標準出力と標準エラー出力をリダイレクトする方法から。 現在使用中のシェルを確認するには、 # echo $SHELL とすれば確認できる。 その他、利用できるシェルを確認するには # cat /etc/shells とする。 ■リダイレクトについて commandコマンドが出力を伴うコマンドの場合、commandコマンドの出力をresult.txtへ出力するには # command > result.txt コマンドの実効結果を別のコマンドの入力値とする場合は、|(パイプ)でつなげる。 # command1 | command2 ■標準出力と標準エラー出力について ・標準出力 正常結果やコマンド実行途中に出力されるメッセージの出力先。 ・標準エラー出力 異常終了時のメッセージやエラーメッセージなど、ユーザーに気づいてほしいメッセージの出力先。 ■標準出力と標準エラー出力の両方をリダイレクトする 先のcommandコマンドのリダイレクト例のうち、result.txtへのリダイレクトは、標準出力をリダイレクトしている。そのため、標準エラー出力はリダイレクトされず、仮にcommandコマンドが標準エラー出力へメッセージを出力した場合は、result.txtではなくコンソールへ出力(表示)される。 標準出力と標準エラー出力の両方をリダイレクトして、result.txtへ出力するには、 # command > result.txt 2>&1 とする。 なお、上の例を省略なしで記述すると # command 1> result.txt 2>&1 となる。 この「1」「2」の番号について。 ・1:標準出力。通常はコンソール画面。 ・2:標準エラー出力。通常はコンソール画面。 となっている。 ちなみに、「0」は「標準入力」。通常はキーボードからの入力。 例:標準エラー出力を error.log へ出力する。標準出力はコンソールへ表示する。 # command 2> error.log 例:標準出力は result.log 、標準エラー出力は error.log へ...

同一セッションに悩まされ

Internet Explorer も、気がついてみたらFirefoxまでも、複数タブ・ウィンドウ間で同一セッションになってしまった。確か、Firefox 3.6のときは、ウィンドウが別だったらセッションも別になっていたと思ったのになぁ... で、同一セッションになって困るのは、セッション変数の扱い。 同じフォームを二つのタブやウィンドウで開くと、後から開いた方の値でセッション変数は上書きされてしまう。 これを防ぐには、フォームがはじめて表示されたときにフォームに対して一意の値を生成し、そいつを毎回POSTする。 そして、セッション配列へフォームの値を保存するときは、POSTされた一意の値をセッション配列のkey、保存したいフォームの値をvalueとすればよい。 で、いらなくなったときに、セッション配列の要素をunset()してやればいい。 この考え方は、ワンタイムチケットと同じ。 こっちも参照 してね。 ワンタイムチケットでなくても、例えばログインフォームで一意の値を生成し、そいつをフォーム間で引き回せば、同じことができる。 ただし、ログインフォームで生成した一意の値が仮に悪意の第3者に漏れた場合、何をされるかわからないので、できれば、一定間隔で再生成する仕組みを考えた方がいい。