受信済情報破損時対策	No.32955
hajimett さん　07/12/30 20:03
いつも秀丸メール便利に使わせていただいております さて この度はまた事故対策についてご助言いただきたく サーバにメールデータを残す設定で使っております 別投稿で書きました失策によりどうやら受信済みである旨の情報が 失われてしまったようです サーバにアクセスすると サーバに残っている1万件以上のメールを再度取り込もうとします 最近サーバに来たメールから拾ってくれれば良いのですが 古い順に取り込もうとしますので途方に暮れています せめてある日付以降のメールのみを取り込むなど なんらかの対策を講じたいのですが どうするのが最も簡単な対症療法となりましょうか ご指導いただけると幸いです なお　当方受信済みデータの管理の仕組みは理解しておりませんので 症状から受信済みである旨の情報が破損したと推測しての投稿です よろしくお願いします

[ △ ]

RE:32955 受信済情報破損時対策	No.32956
秀まるお2 さん　07/12/30 20:21
受信済みかどうかの情報は、秀丸メールのデータ用フォルダ配下にあるアカウ ント用フォルダ配下の「UIDL.bin」というファイルで覚えておく仕組みになって います。これは「.bin」という拡張子になってはいますが、中身は単純なテキス トファイルであって、秀丸エディタ等で編集出来ます。 　メールサーバー上に置いてあるメールを受信済みであるかのように処理させる には、メールサーバー上の各メールのUIDL文字列を、このUIDL.binの中に入れて やればいいです。 　具体的なやり方を説明させていただきますと… 　１．リモートメールの一覧取得をします。 　２．アカウント用フォルダ配下のRemoteってフォルダ配下から、秀丸エディタ 　　　のgrepにて、"Turukame-UIDL:"を検索して、その一覧を作成します。 　３．その結果を加工して、UIDLだけの一覧にします。例えば置換コマンドで         検索:  "Turukame-UIDL: "         置換： "" 　　　で全置換する等します。 　４．UIDL.binファイルを開いて、そこに先ほどのUIDL文字列を貼り付けます。 　　　ちなみにUIDL.binファイルの形式としては、「*」があってタブ文字が 　　あって、その後にダウンロードした日付が入り、その次の行からその日 　　ダウンロードしたメールのUIDL文字列が入るというような形式になって 　　ます。日付は、例えば2007/12/30とか、最新の日付にしておいた方がいい 　　と思います。 　５．秀丸メールでもう一度リモートメールを実行して「▼」を押して 　　　「メール一覧を取得しなおす（完全）」とやれば、UIDL.binに書いた 　　　物についてはちゃんとダウンロード済みになると思います。

[ △ ]

RE:32956 受信済情報破損時対策	No.32957
秀まるお2 さん　07/12/30 20:41
grepの結果を置換する時は、ファイル名+行番号も除去しないといけないので、 たぶん、"^.*TuruKame-UIDL: " を""に置換（正規表現ON）するとかしないとダ メでした。 　とにかくそういうことで、うまくUIDL.binファイルを編集すればなんとかなる んじゃないかと思います。

[ △ ]

RE:32957 受信済情報破損時対策	No.32958
hajimett さん　07/12/30 21:11
大変素早いご対応本当に助かりました！ 正規表現の具体的な文字列まで御指南頂きありがとうございました >たぶん、"^.*TuruKame-UIDL: " を""に置換（正規表現ON）するとかしないとダ 大文字小文字を区別する場合は"^.*Turukame-UIDL: " を空白に置換する必要がありました（一応補足情報として） あとは、重複してDLしてしまったメール（千件ほど） をどう処理するかなんですが 受信ログを見るとある一定期間の古いメールをDLしたようなので Date:で検索して絞り込んで確認できるかも知れないと思っていますが なにか合理的な対処方法があるようでしたら御指南下さい 重複メールの確認では、完全に同一なもののみを抽出対象にする ということは出来ないのですよね・・・ ちょっと模索してみます

[ △ ]

RE:32958 受信済情報破損時対策	No.32959
秀まるお2 さん　07/12/30 21:30
> あとは、重複してDLしてしまったメール（千件ほど） > をどう処理するかなんですが 　フォルダ枠中のアカウントの上でマウス右ボタンを押して「重複メールのチェ ック」とすれば、そのアカウント内の全てのフォルダで重複メールチェックをし てくれます。普通はそれでいいと思います。 > 重複メールの確認では、完全に同一なもののみを抽出対象にする > ということは出来ないのですよね・・・ 　Message-IdとDate:ヘッダが同一ならば重複してる扱いになってしまいます。 オプション類も無いです。

[ △ ]

RE:32959 受信済情報破損時対策	No.32960
hajimett さん　07/12/31 07:00
>　Message-IdとDate:ヘッダが同一ならば重複してる扱いになってしまいます。 >オプション類も無いです。 じつは QUALCOMM Windows Eudora Version 7J　からのメールで ＃このメーラに特有の問題かどうかは分かりませんが たぶん再送信という機能があるんだと思いますが その際に、Message-Id:ヘッダが２つついているメールが生成され 最初に送信されたメールと同じMessage-Id:ヘッダが ２行目に付されて送られてきます。 たぶん秀丸メールは 後の方のヘッダを優先して解釈する仕様なんだと思いますが そうすると違う内容（再送信の際に、編集することも出来るし ヘッダも変えることが出来るようです）のメールでも、 同一メールと解釈されてしまいます Date:ヘッダは異なるので同一ではないことは分かるのですが これを不用意に削除してしまうわけにはいかないので、 「1つだけ残す」の一括処理 が出来ずに居ます Message-Id:ヘッダが同一なのにDate:ヘッダが異なるメールというのは どういう場合に生成されるのかよく分かりませんが 上記のような場合もあるので Date:ヘッダが異なるメールについては 一括処理で保留するなどの操作が可能だと嬉しいです 他にDate:ヘッダが異なる場合というのはどういうときに 生成されるのでしょうか 保留されることで不便になる方が多い場合には 上記の希望は取り下げます あと細かなことかもしれませんが 全く同一のメールがあった場合で 既読と未読の違いのみの時 今回たまたまそうなったのかも知れませんが 一括処理で未読の方が残されました 個人的には既読を残す仕様が欲しかったなと思いました あまり贅沢を言っても良くないかも知れませんが ＃そしてあまり処理を複雑にしても良くないと思いますが 複数回受信が生じたケースでは 「既読である」という情報の方が「維持したい情報」 にあたるような気がするのですが如何でしょう ＃使い方は人それぞれでしょうが

[ △ ]

RE:32960 受信済情報破損時対策	No.32961
秀まるお2 さん　07/12/31 14:52
まず、Message-Id:ヘッダが２つ以上あるケースですが、秀丸メールでは、一 番最後に指定されたMessage-Id:ヘッダだけを認識する作りになってしまってま す。これは意図してそうしてる訳ではないですけど、たまたまそうなってしまっ てます。 　今ちょっと試した限りは、Outlook Expressでは一番先頭のMessage-Id:ヘッダ のみが有効になるようです。なので、秀丸メールでもそういう風に修正してみま す。 　（次のバージョンで） 　ちなみにこの認識順序を変更すると、今現在のメール一覧のキャッシュと実際 のメール内容が矛盾してしまってちょっとおかしなことになるかもしれません。 なので、次のβ版を入れてから、一度メール一覧の作成しなおしをやっていただ いた方がいいと思います。 ----------------------------- 　もう１つの、重複メールのチェックについてですが…。重複メールのチェック での「重複したメールかどうか」の判定および「どのメールを残すのか」の判定 基準については、以前にも何度かオプションで選択させて欲しいというような話 がありました。オプションで選択ということになると、実は優先順位的な問題が からんできて、ちょっとややこしいことになります。 　例えば「メールのサイズが大きい方を残す」というルールと「未読の方を残 す」というルールがあった場合に、どっちの優先順位を高くするかとか、そうい う話があります。 　メールのサイズというのは、まったく同一のメールであってもStatus:ヘッダ の違いによってサイズが変わることが多いです。まったく同じメールであっても １回目にダウンロードしたメールは「Status: U」になりますが、２回目以降だ と「Status: RO」になります。そうすると後で受信したメールの方がサイズが１ バイト大きくなります。 　そういう関係で今のところはオプション類が無いですが、実は CheckDuplicationという関数には少々オプションがあったりはします。 　とにかくこれはこれで奥の深い問題であってユーザー様の思うように完全にコ ントロールさせるような仕組みを用意することはほとんど不可能だと思いますけ ど、何かいいアイデアは無いかだけ考えてみます。 　Date:ヘッダが一致してなくてMessage-Id:だけ一致してるメールについては、 重複メールのチャック途中で「それでもかまわず一括処理するか？」みたいな問 い合わせメッセージが出ると思うので、それが出るまで一括処理してみたらいい んじないかと思いますけど。心配でしたら一度メールデータを全部バックアップ してからアカウント上で右クリックして重複メールチェックを一発さくっとかけ てみて欲しいです。それでこの話は終わるかもしれないし。

[ △ ]

RE:32961 受信済情報破損時対策	No.32962
秀まるお2 さん　07/12/31 16:00
っと考えた所でなんですが、次のバージョンで、「重複メールのチェック」を 実行したら具体的にどういうメールを重複メール扱いしてどういうメールを「１ つだけ残す」とするのか指定するダイアログボックスを表示することにします。 そこで条件を指定して「開始！」を押すと重複メールを探すってことにします。 　ダイアログボックスの内容は、今のところ 　+- 重複してるかどうかの判定基準 ------------------- 　|  □ Message-Idが一致している （必須条件） 　|  □ Date:ヘッダが一致している 　|  □ メール本文の内容がほぼ一致している 　|  □ メールの送信系/受信系の種類が一致している 　+-------------------------------------------------- 　*- 「１つだけ残す」で残すメールの決定方法 --------------- 　|  □ メモ付き／マーク付き／優先度:高メールを残す 　|  □ 未読メールを残す         □ 既読メールを残す 　|  □ 添付ファイル付きの方を残す 　|  □ 送信系メールを残す       □ 受信系メールを残す 　|  □ サイズの大きい方を残す   □ サイズの小さい方を残す 　+--------------------------------------------------------          [開始！]      [キャンセル]    [ヘルプ] 　って風にしようと思います。

[ △ ]

RE:32961 受信済情報破損時対策	No.32963
hajimett さん　07/12/31 16:30
>　今ちょっと試した限りは、Outlook Expressでは一番先頭のMessage-Id:ヘッダ >のみが有効になるようです。なので、秀丸メールでもそういう風に修正してみま >す。 >　（次のバージョンで） もしこれでより良い方向に変化すればいいのですが。 もし他のペア（これまで別のメールだと認識されていたもの）が こんどは同一視されるようになったら却って問題になったりしないか すこしだけ気になりますし >　ちなみにこの認識順序を変更すると、今現在のメール一覧のキャッシュと実際 >のメール内容が矛盾してしまってちょっとおかしなことになるかもしれません。 >なので、次のβ版を入れてから、一度メール一覧の作成しなおしをやっていただ >いた方がいいと思います。 ということですと これは私だけの問題ではないと思うのですが 他のユーザ様は大丈夫でしょうか ＋＋＋＋＋＋順序を入れ替えます >　Date:ヘッダが一致してなくてMessage-Id:だけ一致してるメールについては、 >重複メールのチャック途中で「それでもかまわず一括処理するか？」みたいな問 >い合わせメッセージが出ると思うので、それが出るまで一括処理してみたらいい >んじないかと思いますけど。心配でしたら一度メールデータを全部バックアップ >してからアカウント上で右クリックして重複メールチェックを一発さくっとかけ >てみて欲しいです。それでこの話は終わるかもしれないし。 ご助言ありがとうございます。大変助かりました。 一括処理は怖くてしていませんでしたが、 Date:ヘッダ不一致の場合などでは、 一括処理の場合でも処理するか否かの問い合わせが出るんですね。 これは大変親切な仕様です。 CheckDuplication　関数のヘルプにはその旨記載されていますが、 一括処理でどのような場合に警告が出るのかは、 本体のヘルプにも記載される方がよろしいかと存じます。 >　そういう関係で今のところはオプション類が無いですが、実は >CheckDuplicationという関数には少々オプションがあったりはします。 CheckDuplicationに smallretain　オプションがあることがわかりました やはり例外的な処理は出来るだけマクロで対応する方が 本体をこれ以上複雑化させないという意味でも好ましいと思います >　とにかくこれはこれで奥の深い問題であってユーザー様の思うように完全にコ >ントロールさせるような仕組みを用意することはほとんど不可能だと思いますけ >ど、何かいいアイデアは無いかだけ考えてみます。 とのことですが、CheckDuplicationのオプションで サイズ違い以外の他の条件が全く同じ場合は （つまり、優先順位４番目のサイズ違いの選択基準の代わりとして） メール発生順の新しい方を削除する ということが出来るのなら嬉しいです smallretain　オプション　が もし Status:ヘッダ絡みで より古いデータを残すために使われることが多いとしたら、 大きさという間接的な手がかりによる操作よりも むしろ明示的に発生順という概念が利用可能なら かつその定義の仕方も明確にヘルプに記載されているので わかりやすいと思ったんです よろしくご検討下さい ｐｓ どうでも良いことかも知れませんが（本当のトリビアル） CheckDuplication関数（TKInfo.dll）の記述で "yesall"" 　batch" とあるぶぶんは "yesall" 　"batch" ではないかと・・・すみません、本当に些末なことで。

[ △ ]

RE:32962 受信済情報破損時対策	No.32964
hajimett さん　07/12/31 16:36
>　っと考えた所でなんですが、次のバージョンで、「重複メールのチェック」を >実行したら具体的にどういうメールを重複メール扱いしてどういうメールを「１ >つだけ残す」とするのか指定するダイアログボックスを表示することにします。 >そこで条件を指定して「開始！」を押すと重複メールを探すってことにします。 行き違いになってしまいました ご検討いただきありがとうございます 現状の選択パタンがデフォルトで既にチェックされていて 既存のユーザ様は今まで通り変わりなく操作できるようなものであり かつ 変更したらそれが次回の操作に維持されるようなものなら 皆さんにとって使い勝手の良いものになるかも知れませんね

[ △ ]

---