― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 53 件の記事 ]  ページ移動 1つ前へ  1, 2, 3, 4  次へ
作成者 メッセージ
投稿記事Posted: 2020年12月11日(金) 14:12 
皆さま。。。。
先ほどのソース、Content typeの違いは元々のメールが違うから当然、ということでしょうかね。

実は、ノートPCに68.12.1をダウンロードしサーバー設定を行いました。
今はデスクトップの78.5.1と両方で送受信できるようにしています。
顧客への返信だけでなく、CCに入っている同僚や、同僚への転送時に同じ現象が発生していることが分かったので検証中です。同僚2名ともWindows Live Mail 2012です。

1) 本日受信したメール(A1)をノート(68)、デスクトップ(78)でそれぞれ同僚に転送しました。(A2-68) (A2-78)
2) 本日受信したメール(B1)を同様に別の同僚に転送しました。(B2-68) (B2-78)

同僚の画面で確認すると、(A2-68)(B2-68)は引用部が正常に表示され、(A2-78)(B2-78)は引用部が無くなっていました。しかし、同僚PCから(A2-78)(B2-78)を私に返信してもらうと、私のPCではすべての引用が表示されます。(A3-78)(B3-78)

原因究明できるでしょうか?

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月11日(金) 16:04 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
Ponta さん、EarlgreyTea です。
今日はたまたま休みなのでこんな時間に返信します。

Ponta さんが書きました:
(b) 先方がメールA(1)を送信->Pontaさんが受信して10/27にA(2)を返信
  先方がメールB(1)を送信->Pontaさんが受信して11/4にB(2)を返信
です。

そうしますと、10/27 や 11/4 という日付に特に意味はないわけですね。

Ponta さんが書きました:
顧客から受信画面のキャプチャをもらいました。ソースは、自分のPCの「送信済みトレイ」のメールを確認しました。

重要な「どの時点で」が抜け落ちています。
「受信画面のキャプチャ」は先方での症状の理解には役立ちますが、どの時点でメールソースの欠落が生じたのかはわかりません。
Ponta さんの11/4返信メール時点で欠落を生じさせたのだとすれば、
元の受信メールのソースがきっかけになるわけですからそれを確認しないと意味がないです。
そもそも「引用されるべき元の文が消えている」の指してる意味があいまいで、齟齬を生じさせています。
元の受信メールでソースの欠落が生じているなら、欠落の直接の犯人は先方のWindows Live メールですし、
そうでないなら Ponta さんの Thunderbird です。
どちらでしょうか?

Ponta さんが書きました:
現時点ではサンプル数はそれぞれ各1通のみです。

それでは「たまたま」の可能性があり、「68から78に更新されて今回の問題が発生したような気がします」というのは予断になります。
たまたまでないと結論付けるには、それぞれ「最低3件」は必要だと思います。

Ponta さんが書きました:
取り急ぎ、ソース比較です。違う部分がありました。

multipart の構造に関して抜き出していただいたようですが、私が知りたかったのはそこではないです。
ちなみに、11/4返信の方は「multipart/mixed」なので添付ファイルが付いていたのでしょう(情報が少なすぎてそれ以上はわかりません)

本件で問題となっているのは引用部分が消失(もしくは表示できないだけ?)していることのはずです。
私が申し上げた「構造」はあくまで本文中の引用部分のことでして、
Thunderbird だったら
コード:
On 2020/12/11 XX:XX, hoge@fuga.co.jp wrote:
> 2回目のメール本文
>
> On 2020/12/11 XX:XX, hoge@fuga.co.jp wrote:
>> 1回目のメール本文
>>
>
という具合ですし、Outlook とかだと
コード:
-----Original Message-----
From: piyo <foo@bar.co.jp>
Sent: Friday, December 11, 2020 X:XX PM
To: hoge@fuga.co.jp
Subject: メール件名

元メール本文
という具合です。

そういう引用の構造がどういう書式になっていて、どういう違いが症状に結びついているのかが知りたいわけです。

Ponta さんが書きました:
同僚の画面で確認すると、(A2-68)(B2-68)は引用部が正常に表示され、(A2-78)(B2-78)は引用部が無くなっていました。しかし、同僚PCから(A2-78)(B2-78)を私に返信してもらうと、私のPCではすべての引用が表示されます。(A3-78)(B3-78)

つまりどういうことでしょう。
Windows Live メールの画面表示では引用部分が表示されないけど、メールソースでは消失していないということが確認されたということでしょうか。
Windows Live メールでも Outlook とは違ってソースを確認できるはずですし、状況の整理をお願いいたします。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月11日(金) 17:57 
EarlgreyTea 様

色々と私の表現が曖昧なようで申し訳ないです。
ソースは欠落していません。受信側のLive Mail でも確認済みです。
あくまでも私がThunderbirdで返信もしくは転送したメールをWindows Live Mailを使っている人が開くと引用部分が先方で画面に表示できないだけです。
ですので、受信者が私に再度返信した場合、当方では過去の引用部分が全て表示されます。

別スレで書いたように、本日ノートPCとデスクトップを使ってThunderbirdのバージョン違いで実験しました。すべて同じ結果です。68で返信または転送したメールは受信側のLive Mailでちゃんと表示されます。
78で返信または転送したメールは引用部が表示されません。(ソースはちゃんとありますが、画面に表示されません)

これで、例は3件です。なので、新バージョンでの返信、転送時に68では起きなかった何かが起きているのではないでしょうか?多分、偶然ではないと思います。

よろしくお願いいたします。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月11日(金) 19:03 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
Ponta さんが書きました:
これで、例は3件です。なので、新バージョンでの返信、転送時に68では起きなかった何かが起きているのではないでしょうか?

では、その何かを同じメールを78系と68系で返信したソースを比較して見つけてください。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月11日(金) 21:25 
オフライン

登録日時: 2013年5月19日(日) 13:46
記事: 1928
Ponta さん、maji です。

EarlgreyTea さんが書きました:
multipart の構造に関して抜き出していただいたようですが、私が知りたかったのはそこではないです。
(中略)
本件で問題となっているのは引用部分が消失(もしくは表示できないだけ?)していることのはずです。
私が申し上げた「構造」はあくまで本文中の引用部分のことでして、
(中略)
そういう引用の構造がどういう書式になっていて、どういう違いが症状に結びついているのかが知りたいわけです。

同感です。

今回の場合、

 ・Ponta さんが Thunderbirdで作って送ったメールは
  相手側 Windows Live メールでは
  ちゃんと引用部分まで届いているが画面上では見えなくなっている

みたいですが、
もしそうならば、
その「見えてる部分」と「見えなくなってる部分」の境い目の部分のソースが見れれば
何かヒントが見つかるかもしれません。

そのあたりがまだ提示いただけていないので
私はもう少し静観します。

では。

【編集追記】 2020/12/12(土)早朝、誤記を一箇所だけ修正編集しています。
      指摘いただいた EarlgreyTea さん、ありがとうございました。

_________________
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0


最後に編集したユーザー maji [ 2020年12月12日(土) 03:00 ], 累計 1 回

通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 01:32 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
maji さんが書きました:
その「見えてる部分」と「見えなくなってる部分」の境い目の部分のソースが見れれば
何かヒントが見つかるかもしれません。

同感です。

maji さんが書きました:
そのあたりがまだ提示いただけていないので
私はもう少し静観します。

私も今できることはないですね。
ちなみに Thunderbird 68 と 78 でシンプルにメール返信したソースを比較してみましたが、
メールごとにユニークとなる部分やUser-Agent以外での差異は全くありませんでした。


ところで maji さん
別トピックの方の名前と取り違えてる気が…

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 06:35 
maji様、EarlgreyTea様

私の知識不足、理解不足で必要な情報を出せずにおりじれったい思いをさせていること、お詫びします。お恥ずかしい限りです。。。
maji さんが書きました:
その「見えてる部分」と「見えなくなってる部分」の境い目の部分のソースが見れれば
何かヒントが見つかるかもしれません。


お二人とも同意見ですし、本日会社に行って、じっくりソースを比較してみます。
EarlgreyTea さんが書きました:
ちなみに Thunderbird 68 と 78 でシンプルにメール返信したソースを比較してみましたが、
メールごとにユニークとなる部分やUser-Agent以外での差異は全くありませんでした。

ということは私も同じ結果が予想されますね。。。あぁ、参った。

お二人のご厚意を無駄にしないため、本当ならソースを全部公開すれば早いのでしょうが、私の技量ではどこを伏字にすべきなのか自信がありません。今日は会社は休日なので、じっくり時間をかけてソースを比較しようと思っています。
念のための確認です。今日比較しようと思っているソースは下記の通りですが、これで大丈夫でしょうか?
1)私が返信または転送したメール(私の送信トレイ内)(68系と78系)
2)受信側である同僚のLive Mailの受信メール(68系と78系)

よろしくお願いします。

_________________
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 13:42 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
Ponta さんが書きました:
お二人とも同意見ですし、本日会社に行って、じっくりソースを比較してみます。
Ponta さんが書きました:
今日は会社は休日なので、じっくり時間をかけてソースを比較しようと思っています。
念のための確認です。今日比較しようと思っているソースは下記の通りですが、これで大丈夫でしょうか?
1)私が返信または転送したメール(私の送信トレイ内)(68系と78系)
2)受信側である同僚のLive Mailの受信メール(68系と78系)

あれ?土曜出勤ということでなく、わざわざ本件の調査のために会社に行かれているのでしょうか。
お疲れさまです。
そして、さすがに土曜日の朝からフォーラムチェックしていなくて申し訳ない。

それで、同僚さんのWindows Liveメールを見ることが可能なのでしょうか。

そうであれば、
(1) まず、画面上で見えなくなっている引用部分のソースがどうなっているかを調べてください。
どういうソースになっていた場合に表示されないかを特定するわけです。

(2) 次に、それを踏まえたうえで、Thunderbird 68 と 78 で返信した場合のソースに違いがあるかを調べてください。

ざっくり、こういう方針でお願いします。

私は (1) を調べることができませんので、予想外の箇所が原因となっていて (2) において見落としている可能性もあります。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 14:28 
お二人ともありがとうございます。
蛇足ですが、実は会社が歩いて10分以内なのでこんな時は融通が利くのです。

さて、新しいことがわかりました。

まず、「見えてる部分、見えなくなっている部分の境い目」には違いはありませんでした。
ただ、「画面上で見えなくなっている引用部分のソース」にも違いは無かったのですが、ヘッダーに違いがありました。

Thunderbird 68
Content-Type: text/plain; charset=windows-1252; format=flowed
Thunderbird 78
Content-Type: text/plain; charset=utf-8; format=flowed

フォントが違っているようです。

取り急ぎここまでご報告です。

今しばらくソース比較をしてみます。よろしくお願いします。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 15:27 
追加です。

そもそものお客からのメールのヘッダーは
Content-Type: text/plain; charset="us-ascii"
でした。
それを68で返信なり転送すると
Content-Type: text/plain; charset=windows-1252; format=flowed
となり、
78で返信、転送すると
Content-Type: text/plain; charset=utf-8; format=flowed
となって問題が発生しています。

また、同僚が、問題が起きた後でも過去の引用が全部見れる、と言っていた会社があるのを思い出しました。
確認してみると、元々のお客からのメールは
Content-Type: text/plain; charset="UTF-8"
私の返信メールは
Content-Type: text/plain; charset=utf-8; format=flowed
となっています。

もしかして、文字コードの変換で何か起きているのではないでしょうか.....

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 15:32 
Ponta さんが書きました:
もしかして、文字コードの変換で何か起きているのではないでしょうか.....


すみません、
もしかして、受信側であるLive Mailでの文字コード変換で何か起きているのでは?
の意味です。わかりにくくてすみません。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 16:05 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
Ponta さんが書きました:
そもそものお客からのメールのヘッダーは
Content-Type: text/plain; charset="us-ascii"
でした。
それを68で返信なり転送すると
Content-Type: text/plain; charset=windows-1252; format=flowed
となり、
78で返信、転送すると
Content-Type: text/plain; charset=utf-8; format=flowed
となって問題が発生しています。

これは厄介な問題ですね。
charset="us-ascii" とか charset=windows-1252 と書かれていても
メール本文はラテン文字以外の日本語を含めて書かれているのですよね。
本文は実際はどの文字セットで書かれているのでしょう。
あと、Content-Transfer-Encoding: も Content-Type: とセットで確認してください。

実際の文字セットを確認するには、メールを選択して「メッセージを保存」して .eml ファイルに保存してください。
それを Mery とか TeraPad のようなテキストエディターで開いていただければ確認できるかと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 17:23 
EarlgreyTea さんが書きました:
メール本文はラテン文字以外の日本語を含めて書かれているのですよね。

海外の取引先なので、私の返信も含め全て英語です。

EarlgreyTea さんが書きました:
あと、Content-Transfer-Encoding: も Content-Type: とセットで確認してください。

大元の顧客からのメールは
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
私からの同僚への転送メール68系は、送信元(Thunderbird)、受信側 (Live Mail)とも
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
私からの同僚への転送メール78系は、送信元(Thunderbird)、受信側 (Live Mail)とも
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
となっています。

EarlgreyTea さんが書きました:
本文は実際はどの文字セットで書かれているのでしょう。
実際の文字セットを確認するには、メールを選択して「メッセージを保存」して .eml ファイルに保存してください。
それを Mery とか TeraPad のようなテキストエディターで開いていただければ確認できるかと思います。

TeraPadで開きました。
大元の顧客からのメールは SJIS
私からの同僚への転送メール68系は、送信元(Thunderbird)、受信側 (Live Mail)とも SJIS
私からの同僚への転送メール78系は、送信元(Thunderbird)、受信側 (Live Mail)とも UTF-8N
となっています。

よろしくお願いいたします。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 19:25 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4063
Ponta さんが書きました:
海外の取引先なので、私の返信も含め全て英語です。

そういう重要なことは最初に書いてほしいです。
今までずっと日本語メール前提で考えていました。

Ponta さんが書きました:
TeraPadで開きました。
大元の顧客からのメールは SJIS
私からの同僚への転送メール68系は、送信元(Thunderbird)、受信側 (Live Mail)とも SJIS
私からの同僚への転送メール78系は、送信元(Thunderbird)、受信側 (Live Mail)とも UTF-8N
となっています。

日本語前提の質問だったので確認方法が少し不適切でしたね。
TeraPad はデフォルト Shift_JIS の古い仕様の日本語エディターなので、SJIS になってるのは半角英数なのでしょう。
UTF-8N の方は TeraPad がどういう判断をしてるかは不明ですが、7bit の範囲に収まらない文字が含まれていた可能性があります。
もしそうだとすると、

Ponta さんが書きました:
私からの同僚への転送メール78系は、送信元(Thunderbird)、受信側 (Live Mail)とも
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

というのは問題かもしれません。
あ、でも文字化けや欠けが生じていたわけじゃないんですよね。

とりあえず、Thunderbird の「フォントと文字エンコーディング」の設定で、対象言語とかテキストエンコーディングを先方に合わせて設定してみてはいかがでしょう。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2020年12月12日(土) 23:12 
EarlgreyTea さんが書きました:
そういう重要なことは最初に書いてほしいです。
今までずっと日本語メール前提で考えていました。

ご指摘の通りです...すみませんでした...

EarlgreyTea さんが書きました:
あ、でも文字化けや欠けが生じていたわけじゃないんですよね。

その通りです。

EarlgreyTea さんが書きました:
とりあえず、Thunderbird の「フォントと文字エンコーディング」の設定で、対象言語とかテキストエンコーディングを先方に合わせて設定してみてはいかがでしょう。

ありがとうございます。月曜出社後に検証に入ります。ただ、14日月曜は仕事がかなり立て込んでおり検証に充分時間を割けるかどうかわかりません。ご報告が遅くなり、最悪火曜日にずれ込むかもしれません。なんだか光が見えてきているような気がしますので決して途中で投げ出したりしません。もしも私の返信が遅くてもそういう事情ですので、どうか最後までご教授お願いします。

根本的な解決にはなりませんが、
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
で送ってくる海外の顧客に、「UTF-8で送信」するようお願いすれば、今の設定のままでも Live MailでCC受信する同僚も引用が読めて、とりあえず問題は解決するのかな?とも思います。
いや、本当は、我社で未だLive Mailの使用を許している所が大問題なのですが...

_________________
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36 OPR/72.0.3815.400


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 53 件の記事 ]  ページ移動 1つ前へ  1, 2, 3, 4  次へ

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[108人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean