秀Term Evo での行抜けNo.01111
tsuka さん 98/07/26 20:30
 
  秀TermEVO (Ver. 4.35) を使っています。まれなケースとは思いますが、
以下のような事象に出くわしました。

  送信側が、復帰改行コード("0D0A")または、改行コード("0A")ではな
  く、復帰コード("0D")のみの入った行を送ってくると、その行が前行
  の先頭にかぶってしまいます。

    例えば、以下のテキストを送信したとします。

      東京に住んでいる人が、福井にいる母のために祈っても、"0D"
      潜在意識が感応すれば治癒が起こる。"0D0A"潜在意識は時として
      奇跡的なことを引き起し、"0D0A"東京の息子を喜ばせる。

    これは、送り手の意図としては次のようです。

      東京に住んでいる人が、福井にいる母のために祈っても、(改行)
      潜在意識が感応すれば治癒が起こる。(改行)
      潜在意識は時として奇跡的なことを引き起し、(改行)
      東京の息子を喜ばせる。

    ところが、実際には以下のようになってしまいます。

      潜在意識が感応すれば治癒が起こる。のために祈っても、(改行)
      潜在意識は時として奇跡的なことを引き起し、(改行)
      東京の息子を喜ばせる。

  つまり、復帰コードのみの場合、秀Termがラインバッファ上で、行頭に
復帰し、一行が完了しないとみなすために生じるようです。
  小生宛のメールは、受け取ったものを自作スクリプトにて送り手ごとに
分類したディレクトリに自動ファイルしているのですが、この事象に出く
わして行抜けが発生してしまい、困ってしまったのです。海外から定期送
信されてくるものに最近、このようなケースがあり、かの国でも送信メー
ラーは復帰改行が通常なのですが、まれに復帰コードのみというのがある
みたいです。
  最初は、NiftyServeからの送信速度に受信速度が追いつかないケースか
と思い、秀Termの設定を変えたり、いろいろやってみたのですが、上記の
ケースであると判明し、現在はスクリプトで工夫して自動ファイルされる
のは行抜けがなくなりましたが、秀Termの表示画面上とストックファイル
上は行抜けしたままです。受信記録としての信憑性が薄れています。
  こんなメールを送ってくる方が問題なんでしょうが、秀まるおサン、何
とかなりませんかねぇ。

[ ]
RE:01111 秀Term Evo での行抜けNo.01113
斉藤秀夫 さん 98/07/28 12:25
 
 改行コードですが、0Dの場合、カーソルは行頭に移動するだけで、スクロールアッ
プはしません。これは通信ソフトならどれも同じでして、秀Termだけ違う動きをする
訳ではないです。

 ただし、「受信時 CR->CR+LF変換」をonにしておけば、0Dを受信しただけでもちゃ
んとスクロールアップするようになります。

 0Dの改行と0D0Aの改行をまぜて送ってくるような場合には、少なくとも秀Term、と
いうか、通信ソフトで受信する以上は正常に表示することはできないです。

 送り側の人に対処してもらうしか無いと思います。


[ ]
RE:01113 秀Term Evo での行抜けNo.01114
tsuka さん 98/07/28 19:38
 

> 改行コードですが、0Dの場合、カーソルは行頭に移動するだけで、スクロールアッ
>プはしません。これは通信ソフトならどれも同じでして、秀Termだけ違う動きをする
>訳ではないです。
>
> ただし、「受信時 CR->CR+LF変換」をonにしておけば、0Dを受信しただけでもちゃ
>んとスクロールアップするようになります。
>
> 0Dの改行と0D0Aの改行をまぜて送ってくるような場合には、少なくとも秀Term、と
>いうか、通信ソフトで受信する以上は正常に表示することはできないです。
>
> 送り側の人に対処してもらうしか無いと思います。
>
ご指摘の状況は分かっています。
ただ、e-mailer (例えば、IE4.0)などで受ける分には問題ないのです。
送り手に対処してもらえばそれに越したことはありませんが、少なくとも、他の
通信ソフトは、0Dのみのケースは0Dを削除しているみたいで0D0Aで初めて改行
としているようです。多分にこれは、謝ったケースでも通信の確実性から、送信
文字列を保証するという思想からきていると思われます。
秀TERMの「受信時CR->CR+LF変換」をONは一つの解決策です。ですが、この場合
0D0A行は 2行の改行となってしまい、非常に間延びしたテキストとなってしまい
これも不自然です。
やはり、0Dのみの行は0Dを削除するのがベターと考えています。実際、スクリプト
でキャラクタ毎の受信としておき、キャラクタ毎にこの判定を入れて処理すると
なんら不都合はありません。でも、この場合でもストックファイルは、0Dを行頭
に戻してしまうので、受信内容を欠落したように見せてしまいます。規約から
すれば、秀TERMの処理が正しいとも思ってはいますが、通信の送り手の意図を
欠落させないと、いう考え方に立てば、柔軟な解釈がなされてもよいのでは ?
とも考えています。いかがでしょうか。

[ ]
RE:01114 秀Term Evo での行抜けNo.01115
斉藤秀夫 さん 98/07/29 09:44
 
 0Dを受信した時の動作を変えてしまうことはさすがにできないですけど、しいて
秀Term側で対処するとすれば、[0Dのみを改行扱いして、0Aは無視する] という
新しいモードを用意することになると思います。

 って、0Dは改行の意味で届く訳ですよね?


[ ]
RE:01115 秀Term Evo での行抜けNo.01116
範子 さん 98/07/30 01:06
 

> 0Dを受信した時の動作を変えてしまうことはさすがにできないですけど、しいて
>秀Term側で対処するとすれば、[0Dのみを改行扱いして、0Aは無視する] という
>新しいモードを用意することになると思います。

ログには意図したとおり出力するスクリプトを書く技術はもってらっしゃるよう
なので、

画面表示は、display offとwritebuffer2を使っておんなじ用にしていただ
くという手もあります。そうすると、ストックファイルも表示したようになる
はずです。

というか、改行コードが混在するなんて尋常でないデータの処理なんかは、
スクリプトですきかってするに限るという気がします。

[ ]
RE:01116 秀Term Evo での行抜けNo.01117
斉藤秀夫 さん 98/07/30 10:17
 
 範子さんご指摘の通り、スクリプトで正しく表示させることは可能みたいです。

 たとえばこんな感じです。(テストしてないけど)

    loopswitch
        case "^M"
            writebuffer "^M^J"
        case "^J"
            writebuffer "^01B[A"
    endloop

> 画面表示は、display offとwritebuffer2を使って

 この方法がある訳ですが、getline文では最後のプロンプト待ちをうまく検出する
のが難しいと思います。


[ ]
RE:01117 秀Term Evo での行抜けNo.01121
tsuka さん 98/08/01 10:32
 

> 範子さんご指摘の通り、スクリプトで正しく表示させることは可能みたいです。
>
> たとえばこんな感じです。(テストしてないけど)
>
>    loopswitch
>        case "^M"
>            writebuffer "^M^J"
>        case "^J"
>            writebuffer "^01B[A"
>    endloop
>
>> 画面表示は、display offとwritebuffer2を使って
>
> この方法がある訳ですが、getline文では最後のプロンプト待ちをうまく検出する
>のが難しいと思います。
>
秀まるおサンのご指摘どおり、getlineではだめですね。ちなみに、スクリプトは
getchar で一文字受信しては、一旦、"0D" も "0A" も削除 (""ヌル) にして、
"0A"で一行の終了としています。一行検出でファイルライトしています。
上記の秀まるおサンのスクリプト例を参考に、仕込んでみます。ありがとうござ
いました。

[ ]