EmailAddressExtractor

我被騙了嗎電子郵件地址提取器

一個從給定路徑中的任何文件中快速提取所有電子郵件地址的項目

背景

該專案旨在成為基本程式碼庫的全新開源版本，我在十年中的大部分時間裡一直使用該基本程式碼庫，從資料外洩中提取電子郵件地址，然後將其載入到 HIBP 中。大多數違規行為都是 .sql 或 .csv 格式，位於單一檔案或資料夾內的多個檔案中，提取遵循一個簡單的過程：

1. 透過正規表示式提取所有位址
2. 將它們轉換為小寫
3. 按字母順序排列
4. 將它們保存到輸出文件
5. 建立每個文件中有多少個唯一地址的報告

我使用的正規表示式如下： b[a-zA-Z0-9.-_+]+@[a-zA-Z0-9.-_]+.[a-zA-Z]+b

透過正規表示式進行電子郵件地址驗證很困難，但它也不需要完美適合此用例。誤報極為罕見，影響可以忽略不計，即非真實地址的字串被載入到 HIBP 中，或載入了不尋常格式的真實地址。在大多數情況下，這個正規表示式可以概括為「在 @ 符號的兩側填充字母字元的 TLD」。

實際考慮

在考慮解析規則時，討論不可避免地會導致遵守 RFC 與某些字元的實際用途。這裡有兩個主要考慮因素：

1. 如果 RFC 允許使用雙引號等字符，則應將其視為有效字符並允許在地址中使用
2. 雙引號等字元更有可能是由於解析錯誤而不是合法使用而出現

有趣的是，與第 2 點相比，第 1 點很少是正確的。允許實際不存在的地址的影響是將垃圾記錄引入 HIBP（影響也較低）。特別是當考慮實際使用具有模糊字元的地址的可能性時（例如，被接受到註冊表中並且未被拒絕），總的來說，最好拒絕可能是解析錯誤的結果的字元。

1. 提取地址時

實際上，電子郵件地址中不太可能使用晦澀的模式

貢獻

我已經聯繫並請求支持，並將透過一兩個關鍵人物啟動工作，然後尋求更廣泛的意見。我對跨更大的資料集和非文字檔案優化服務特別感興趣，特別是隨著勒索軟體人員轉儲的文件不斷增加。我將開始為需要建置的部分建立問題。

測試數據

使用 Red Gate 的 SQL 資料產生器，可以從 Mega 下載包含 10M 條典型違規資料記錄的範例檔案。此文件會導致使用此應用程式的當前版本提取 10M 電子郵件地址。注意：測試資料檔目前為V2，早期版本由於有無效網域模式，導致唯一位址略少於10M。

運行地址提取器

語法： AddressExtractor.exe -?語法： AddressExtractor.exe -v語法： AddressExtractor.exe <input [[... input]]> [-o output] [-r report]

主要選項

選項	描述
-? , -h , --help	列印命令列語法和選項
-v , --version	列印應用程式版本號
輸入	一個或多個輸入檔名或目錄
-o , --output輸出	輸出檔案的路徑和檔案名稱。預設為“addresses_output.txt”
-r , --report報告	報告文件的路徑和文件名。預設為“report.txt”
--recursive	為目錄啟用遞歸模式，這將搜尋子目錄
-y ， --yes	自動確認提示繼續，無需詢問
-q , --quiet	以更少的冗長運行，不顯示進度訊息

性能/調試

選項	描述
--debug	啟用調試模式以進行微調效能檢查
--threads數	使用帶有通道的多個線程來讀取檔案。預設為4
--skip-exceptions	出現異常時自動提示CONTINUE