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



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 8 件の記事 ] 
作成者 メッセージ
投稿記事Posted: 2016年2月01日(月) 11:30 
お世話になります。
fa-panelというグラフィックソフトでメールソフト(Thunderbird VER38.5.1)でメールを受信したところ
件名の後にサイコロの4のようなマークが表示されました。マークの意味、原因やマークを非表示する方法などありましたらご教授おねがいいたします。
(他のメールソフト(windows liveメッセンジャー)ではマークはでませんでした。)

fa-panelサイト
http://www.roboticsware.co.jp/ver5/fapanel5.htm




























_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月02日(火) 08:09 
※質問するときは、「フォーラムの利用に関するご案内」、とりわけ「質問するときは」に目を通し、OS の種類や Thunderbird のバージョン、アカウントは IMAP か POP かといった使用環境についての最低限の情報を書き添えることをお勧めします。

fa123 さんが書きました:
fa-panelというグラフィックソフトでメールソフト(Thunderbird VER38.5.1)でメールを受信したところ

そのグラフィックソフトと Thunderbird の関係がよくわかりませんが、Thunderbird のメールアカウント(おそらく IMAP ?)で起こっていることですよね。(関連=後述補足)

ご質問の「サイコロの4のようなマーク」というのが、スレッドペインの件名欄では表示され、下のヘッダビューの件名欄では表示されていませんので、Thunderbird の内部では、msf ファイルに固有の問題である可能性が考えられそうです。
一方、後述のように、こうした文字データが表示されること自体にそもそもの問題があるという側面も考えられます。

添付画像でお示しの「サイコロの4のようなマーク」と仰っているいるのは、Unicode の U+0000 、つまり NUL のようです。
Unicode 文字が「サイコロの4のようなマーク」として表示されるのは、それを表示するデバイスやアプリケーションが、Unicode の文字だとは認識できているけれども、表示用に指定されているフォントがその字形を持っていない場合に、コードで表示されるものだったと思います。
しかしながら、NUL は空文字を意味する制御文字の一種なので、通常は画面に表示されることはなかったようにも思います。
(参考)・Unicode一覧 0000-0FFF - Wikipedia
https://ja.wikipedia.org/wiki/Unicode%E ... _0000-0FFF
(参考)・制御文字 - Wikipedia
https://ja.wikipedia.org/wiki/%E5%88%B6 ... 7%E5%AD%97

ごく普通に考えて、デスクトップ環境で電子メールを作成するときは、キーボードから文字を入力すると思います。その条件下で NUL が入り込むことは通常は考えられません。仮に何かの事情で NUL が含まれてしまったとしても、本来は空文字なので目視できる形で表示されないと思います。

「自動通報メール」「Alarm」などの件名から推測して、サーバーなどから自動送信されるメールでしょうか?
もしそうだとしたら、その自動送信プログラムの中で定義された「件名」(Subject)の中に、NUL が含まれていて、そのままメールの件名に入り込んでいるのかもしれません。

Thunderbird 38.5.1 で件名を「自動通報メール」(カギカッコは除く)としてメッセージを作成すると、Subject ヘッダのソースは次のようになります。
Subject: =?UTF-8?B?6Ieq5YuV6YCa5aCx44Oh44O844Or?=

fa123 さんが受信なさった「自動通報メール」のメールヘッダのうち、Subject: の項目ははどうなっていますでしょうか。
メッセージソースを表示したいメールを選択し、キーボードの [Ctrl] + [U] でメッセージソース画面が開きます。画像も公開されていますし、差し支えのある件名とは思えないので、上記のようにソースを提示してみてください。フォーラムを見ているユーザーさんたちに検証してもらう機会が作れます。

もし、件名に余分な文字データが入り込んでいるのだとすれば、送信者に問い合わせたほうがいいと思います。とくに自動送信であれば、そのプログラムソースを取り扱える人に状況を認識してもらったほうが、事実関係が明確になるのではないかと思います。

(補足)
fa123 さんが書きました:
(他のメールソフト(windows liveメッセンジャー)ではマークはでませんでした。)

単純な誤記かもしれませんが、Windows Live Messennger というのは、電子メールとは異なるインスタントメッセンジャー用のソフトウェアとそのサービス名です。現在は Skype に統合されて同名のサービスは存在しません。
もしかしたら Windows Live Mail の間違いでしょうか?
それとも「自動通報メール」の内容が、通常の電子メールだけでなく、Windows Live Messennger(あるいはその後継サービス)などのインスタントメッセンジャーでも受信できるような仕組みになっているのでしょうか??

前者の場合、アプリケーションの Unicode への対応度合などに差があると、Unicode 文字の認識や表示にも差が出るので、そういうことなのかもしれません。Thunderbird でも、ヘッダビューの件名欄では表示されていないように見えますので、NUL が存在してもそれをどう扱うか部位によって差があるケースが考えられそうです。

後者の場合、電子メールとインスタントメッセンジャーでは送信側での仕組みや実行手順が異なってくると考えられるので、送信段階でデータ処理に差があれば、表示に差が出るのは必ずしも不自然とはいえないことになります。

気になったのは以上です。的外れな話だったらすみません。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月02日(火) 09:15 
返信ありがとうございます。
windows liveメッセンジャーについては誤記でしたすみません。
Windows Live Mailのことです。

PCのOSはwindows7 Professional Service Pack1 32ビット
メールアカウントはPOP

ヘッダのソースは
Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=

です。確認していただけたらと思います。


状況は、fa-panelというグラフィックソフトのサーバーソフトがあるのですが、イベントが発生したらサーバーソフトからメールを

自動送信します。サーバーソフトの設定としては件名、内容などの情報はメールマスターのテキストを参照し、メール設定はサーバーソフトでおこなっています。設定内容はキャプチャしておきました。

_________________
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月02日(火) 23:55 
fa123 さんが書きました:
ヘッダのソースは
Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=

です。確認していただけたらと思います。

デコードすると「8ea9 93ae 92ca 95f1 8381 815b 838b 00」ですので、余計な「00」が付いてますね。

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


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月03日(水) 00:10 
fa123 さんが書きました:
ヘッダのソースは
Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=

です。確認していただけたらと思います。


状況は、fa-panelというグラフィックソフトのサーバーソフトがあるのですが、イベントが発生したらサーバーソフトからメールを

自動送信します。

本来は「=?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4s=?=」とエンコードされないといけないので、fa-panelのバグだと思います。

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


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月03日(水) 08:24 
fa123 さん、追加情報をありがとうございます。
通りマン さん、検証とご助言をありがとうございます。当方でも同じ内容を確認しました。

問題点は2つあると思います。
(A)ひとつは、送信される件名の問題です。こちらが本筋でしょう。
(B)もうひとつは、それを受信した Thunderbird 内部で、スレッドペインとヘッダビューで件名の表示が異なるという問題です。
(参考)・Thunderbird の各部の一般的な名称
http://meitner.jimdo.com/2015/07/03/thu ... erence-01/

まず(A)について。
fa123 さんが書きました:
ヘッダのソースは
Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=

「自動通報メール」の文字列(カギカッコ除く)を件名にして、Shift_JIS で B エンコーディングした場合、通常は 通りマン さんがご指摘くださったようになります。
【X】Subject: =?Shift_JIS?B?jqmTrpLKlfGDgYFbg4s=?=

しかし、テンプレートになっている件名そのものか、その件名を送信データに挿入する際、末尾に余計なデータが入ってしまうため、
【Y】Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=
とエンコーディングされてしまうのでしょう。
(補足)
些末なことですが...。
冒頭の SHIFT-JIS は、MIME(Multipurpose Internet Mail Extensions)の推奨名としては Shift_JIS であるほうが望ましいです。大文字・小文字の違いはとくに問題ありませんが、アンダースコアとハイフンの違いがあります。
本件とは直接の関係はありませんが、こういう曖昧さがあるということは、お使いの自動送信機能が電子メールの規格にきちんと対応していない可能性を疑う理由にはなりえます。
(一般論としていえば、電子メールの取り扱いが本旨でないソフトウェアに付属している "メール送信機能" の中には、電子メールとしての規格を守っているとは言い難いものがときどき存在します。お使いのソフトウェアがそうだとは断言しませんが、十分に対応しきれていない可能性はあるかもしれません。一方、Thunderbird は電子メールの規格にけっこう厳格に対処しますので、融通がきかないといいますか、わずかの食い違いで問題が起こることがあります。)



次に(B)です。
これは、Thunderbird のメール管理の仕組みに関係がありそうです。

例えば、[受信トレイ] に入っているメッセージ群は添付ファイルのデータを含めて、プロファイル内にある Inbox という拡張子のないファイルに一括して保存されています。この Inbox ファイルがメールデータの実体であり、最重要ファイルです。

これとは別に、Inbox.msf というファイルがあります。これは [受信トレイ] の内容をスレッドペインに表示するためのメッセージリストとその表示条件を保持した一種のサマリーデータです。メールの受信や移動・削除にともなって変化する Inbox ファイルの状態は、随時 Inbox.msf ファイルに反映されます。
そして、スレッドペインに表示されるメッセージ一覧は、Inbox.msf ファイルから読み込まれています。

一方、スレッドペインで選択されたメッセージは下段のメッセージペインに表示されますが、その上部にあるヘッダビューの件名は、Inbox ファイルから直接読み込まれます。
ヘッダビューの件名の末尾に NUL が表示されないのは、NUL が含まれていたとしても空文字として表示しないからだと考えられます。
(Windows Live Mail の表示と同等といいましょうか。他のいくつかのメールソフトで【Y】の Subject を読み込ませても、末尾のデータは表示上無視されています。NUL の本来的な意味としてはそれが正常な表示だと思うのですが...。)

これらの流れから、スレッドペインで NUL がコード表示されることについては、msf ファイルの内容とその取り扱いに疑問が残ります。
この点は、Thunderbird 38.x 系の問題である可能性が疑われますが、詳細はわかりかねます。

しかしながら根本的には、「fa-panelというグラフィックソフトのサーバーソフト」が、「自動通報メール」という件名を【X】のように正しくエンコーディングして送ってくれば、Thunderbird 38.x 系でもご質問のようなことが起こらないのは確かです。

fa123 さんが書きました:
状況は、fa-panelというグラフィックソフトのサーバーソフトがあるのですが、イベントが発生したらサーバーソフトからメールを自動送信します。
サーバーソフトの設定としては件名、内容などの情報はメールマスターのテキストを参照し、メール設定はサーバーソフトでおこなっています。設定内容はキャプチャしておきました。

「メールマスターのテキスト」の書き方に問題があるのかもしれませんし、「メールマスターのテキスト」の参照・引用の仕方に原因があるのかもしれませんが、その「fa-panelというグラフィックソフトのサーバーソフト」の詳細を知りえない身なので、fa-panel 側での解決方法をアドバイスすることはできません。

しいていえば、ユーザー側で試せるのは次のようなことでしょうか。
ご提示いただいた Property 画面の最下段にある [文字エンコード方式] は、切り替えができるようです。これを UTF-8 とか、ISO-2022-JP とかにしてみて、何か変化はあるでしょうか。「メールマスターのテキスト」の文字コードなどにも注意しつつ、いくつか条件を変えてテストしてみてはいかがでしょう。丸くおさまる設定が見つかるかもしれません。(どうしても Shift_JIS でなければならない理由があるなら仕方ないですが、いまどきの日本語メールでは UTF-8 か ISO-2022-JP を使うほうがいいと思います。)

件名のエンコーディングに関しては、通りマン さんが仰っているように fa-panel のバグである可能性が高いので、一度そのソフトのサポート窓口に問い合わせてみることをお勧めしておきます。

追記いただいた情報をふまえ、気がついたのは以上です。的外れな話だったらすみません。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月03日(水) 23:11 
偶然的通行人 さんが書きました:
まず(A)について。
fa123 さんが書きました:
ヘッダのソースは
Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=

「自動通報メール」の文字列(カギカッコ除く)を件名にして、Shift_JIS で B エンコーディングした場合、通常は 通りマン さんがご指摘くださったようになります。
【X】Subject: =?Shift_JIS?B?jqmTrpLKlfGDgYFbg4s=?=

しかし、テンプレートになっている件名そのものか、その件名を送信データに挿入する際、末尾に余計なデータが入ってしまうため、
【Y】Subject: =?SHIFT-JIS?B?jqmTrpLKlfGDgYFbg4sA?=
とエンコーディングされてしまうのでしょう。

エスパーデバッグすると、fa-panelとやらがBase64のエンコード処理手順を以下のように間違っていると思います。

■正しいエンコード処理手順
1. 元データ
文字列:"自動通報メール"
16進表現:8e a9 93 ae 92 ca 95 f1 83 81 81 5b 83 8b
2進表現:10001110 10101001 10010011 10101110 10010010 11001010 10010101 11110001 10000011 10000001 10000001 01011011 10000011 10001011

2. 6ビットずつに分割
100011 101010 100110 010011 101011 101001 001011 001010 100101 011111 000110 000011 100000 011000 000101 011011 100000 111000 1011

3. 4ビット余るので、2ビット分0を追加して6ビットにする
100011 101010 100110 010011 101011 101001 001011 001010 100101 011111 000110 000011 100000 011000 000101 011011 100000 111000 101100

4. 変換表により、4文字ずつ変換
jqmT rpLK lfGD gYFb g4s

5. 3文字余るので、1文字分 = 記号を追加して4文字にする
jqmT rpLK lfGD gYFb g4s=

6. Base64文字列
jqmTrpLKlfGDgYFbg4s=

■間違ったエンコード処理手順
1. 元データ
(省略)

2. 24ビット(6ビット×4文字)ずつに分割 ← ※間違い(正しい手順の4の「4文字ずつ」の部分を2と一緒に処理している)
100011 101010 100110 010011 101011 101001 001011 001010 100101 011111 000110 000011 100000 011000 000101 011011 100000 111000 1011

3. 16ビット余るので、8ビット分0を追加して24ビットにする
100011 101010 100110 010011 101011 101001 001011 001010 100101 011111 000110 000011 100000 011000 000101 011011 100000 111000 101100 000000

4. 変換表により、変換
jqmT rpLK lfGD gYFb g4sA

5. Base64文字列
jqmTrpLKlfGDgYFbg4sA

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


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2016年2月05日(金) 20:13 
通りマン さん、詳しい説明、ありがとうございます。

余計なデータが挿入されるのではなく、エンコーディングの処理手順が間違っていることで、自身で生成してしまうということになりましょうか。
そういうケースは頭に浮かばなかったので、ぼく自身も勉強になりました。ありがとうございました。

あとは、fa123 さんが確認なさったことの結果報告待ち、ということで...。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 8 件の記事 ] 

All times are UTC + 9 hours


オンラインデータ

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


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

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