電子メールを外部システムへの入力として使用する場合、本文のみの電子メールをトリミングする方法は?


8

アプリケーションがメールに送信してコメントに返信したり、ToDoを追加したりできるようにする場合、さまざまな標準が存在するため、関連するテキストのみのメールをトリミングすることが問題になります。多くの場合、次のようなものが表示されます。

ジョー、こんにちは。いつ町に戻るか教えてください。
Bobによる投稿、30分前


13日に戻ります。

-
よろしくお願いいたします。JosephR
. Roberts
シニアパートナー

この通信は機密情報であり、Whatever Law Firmの所有物です。
Joeによる投稿、10秒前

署名はおそらく取り除くのが最も難しく、引用されたテキストが最も簡単です。トリミングの包括的な戦略は多面的であり、理想的には学習になると思います。私は良いシステムがすべきだと思います:

  1. 引用された本文を削除
  2. 引用ヘッダーを削除(「10月15日、Joeは次のように書いた:」)
  3. 署名を削除する
  4. 手動で入力したものはすべて保持します。

これを達成するためにシステムはどのような手順を踏む必要がありますか?また、システムが認識すべき落とし穴は何ですか?


この回答は、同様の質問に対する有用な回答の良い例です


解析中に実際の情報を削除する際は注意してください。コンテキストが削除されるため、行を削除するのではなく、破棄/破棄できるものとしてマーク/インデックスを付けたほうがよいでしょう。
Carlo Kuip、2011年

未記述の標準署名区切り文字があり、これは2つのハイフンと1行のスペースだけです。
Blrfl、2011年

ただし、2つのハイフンは必ずしもそれが意味するわけではありません。たとえば、送信者が何かを分割したいが、後半が切り取られた場合などです。それは痛い...
Erica Xu

1
「-」が使用されるのは、eMailソフトウェアは通常、末尾のスペースを破棄するため、.sig区切り文字としてのみ使用する必要があるためです。HTMLおよびMIME全般と同様に、YMMVですが、実際にこれが偶発的に発生することはありません。とりわけ、EvolutionとGmailは「-」解析を行います。
BRPocock 2011

回答:


2

適切にフォーマットされたシグニチャーは、その前にある '-'(ダッシュとダッシュのスペース)の行で簡単に識別できます。多くを見つける幸運。ネチケットは署名が3行以下であることを要求しますが、多くの組織はこれをはるかに超える標準の署名と免責事項を持っています。

適切にフォーマットされた引用テキストは、1つ以上の「>」文字で始まります。これは、データを抽出する本文のプレーンテキストコピーがあることを前提としています。

HTML形式のメッセージには、必要な処理に役立つCSSスタイルが含まれている場合があります。


1

普通のアイレーザーで行うのと同じように、メールをトリミングできます。引用部分と署名は無視してください。

ただし、トリミングが失敗した場合に備えて、必ずコピーを保存してください。または、お客様に最初に数通の電子メールを切り取らせ、彼/彼女の習慣に従うようにすることができます。

どんなに注意深く、思いやりがあっても、私はすべての電子メールがトリミングされた資産であることを確認する方法はないと思います。手動で書かれたいくつかの奇妙なものは切り捨てられます。

(または、メールの記述方法を変更することができます。実際に入力するか、コピーして貼り付けて保存する間にマークを付けます。ただし、この変更には時間がかかる場合があります...)


1

ソフトウェアの電子メールクライアントと人間は電子メールの部分に便利な方法でタグを付けるので、電子メールの迷惑メールを簡単に消去することはできませんが、メッセージを消去するには、まず次のようにします。

応答には、引用符、前後、またはブロック引用符が混在したテキストを含めることができます。場合によっては、あなたが言及したように、いくつかの要素を直接クリーンアップすることができます:

  • 非表示のヘッダー。
  • 主要な電子メールクライアントからのヘッダーの転送と返信
  • 主要な電子メールクライアントからの引用

それほどではありませんが、出発点です。

これを改善するには、メッセージをスレッドごとにチェーンし、gitがソースコードに対して行うのと同様の方法でdiffアルゴリズムを使用します。

電子メールメッセージには、返信をチェーンして転送するために使用できる非表示のヘッダーがあります。これを使用すると、会話の有向グラフをマウントできます。これがどれほど信頼できるかはわかりませんが、多くの会話がグループ化されると思います。多くのリストサーバーには「スレッド」ナビゲーションがあり、うまく機能します。メッセージがそのようにチェーンされていると思います。

同じソースからの電子メールを直接比較して署名を分離することにより、これを改善できます。

自動署名は、同じソースからのほとんどの電子メールに存在します。それだけでなく、作者がよく使用するキャッチフレーズやその他の装飾。同じ人物からの複数の電子メールを比較することにより、それらの装飾が見つかり、コンテンツにとって重要ではない淡色表示になります。私の直感は、電子メールの最初と最後の装飾を分離し、作者が使用するテキストの一般的な表現を避けるために、いくらかの調整が必要になることを教えてくれます。

これを改善するには、電子メールを電子メールデータベースと直接比較して、類似のテキストを見つけます。

これは開発が難しくなりますが、素晴らしい監査ツールになる可能性があります。

私の直感は、メッセージをチャンク化し、同じ単語を持つメッセージを見つけ、それらを比較することにより、PostgreSQLデータベースの全文検索を使用して、それに適切なパフォーマンスを与えることができるということです。

  [chunk 1][chunk 3][chunk 5][chunk 7]
      [chunk 2][chunk 4][chunk 6]

  chunk 1: 0-50; chunk 2: 25-75; chunk 3: 50-100 ...

アイデアは、単語をチャンクにリストし、使用頻度の低い単語を特定し、それらを含む電子メールをデータベースに問い合わせることです。次に、比較アルゴリズムを使用して電子メールを比較し、どの部分が等しいかを確認します。

これにより、メッセージIDによる直接チェーンを超えることができます。たとえば、コピーアンドペーストを認識します。

ただし、ここでは多少の調整が必要になります

テキストマイニング技術を使用してマッチングを改善できます

標準的なテキストマイニング(多くの論文で説明されています)には、テキストが簡略化されている場所をクリーニングするステップが含まれています。結合詞はテキストから削除され(a、is、and、orなど)、単語は次のように変換されます(たとえば、変更された、変更可能に変更された)。この変換されたテキストは判読できませんが、テキストマッチングには適しています。

このようなクリーニングを行うと、ユーザーがメールを再フォーマットしたとき、またはメールがHTMLからプレーンテキストに変換されたときに通常発生する一致の問題が特定されます。これにより、チェーンを切断するための単純なスペル修正も防止されます。

結論

これはクールな問題です。私の提案は純粋に直感に基づいており、テストされておらず、せいぜい投機的です。これがこのような問題に直面した場合、私が研究を始める最初の道です。これは開発が難しいと思いますが、強力なコミュニケーションと監査のツールになるかもしれません。

このようなソリューションは、おそらく良い電子メールアーカイブを作成します。メッセージをチェーンし、diffとチャンクのみを保存することにより、zipが実行できるものを超える巨大な圧縮係数が得られるでしょう。

また、これは強力な監査ツールになります。これは、ブロッククォート、返信、または転送を偽造した場合に明らかになります。変更されたブロック引用は元のテキストとして識別され、ソリューションによって削除されません。


0

客観的な真実は、ここでそれを行う安全な方法はないということです-一般的な電子メール/ディスカッションのためではありません。

解析したいメールが常にいくつかの厳格なルールに従っている場合は、運が良いかもしれません。

電子メールが任意の電子メールクライアントを使用している誰からでも送信される可能性がある場合は、常に適切なデータを捨ててゴミを残すリスクに直面します。

シグネチャ:完全に欠落しているものから非常に簡潔なものまで、複雑なスクリプトやアニメーションが含まれているものまで、すべての形式と形状で提供されます。

「ヘッダー」と「フッター」もあらゆる種類のコンテンツ/キーワードを持つことができます。

「ベスト」とは:最初のメールに質問のリストが含まれている場合、新しいメールの回答は古いメールの行とインターレースされて実際に編集されるのが習慣です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.