自動折り返し関係の仕様変更案＆意見募集 - 秀丸メール情報交換会議室 - スレッド02253, 2017/10/19

自動折り返し関係の仕様変更案＆意見募集

秀まるお2 さん　17/10/19 18:08

　最近ですが、スマホを使う人が当たり前になった関係で、メール本文を７２桁で折
り返す意味がほとんど無くなったというか、むしろ余計な処理になってきてるように
思います。

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

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

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

「72桁で折り返し」

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

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

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

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

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

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

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

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

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

　何かご意見がありましたらコメントお願いします。

RE:02253 自動折り返し関係の仕様変更案＆

石田さん　17/10/19 21:07

新方針についての質問です。

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

これは送信者は従来通り、72ケタで送信できるが、
受信者は73ケタ目に改行マークが入ったメールを読まなくて良い。
受信メールの体裁は受信者が勝手に決められる……という事でしょうか？

RE:02255 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/20 08:39

　秀丸メールからメールを発信する場合についての話になるかと思います
が・・・

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

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

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

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

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

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

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

　相手のメールソフト次第になりますが、僕が調べた限りでは、すべてのメール
ソフトがウィンドウ幅で折り返して表示する動作になっていました。折り返し桁
数をウィンドウ幅とは別に指定できるようなメールソフトは無いと思います。

RE:02257 自動折り返し関係の仕様変更案＆

石田さん　17/10/21 02:57

最新メール事情には疎い者ですが、新タイプの秀丸メール
になっても、画面デザインの「2枠区切り」は維持される
のでしょうか？　ほとんどのメーラが「3枠区切り決め打ち」
で、自分には使い易いとは思えないのです。是非、「2ペイン」を
利用者が選択できる余地を残して欲しいと願っています。

RE:02253 自動折り返し関係の仕様変更案＆

hajimeｔ さん　17/10/21 11:11

いつも便利に活用させて頂いております
キチンと理解できていないのですが、
たとえば、「○折り返しなし」設定の場合は、
X-TuruKame-KeitaiSend: 1　が設定されているのに相当する動作をして、
X-TuruKame-KeitaiSend: 1　の設定自体が無意味になるのでしょうか。
　すなわち「● 72桁で折り返し」設定をしているときだけX-TuruKame-KeitaiSend:
1が意味を持つ。
あるいはなにかちょっとした違いが生じるのでしょうか。
　たとえば、１０００文字で改行が入る、のような、RFC的な規定を外す動作に違い
が出るなど。

RE:02253 自動折り返し関係の仕様変更案＆

K'zawa さん　17/10/22 11:23

秀まるおさん、こんにちは。
K'zawaです。

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

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

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

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

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

RE:02263 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/23 08:09

　２枠区切りというか、枠関係については特にいじるつもりは無いです。その点
は大丈夫です。

RE:02264 自動折り返し関係の仕様変更案＆

秀まるお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 --> 折り返し無しで送信

　となります。

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

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

　ちなみにWindows10のメールアプリも同じような動作になってるようでした。
たぶんスマホのメールアプリとかもみんな同じだと思うし、今さらbase64
エンコードの解釈できないメールクライアントは無いと思うので、折り返し無し
での送信でも問題は出ないだろうと思います。

RE:02266 自動折り返し関係の仕様変更案＆

秀まるお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 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/23 09:12

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

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

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

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

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

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

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

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

　ってコマンドを表示するアイデアがいいかなぁと思ったりしました。
　もうちょっと考えます。

RE:02270 自動折り返し関係の仕様変更案＆

hajimeｔ さん　17/10/23 16:13

ありがとうございました。
>たぶんスマホのメールアプリとかもみんな同じだと思うし、今さらbase64
>エンコードの解釈できないメールクライアントは無いと思うので、折り返し無し
>での送信でも問題は出ないだろうと思います。
もうそういう時代なのですね。勉強になりました。安心して折り返し無し設定で運用
することにします。

あとは、この掲示板にメールで投稿する際にどこで折り返しされるのか
という場面で、一行字数を気にすることがあるくらいでしょうか。

RE:02277 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/23 16:52

> あとは、この掲示板にメールで投稿する際にどこで折り返しされるのか
> という場面で、一行字数を気にすることがあるくらいでしょうか。

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

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

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

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

　例えばこのメールも、自動折り返し無しで配信されてると思います。

RE:02272 自動折り返し関係の仕様変更案＆

K'zawa さん　17/10/23 17:19

秀まるおさん、こんにちは。
K'zawaです。

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

追加質問終わり

受信メールについて

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

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

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

config "xAutoAdjustOrikaeshi:2";

を使えるようにするとか。

RE:02279 自動折り返し関係の仕様変更案＆

hajimeｔ さん　17/10/23 17:21

>　例えばこのメールも、自動折り返し無しで配信されてると思います。
これでほぼなにも気にせず、折り返し無しでの運用ができます。ありがとうございま
した。

RE:02253 自動折り返し関係の仕様変更案＆

suii さん　17/10/23 17:41

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

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

RE:02280 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/23 18:10

> 追加質問ですが、送信が「72桁で折り返し」オフのとき、手動の改行はできるの
> ですよね？

　もちろん出来ます。

> 受信メールについて

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

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

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

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

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

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

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

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

　コマンド名が変わるだけで、実質的には現状の秀丸メールと機能的に不足は無いと
思います。

RE:02283 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/23 18:13

　手元の暫定版では引用行の折り返し桁数79桁固定にしてしまってましたが、

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

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

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

　メール本文の折り返し桁数の「72」をカスタマイズする機能は今のところ廃止とい
う方向にさせていただきます。たぶんここもカスタマイズされてる方は、そもそも的
に、新しい「折り返し無し」のモードで使っていただけると思うので。

RE:02284 自動折り返し関係の仕様変更案＆

K'zawa さん　17/10/23 20:22

秀まるおさん、こんにちは。
K'zawaです。

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

はい、こちらとしてはそれでＯＫです。

RE:02253 自動折り返し関係の仕様変更案＆

usagi6502 さん　17/10/24 08:05

お世話になります。

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

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

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

usagi6502

RE:02288 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/24 10:13

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

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

　そもそも的に仕様変更するといっても、、バージョンアップでインストールした場
合は何も変化は無いはずになります。見た目上で、「表示」メニューの「自動折り返
し」が「72桁で折り返し」って名前に変わってるだけの予定です。（細かい所は別に
したら）

RE:02289 自動折り返し関係の仕様変更案＆

usagi6502 さん　17/10/24 12:55

お世話になります。

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

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

usagi6502

RE:02292 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/24 16:35

　$(SmallRootHeader)の場合、現状は72桁で自動折り返し処理してて、それは次のβ
版でも同じです。

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

　例えば、

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

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

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

RE:02294 自動折り返し関係の仕様変更案＆

usagi6502 さん　17/10/25 07:46

お世話になります。

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

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

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

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

usagi6502

RE:02253 自動折り返し関係の仕様変更案＆

sgsano さん　17/10/28 17:22

一点質問させてください。

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

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

--
さの

RE:02326 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/29 09:31

　format=flowedで送る方式もあって、Thunderbirdはその方式なんですが、format=f
lowedの仕組みは英語のメールの場合はいいんですが、日本語のメールだとあんまり
仕様的に良くないというか、メールクライアントの解釈がはっきりしない点があって
良くないかなぁという気がしてやめました。というか、実際Thunderbirdさんの動作
がおかしいです。

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

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

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

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

　もう本当に古い古いメールクライアント（base64の解釈が出来ないメールクライア
ント）があれば「読めない」っていう話が出てくると思いますけども、さすがにスマ
ホ全盛の現代でそういうことは無いだろうと思います。

RE:02330 自動折り返し関係の仕様変更案＆

Iranoan さん　17/10/29 17:42

秀まるお2さん今日は、Iranoan です
> 　もう本当に古い古いメールクライアント（base64の解釈が出来ないメールクライ
>アント）があれば「読めない」っていう話が出てくると思います
まさしく私が普段使っている環境がこれなのですが、特殊な環境だし、自己対処でき
るので今までスルーしていました
これを踏まえて、
> 　base64エンコードして送る方式だと、そういう、メールクライアント毎に異なる
>動作も無いので、そっちの方が安心かなぁと思いました。実際、Windows10の「メー
>ル」アプリはbase64エンコードで送ってくるし、スマホのメールアプリもbase64かq
>uoted-printableかのどっちかでエンコードかけて送ってきてるみたいです。（調べ
>た限りは）
についてですが、添付ファイルは base64 が多いですが、本文は quoted-printable
の方が多い印象が有ります
その為、なぜ base64 にしたんだろう? という印象は有ります

RE:02339 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/30 09:16

　iPhoneから届くメールは、同じ人からのメールでもなぜかquoted-printableとbase
64の２種類あったりするみたいで、どういうルールになってるのかちょっと分かりま
せん。

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

　quoted-printableでもbase64でもどっちでもいいんですが。実はメール本文をquot
ed-printableでエンコードする処理はまだ秀丸メールに存在してないので、既存の、
バグの枯れてる処理を使うとしたら、base64の方がいいというだけだったりします。

RE:02340 自動折り返し関係の仕様変更案＆

Iranoan さん　17/10/30 20:47

秀まるお2さん今日は、Iranoan です
> 　iPhoneから届くメールは、同じ人からのメールでもなぜかquoted-printableとba
>se64の２種類あったりするみたいで、どういうルールになってるのかちょっと分か
>りません。
>
> 　Windows10の「メール」アプリはbase64固定みたいです。
base64 の方がエンコード後のデータ量が少ないので、こちらが主流になってくるん
ですかね

> 　quoted-printableでもbase64でもどっちでもいいんですが。実はメール本文をqu
>oted-printableでエンコードする処理はまだ秀丸メールに存在してないので、既存
>の、バグの枯れてる処理を使うとしたら、base64の方がいいというだけだったりし
>ます。
解りました
個人で対応できる範囲なので、このままで構いません

RE:02270 自動折り返し関係の仕様変更案＆

Iranoan さん　17/10/31 11:37

秀まるお2さん今日は、Iranoan です
> 　１行の長さが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 自動折り返し関係の仕様変更案＆

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 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/10/31 13:48

　問題のメールの受信ログのbase64エンコードされた本文を個別に（秀丸エディタ用
に自分で作った変換モジュールで）デコードしたら、状況理解しました。

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

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

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

　コミュニテックスのシステムの方で修正させていただきます。

RE:02357 自動折り返し関係の仕様変更案＆

Iranoan さん　17/10/31 14:47

秀まるお2さん今日は、Iranoan です
> 　charset=iso-2022-jpとしてるにも関わらず、デコードされた内容がShift-JISに
>なってしまってました。
>
> 　これは、すみませんがうちのコミュニテックスの方のバグになります。
結果的にフォーラム違いでしたね(^_^;;

RE:02360 自動折り返し関係の仕様変更案＆

秀まるお2 さん　17/11/01 07:51

　今、うちのサーバーの該当モジュールを入れ替えて再起動しました。

　ありがとうございます。