[ 新規に投稿する ]

自動折り返し関係の仕様変更案&意見募集No.02253
秀まるお2 さん 17/10/19 18:08 [ コメントを投稿する ]
   最近ですが、スマホを使う人が当たり前になった関係で、メール本文を72桁で折り返す意味がほとんど無くなったというか、むしろ余計な処理になってきてるように思います。

 スマホに合わせる形で、Windowsのメールソフトもいろいろ変わってきてまして、ThunderbirdやWindows10の「メール」アプリも折り返し一切せずに送信します。

 ということで、秀丸メールの仕様も時代に合わせて変更しようと思います。


■1.現状の、「表示」メニューにある「自動折り返し」を、

    「72桁で折り返し」

  ってコマンドにして、このコマンドは送信系メールでしか効かないように
  します。

  受信系メール:現状の「自動折り返し=ON」固定の動作になる
  送信系メール:72桁で折り返すか折り返さないかの切り替えが可能

  秀丸メール本体上の「表示」メニューからは、「自動折り返し」コマンド
  を削除します。

■2.「全般的な設定・メール表示」の中に、

  +送信するメールの自動折り返し----------+
  |  ● 72桁で折り返し   ○折り返しなし  |
  +--------------------------------------+

   のような設定を追加します。旧バージョンからバージョンアップ
  したユーザーさんは「72桁で折り返し」がデフォルトONになりますが、
  新規インストールしたユーザーさんからは「折り返しなし」が標準
  になるようにしてしまおうと思います。

  「本文の折り返し桁数」と「引用行の折り返し桁数」の設定は廃止
  しようと思います。(本文=72、引用行=79桁固定にしてしまう)

■3.「全般的な設定 - メール表示 - 詳細(表示関係)」の
  「□ 送信系メールで、表示上に限ってウィンドウ幅で折り返す」
  は廃止というか、ON相当固定にする。従って、「折り返しなし」
  のメールについてはウィンドウ幅で折り返して表示される形になる。

 ってことで、時代の変化に合わせようと思います。

 何かご意見がありましたらコメントお願いします。
[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02255
石田 さん 17/10/19 21:07 [ コメントを投稿する ]
  新方針についての質問です。

>受信系メール:現状の「自動折り返し=ON」固定の動作になる
>送信系メール:72桁で折り返すか折り返さないかの切り替えが可能

これは送信者は従来通り、72ケタで送信できるが、
受信者は73ケタ目に改行マークが入ったメールを読まなくて良い。
受信メールの体裁は受信者が勝手に決められる……という事でしょうか?
[ ]
RE:02255 自動折り返し関係の仕様変更案&意見募集No.02257
秀まるお2 さん 17/10/20 08:39 [ コメントを投稿する ]
   秀丸メールからメールを発信する場合についての話になるかと思います
が・・・

>送信系メール:72桁で折り返すか折り返さないかの切り替えが可能

 従来通り、「72桁で折り返し」をONにして使う限りは何も変わらないです。そ
の場合は、秀丸メール上での表示は72桁で折り返し表示されつつ、届いた先でも
72桁で必ず改行されて表示されます。

 今回追加予定の新しい方式の「折り返さない」を選択した場合は・・・

 秀丸メール上では、ウィンドウ幅で折り返して表示されます。届いた先でも、
僕が調べた限りでは、すべてのメールソフトではウィンドウ幅で折り返して表示
されます。

> 受信者は73ケタ目に改行マークが入ったメールを読まなくて良い。

 新しい「折り返さない」を選択して送った場合は、そうなります。

> 受信メールの体裁は受信者が勝手に決められる……という事でしょうか?

 相手のメールソフト次第になりますが、僕が調べた限りでは、すべてのメール
ソフトがウィンドウ幅で折り返して表示する動作になっていました。折り返し桁
数をウィンドウ幅とは別に指定できるようなメールソフトは無いと思います。
[ ]
RE:02257 自動折り返し関係の仕様変更案&意見募集No.02263
石田 さん 17/10/21 02:57 [ コメントを投稿する ]
  最新メール事情には疎い者ですが、新タイプの秀丸メール
になっても、画面デザインの「2枠区切り」は維持される
のでしょうか? ほとんどのメーラが「3枠区切り決め打ち」
で、自分には使い易いとは思えないのです。是非、「2ペイン」を
利用者が選択できる余地を残して欲しいと願っています。
[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02264
hajimet さん 17/10/21 11:11 [ コメントを投稿する ]
  いつも便利に活用させて頂いております
キチンと理解できていないのですが、
たとえば、「○折り返しなし」設定の場合は、
X-TuruKame-KeitaiSend: 1 が設定されているのに相当する動作をして、
X-TuruKame-KeitaiSend: 1 の設定自体が無意味になるのでしょうか。
 すなわち「● 72桁で折り返し」設定をしているときだけX-TuruKame-KeitaiSend: 1が意味を持つ。
あるいはなにかちょっとした違いが生じるのでしょうか。
 たとえば、1000文字で改行が入る、のような、RFC的な規定を外す動作に違いが出るなど。
[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02266
K'zawa さん 17/10/22 11:23 [ コメントを投稿する ]
  秀まるおさん、こんにちは。
K'zawaです。

> 「□ 送信系メールで、表示上に限ってウィンドウ幅で折り返す」
>  は廃止というか、ON相当固定にする。従って、「折り返しなし」
>  のメールについてはウィンドウ幅で折り返して表示される形になる。

折り返しありの場合は従来どおり、送信時に改行文字が入れられる場所で
折り返し表示されるということですよね?

>  受信系メール:現状の「自動折り返し=ON」固定の動作になる

これは、受信メールの折り返しは一切できないということでしょうか?
また、72(引用79)桁に固定ということでしょうか?ウィンドウ幅でしょうか?

例えば80桁とか90桁で改行を入れたメールを、改行以外で折り返さないようにし
て閲覧することはできなくなるのでしょうか?(それは困ります)
[ ]
RE:02263 自動折り返し関係の仕様変更案&意見募集No.02269
秀まるお2 さん 17/10/23 08:09 [ コメントを投稿する ]
   2枠区切りというか、枠関係については特にいじるつもりは無いです。その点
は大丈夫です。
[ ]
RE:02264 自動折り返し関係の仕様変更案&意見募集No.02270
秀まるお2 さん 17/10/23 08:17 [ コメントを投稿する ]
   現状だと、

 自動折り返しあり  + X-TuruKame-KeitaiSend:1  --> 折り返し無しで送信
 自動折り返しなし  + X-TuruKame-KeitaiSend:1  --> 折り返し無しで送信

 となってまして、X-TuruKame-KeitaiSend: 1 があれば、どっちにしても折り
返し無しで送信されます。

 次のβ版からも同じになる予定です。「自動折り返し」のコマンド名称が
「72桁で折り返し」って名前に変更にはなりますが、X-TuruKame-KeitaiSend:の
動作には変更は無いです。

 つまり、

 72桁で折り返し:ON + X-TuruKame-KeitaiSend:1  --> 折り返し無しで送信

 となります。

>  たとえば、1000文字で改行が入る、のような、RFC的な規定を外す動作に違い
> が出るなど。

 1行の長さが1000行を超える場合は自動的にメール本文をbase64エンコードし
て送るようにしています。(現状の秀丸メールでも)

 ちなみにWindows10のメールアプリも同じような動作になってるようでした。
たぶんスマホのメールアプリとかもみんな同じだと思うし、今さらbase64
エンコードの解釈できないメールクライアントは無いと思うので、折り返し無し
での送信でも問題は出ないだろうと思います。
[ ]
RE:02266 自動折り返し関係の仕様変更案&意見募集No.02271
秀まるお2 さん 17/10/23 08:26 [ コメントを投稿する ]
  > 折り返しありの場合は従来どおり、送信時に改行文字が入れられる場所で
> 折り返し表示されるということですよね?

 「自動折り返し」のコマンド名称が「72桁で折り返し」となるだけで、自動折
り返しありの場合の動作は基本同じです。

 しいて違う点としては・・・現状では「全般的な設定 - メール表示」の所で
折り返し桁数(および引用行の折り返し桁数)を好きなように指定できますが、
それは廃止して、72固定(引用行は79固定)にしてしまいます。

 ここをカスタマイズしてる人がいたら困るかもしれないって懸念はあります。

> これは、受信メールの折り返しは一切できないということでしょうか?
> また、72(引用79)桁に固定ということでしょうか?ウィンドウ幅でしょうか?

 受信系メールはウィンドウ幅で折り返し表示するのみの動作に固定しようとし
ています。

 メール自体が72桁で改行されてる場合は、例えばウィンドウ幅を80桁相当に広
げれば、画面上では72桁で折り返されて表示されたようになります。

> 例えば80桁とか90桁で改行を入れたメールを、改行以外で折り返さないようにし
> て閲覧することはできなくなるのでしょうか?(それは困ります)

 ウィンドウ幅を90桁より大きくひげればいいと思いますが、90桁より狭い幅に
すると、ウィンドウ幅で折り返されて表示されてしまいます。

 例えば

+--------------------------+
|あああ                    |
+--------------------------+

 みたいな罫線で書かれた表があったとして、その表の横幅が90桁あったとして、
ウィンドウの幅が80桁した無かったら、

+-----------------------
---+
|あああ                 
   |
+-----------------------
---+

 みたいな表示になってしまいます。

 それが困るということになると・・・。やはり受信系メールでの自動折り返し
ON/OFFは維持しないとダメってことになりますが・・・。

 自動折り返しありで送信してくるメールはみな、80桁未満で改行してるはずだ
し、そういう、90桁前提でレイアウトが崩れるようなメールを送ってくるケース
は、しいてHTMLメール以外では無いと思うんですけども。

 どうなんでしょうか。
[ ]
RE:02271 自動折り返し関係の仕様変更案&意見募集No.02272
秀まるお2 さん 17/10/23 09:12 [ コメントを投稿する ]
  >  それが困るということになると・・・。やはり受信系メールでの自動折り返し
> ON/OFFは維持しないとダメってことになりますが・・・。

 改めて他のメールソフト見直してみたんですが、Shuriken 2016の場合は
「ビューア設定」ってのがあって、そこで折り返し無しの表示も可能なようでし
た。

 Becky!やThunderbirdには、折り返し無しで表示する機能は無いように思いま
す。

 果たしてどうしたらいいやら?

 案として・・・やはり受信系メールでの自動折り返しON/OFF機能を削らないよ
うにするとしたら・・・

 「表示」メニューの中に「自動折り返し」ってサブメニューを入れた上で、そ
こに、

送信系メールの場合:
   72桁で折り返し
   折り返しなし(表示上はウィンドウ幅で折り返し)

受信系メールの場合:
   ウィンドウ幅で折り返し
   折り返しなし

 ってコマンドを表示するアイデアがいいかなぁと思ったりしました。
 もうちょっと考えます。
[ ]
RE:02270 自動折り返し関係の仕様変更案&意見募集No.02277
hajimet さん 17/10/23 16:13 [ コメントを投稿する ]
  ありがとうございました。
>たぶんスマホのメールアプリとかもみんな同じだと思うし、今さらbase64
>エンコードの解釈できないメールクライアントは無いと思うので、折り返し無し
>での送信でも問題は出ないだろうと思います。
もうそういう時代なのですね。勉強になりました。安心して折り返し無し設定で運用することにします。

あとは、この掲示板にメールで投稿する際にどこで折り返しされるのか
という場面で、一行字数を気にすることがあるくらいでしょうか。
[ ]
RE:02277 自動折り返し関係の仕様変更案&意見募集No.02279
秀まるお2 さん 17/10/23 16:52 [ コメントを投稿する ]
  > あとは、この掲示板にメールで投稿する際にどこで折り返しされるのか
> という場面で、一行字数を気にすることがあるくらいでしょうか。

 ここの掲示板のメールによる投稿およびメールによる配信の仕様ですが、

 まず、投稿については、自動折り返し無しで書き込まれた場合は、それはそのままの形で書き込みされます。

 配信されるメールについては、書き込まれた内容が折り返し無しだったとしても、配信されるメールについては72桁で折り返されるように改行を入れて配信されるようにしてました。(http:とかのURLは例外として)

 それについて、実は今日システムを修正してまして、自動折り返し無しで配信するようにしました。

 例えばこのメールも、自動折り返し無しで配信されてると思います。
[ ]
RE:02272 自動折り返し関係の仕様変更案&意見募集No.02280
K'zawa さん 17/10/23 17:19 [ コメントを投稿する ]
  秀まるおさん、こんにちは。
K'zawaです。

追加質問ですが、送信が「72桁で折り返し」オフのとき、手動の改行はできるの
ですよね?相手が自由な感性で改行をいれて送ってくる場合もあると…。

追加質問終わり

受信メールについて

こちらはスクリーンリーダーを使っているので、(改行でない)折り返しのあと、
数文字で改行、みたいなパターンが嫌なんです。
なので、改行が全くないか一行がものすごく長いメールならウインドウ幅、
それ以外のメールは、秀丸エディタでいうところの最大で表示できれば
うれしいのですが、最悪、ウインドウ幅固定でもフォントサイズを小さくして、
最大150桁あたりまで対応できればいいかなと思いました。
(個人的に、受信メールの72桁折り返しはあまり意味がないと思っています。)

ということでなんとかなりそうなので、受信メールの折り返し設定をどうするか
はお任せします。

あるいは、ウインドウ幅固定だけど裏技として

config "xAutoAdjustOrikaeshi:2";

を使えるようにするとか。
[ ]
RE:02279 自動折り返し関係の仕様変更案&意見募集No.02281
hajimet さん 17/10/23 17:21 [ コメントを投稿する ]
  > 例えばこのメールも、自動折り返し無しで配信されてると思います。
これでほぼなにも気にせず、折り返し無しでの運用ができます。ありがとうございました。
[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02283
suii さん 17/10/23 17:41 [ コメントを投稿する ]
  > 「本文の折り返し桁数」と「引用行の折り返し桁数」の設定は廃止
> しようと思います。(本文=72、引用行=79桁固定にしてしまう)

私は引用行の折り返し桁数を上限の1000にしています。
引用行の折り返し79桁 というのは、たくさんの引用記号が付加されたメールでは
途中で体裁を崩して改行を挿入していくということでしょうか?
それは困ります。
[ ]
RE:02280 自動折り返し関係の仕様変更案&意見募集No.02284
秀まるお2 さん 17/10/23 18:10 [ コメントを投稿する ]
  > 追加質問ですが、送信が「72桁で折り返し」オフのとき、手動の改行はできるの
> ですよね?

 もちろん出来ます。

> 受信メールについて

 やっぱり、機能を減らすと後々他のユーザー様からも苦情が来ること間違いないと思うので、受信系メールでの「ウィンドウ幅で折り返しするかしないか」の設定およびコマンドは残すことにします。

 現状では、「表示」メニューに「自動折り返し(メール毎の設定)」ってコマンドがありますが、送信系メールと受信系メールとでコマンド名を変えて表示することにします。

 受信系メールの場合:「ウィンドウ幅で折り返し」コマンドを表示。

     ONの場合:ウィンドウ幅で折り返し表示

     OFFの場合:折り返し無し表示

 送信系メールの場合:「72桁で折り返し」コマンドを表示。

     ONの場合:72桁で折り返し表示され、送信されるメールは
          72桁に改行コードが入る。

     OFFの場合:ウィンドウ幅で折り返し表示される。
          送信されるメールには折り返し位置の改行は
          無し。

 コマンド名が変わるだけで、実質的には現状の秀丸メールと機能的に不足は無いと思います。
[ ]
RE:02283 自動折り返し関係の仕様変更案&意見募集No.02285
秀まるお2 さん 17/10/23 18:13 [ コメントを投稿する ]
   手元の暫定版では引用行の折り返し桁数79桁固定にしてしまってましたが、

> 引用行の折り返し79桁 というのは、たくさんの引用記号が付加されたメールでは
> 途中で体裁を崩して改行を挿入していくということでしょうか?
> それは困ります。

 はたしかにおっしゃる通りなので、とりあえず折り返し桁数の設定は残すことにさせていただきます。

 ただし、「全般的な設定 - メール表示 - 詳細(表示関係)」の所に移動します。

 メール本文の折り返し桁数の「72」をカスタマイズする機能は今のところ廃止という方向にさせていただきます。たぶんここもカスタマイズされてる方は、そもそも的に、新しい「折り返し無し」のモードで使っていただけると思うので。
[ ]
RE:02284 自動折り返し関係の仕様変更案&意見募集No.02286
K'zawa さん 17/10/23 20:22 [ コメントを投稿する ]
  秀まるおさん、こんにちは。
K'zawaです。

> やっぱり、機能を減らすと後々他のユーザー様からも苦情が来ること間違いないと
>思うので、受信系メールでの「ウィンドウ幅で折り返しするかしないか」の設定およ
>びコマンドは残すことにします。
<略>
> 受信系メールの場合:「ウィンドウ幅で折り返し」コマンドを表示。
>
>     ONの場合:ウィンドウ幅で折り返し表示
>
>     OFFの場合:折り返し無し表示
<略>
> コマンド名が変わるだけで、実質的には現状の秀丸メールと機能的に不足は無いと思います。

はい、こちらとしてはそれでOKです。
[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02288
usagi6502 さん 17/10/24 08:05 [ コメントを投稿する ]
  お世話になります。

念のため確認ですが、返信時のTO,CCのヘッダ部分の引用内容
や、新規作成時のTO,CC部分って言うのは、設定でそれなりに
表示されると考えてよろしいでしょうか?


また、見た目や使い勝手が変わる仕様変更は、理屈的には理解して
ても長年使い込んでいることもあり、慣れのせいで実際に使って
みると違和感があったりします。

取りあえず、β版を期待しています。


usagi6502





[ ]
RE:02288 自動折り返し関係の仕様変更案&意見募集No.02289
秀まるお2 さん 17/10/24 10:13 [ コメントを投稿する ]
  > 念のため確認ですが、返信時のTO,CCのヘッダ部分の引用内容
> や、新規作成時のTO,CC部分って言うのは、設定でそれなりに
> 表示されると考えてよろしいでしょうか?

 具体的にどのことを指しておられるのか(テンプレート?)分かりませんが、送信するメールでの自動折り返しとは無関係な所が変わることは無いはずです。

 そもそも的に仕様変更するといっても、、バージョンアップでインストールした場合は何も変化は無いはずになります。見た目上で、「表示」メニューの「自動折り返し」が「72桁で折り返し」って名前に変わってるだけの予定です。(細かい所は別にしたら)
[ ]
RE:02289 自動折り返し関係の仕様変更案&意見募集No.02292
usagi6502 さん 17/10/24 12:55 [ コメントを投稿する ]
  お世話になります。


早々にご教示ありがとうございました。
β版がリリースされれば試使用させていただきます。


なお、返信&転送時のテンプレートで$(SmallRootHeader)命令を使用
していますが、本文にアドレスが挿入された時、1行に1アドレスずつ
記述される仕様に変更がなければ助かります。



usagi6502

[ ]
RE:02292 自動折り返し関係の仕様変更案&意見募集No.02294
秀まるお2 さん 17/10/24 16:35 [ コメントを投稿する ]
   $(SmallRootHeader)の場合、現状は72桁で自動折り返し処理してて、それは次のβ版でも同じです。

 72桁で改行するのが仕様で、「1行に1アドレスずつ記述する」ってルールにはそもそもなってないです。

 例えば、

    To: a@hoge, b@hoge, c@hoge

 のようなヘッダのメールだと、そのTo:ヘッダの長さが72桁未満なので、そのまんま、1行に3つのメールアドレスが入ります。

 今はたまたま72桁での自動折り返しのせいで、1行に1アドレスに自動折り返しされてるんだろうと思います。
[ ]
RE:02294 自動折り返し関係の仕様変更案&意見募集No.02295
usagi6502 さん 17/10/25 07:46 [ コメントを投稿する ]
  お世話になります。

ご教示ありがとうございました。


> 今はたまたま72桁での自動折り返しのせいで、1行に1アドレスに自動折り返しされてるんだろうと思います。


 仕様ではなく”たまたま”と理解しました。

 マクロで処理していることもあり気になった次第です。



usagi6502




[ ]
RE:02253 自動折り返し関係の仕様変更案&意見募集No.02326
sgsano さん 17/10/28 17:22 [ コメントを投稿する ]
  一点質問させてください。

現状の秀丸メールは、“ Content-Type: ”の“ format=flowed ”(RFC 3676) 
には対応しておりましたでしょうか。

自動折り返しを行ったうえで、“ format=flowed ”に対応し送信するのがよい
のでは、と思います。

-- 
さの
[ ]
RE:02326 自動折り返し関係の仕様変更案&意見募集No.02330
秀まるお2 さん 17/10/29 09:31 [ コメントを投稿する ]
   format=flowedで送る方式もあって、Thunderbirdはその方式なんですが、format=flowedの仕組みは英語のメールの場合はいいんですが、日本語のメールだとあんまり仕様的に良くないというか、メールクライアントの解釈がはっきりしない点があって良くないかなぁという気がしてやめました。というか、実際Thunderbirdさんの動作がおかしいです。

 Thunderbirdから送られてくるメールの場合だと、引用行の改行がおかしくなるバグがあって、秀丸メールの方で独自の解釈を加えることでおかしくならないようにしています。

 参照: http://www.maruo.co.jp/hidesoft/8/x01793_.html

 このformat=flowedのRFCを決めてた人は日本語のことなんかなんにも考えてないんだろうと思います。Thunderbirdの開発してる人も、日本語のことよく分かってないように思います。

 base64エンコードして送る方式だと、そういう、メールクライアント毎に異なる動作も無いので、そっちの方が安心かなぁと思いました。実際、Windows10の「メール」アプリはbase64エンコードで送ってくるし、スマホのメールアプリもbase64かquoted-printableかのどっちかでエンコードかけて送ってきてるみたいです。(調べた限りは)

 もう本当に古い古いメールクライアント(base64の解釈が出来ないメールクライアント)があれば「読めない」っていう話が出てくると思いますけども、さすがにスマホ全盛の現代でそういうことは無いだろうと思います。
[ ]
RE:02330 自動折り返し関係の仕様変更案&意見募集No.02339
Iranoan さん 17/10/29 17:42 [ コメントを投稿する ]
  秀まるお2さん今日は、Iranoan です
>  もう本当に古い古いメールクライアント(base64の解釈が出来ないメールクライアント)があれば「読めない」っていう話が出てくると思います
まさしく私が普段使っている環境がこれなのですが、特殊な環境だし、自己対処できるので今までスルーしていました
これを踏まえて、
>  base64エンコードして送る方式だと、そういう、メールクライアント毎に異なる動作も無いので、そっちの方が安心かなぁと思いました。実際、Windows10の「メール」アプリはbase64エンコードで送ってくるし、スマホのメールアプリもbase64かquoted-printableかのどっちかでエンコードかけて送ってきてるみたいです。(調べた限りは)
についてですが、添付ファイルは base64 が多いですが、本文は quoted-printable の方が多い印象が有ります
その為、なぜ base64 にしたんだろう? という印象は有ります
[ ]
RE:02339 自動折り返し関係の仕様変更案&意見募集No.02340
秀まるお2 さん 17/10/30 09:16 [ コメントを投稿する ]
   iPhoneから届くメールは、同じ人からのメールでもなぜかquoted-printableとbase64の2種類あったりするみたいで、どういうルールになってるのかちょっと分かりません。

 Windows10の「メール」アプリはbase64固定みたいです。

 quoted-printableでもbase64でもどっちでもいいんですが。実はメール本文をquoted-printableでエンコードする処理はまだ秀丸メールに存在してないので、既存の、バグの枯れてる処理を使うとしたら、base64の方がいいというだけだったりします。
[ ]
RE:02340 自動折り返し関係の仕様変更案&意見募集No.02352
Iranoan さん 17/10/30 20:47 [ コメントを投稿する ]
  秀まるお2さん今日は、Iranoan です
>  iPhoneから届くメールは、同じ人からのメールでもなぜかquoted-printableとbase64の2種類あったりするみたいで、どういうルールになってるのかちょっと分かりません。
>
>  Windows10の「メール」アプリはbase64固定みたいです。
base64 の方がエンコード後のデータ量が少ないので、こちらが主流になってくるんですかね

>  quoted-printableでもbase64でもどっちでもいいんですが。実はメール本文をquoted-printableでエンコードする処理はまだ秀丸メールに存在してないので、既存の、バグの枯れてる処理を使うとしたら、base64の方がいいというだけだったりします。
解りました
個人で対応できる範囲なので、このままで構いません
[ ]
RE:02270 自動折り返し関係の仕様変更案&意見募集No.02354
Iranoan さん 17/10/31 11:37 [ コメントを投稿する ]
  秀まるお2さん今日は、Iranoan です
>  1行の長さが1000行を超える場合は自動的にメール本文をbase64エンコードし
> て送るようにしています。(現状の秀丸メールでも)
こちらのことで確認させて下さい
これまでは、自動で改行コードが入っていたので、これに該当するメールはこのフォーラムではほとんど流れていませんでした。しかし最近はこれに該当するメールが多く有り、確認したいことが有ります

具体的には、こちらのフォーラムの
> Subject: hidesoft.8:02353| V6.76β12
のメールです
このメールヘッダに
> Content-Type: text/plain; charset=iso-2022-jp
> Content-Transfer-Encoding: base64
と有り、本文部分が base64 でデコードされています
実際には処理をしているのが、こちらのフォーラムなのかその元となった秀丸メールなのかは解りませんが、こちらのメール本文は Shift-JIS をエンコードしていますよね
この場合、
Content-Type: text/plain; charset=shift_jis
Content-Transfer-Encoding: base64
などとするか、一旦 JIS か UFT-8 に変換後にエンコードし
Content-Type: text/plain; charset=iso-2022-jp
または
Content-Type: text/plain; charset=utf-8
等と、その元の文字コードに合わせるべきではないでしょうか?

実際「私の環境は本文の base64 は非対応なのかな?」と思っていたのですが、
Content-Type: text/plain; charset=shift_jis
に書き換えてやれば問題なく読めました
[ ]
RE:02354 自動折り返し関係の仕様変更案&意見募集No.02356
Iranoan さん 17/10/31 12:50 [ コメントを投稿する ]
  秀まるお2さん今日は、Iranoan です
> と有り、本文部分が base64 でデコードされています
> 実際には処理をしているのが、こちらのフォーラムなのかその元となった秀丸メールなのかは解りませんが、こちらのメール本文は Shift-JIS をエンコードしていますよね
> この場合、
> Content-Type: text/plain; charset=shift_jis
> Content-Transfer-Encoding: base64
> などとするか、一旦 JIS か UFT-8 に変換後にエンコードし
> Content-Type: text/plain; charset=iso-2022-jp
> または
> Content-Type: text/plain; charset=utf-8
> 等と、その元の文字コードに合わせるべきではないでしょうか?
追記です
こちらのヘッダはフォーラムのシステムが iso-2022-jp 決め打ちで「秀丸メールでは charset を元の文字コードに合わせてある」ということでしたら、このままで結構です
[ ]
RE:02356 自動折り返し関係の仕様変更案&意見募集No.02357
秀まるお2 さん 17/10/31 13:48 [ コメントを投稿する ]
   問題のメールの受信ログのbase64エンコードされた本文を個別に(秀丸エディタ用に自分で作った変換モジュールで)デコードしたら、状況理解しました。

 charset=iso-2022-jpとしてるにも関わらず、デコードされた内容がShift-JISになってしまってました。

 これは、すみませんがうちのコミュニテックスの方のバグになります。

 秀丸メールだと文字コード自動判定が働くので化けなくて、全然気づいてませんでした。

 コミュニテックスのシステムの方で修正させていただきます。
[ ]
RE:02357 自動折り返し関係の仕様変更案&意見募集No.02360
Iranoan さん 17/10/31 14:47 [ コメントを投稿する ]
  秀まるお2さん今日は、Iranoan です
>  charset=iso-2022-jpとしてるにも関わらず、デコードされた内容がShift-JISになってしまってました。
>
>  これは、すみませんがうちのコミュニテックスの方のバグになります。
結果的にフォーラム違いでしたね(^_^;;
[ ]
RE:02360 自動折り返し関係の仕様変更案&意見募集No.02366
秀まるお2 さん 17/11/01 07:51 [ コメントを投稿する ]
   今、うちのサーバーの該当モジュールを入れ替えて再起動しました。

 ありがとうございます。
[ ]

[ 新規に投稿する ]