文字與日常工具·文字工具包
URL 和電子郵件擷取如何知道位址結束位置
· 工作原理
文字提取 網址 電子郵件地址
著眼於從散文中提取連結和地址時的兩個艱難決定——URL 在哪裡停止以及電子郵件模式應該有多嚴格——以及為什麼實用模式在真實文字上擊敗了完整的 RFC 語法。
帶有句號的連結 - 為什麼簡單提取返回 https://example.com. 並破壞連結
會議記錄通常會在句子末尾放置一個有用的連結： `Agenda: https://example.com/roadmap.` 接受每個非空格字元的搜尋將包括最後的句號。可見文字看起來合理，但提取的值不再與作者打算共享或重新訪問的地址相符。
ToolAcre 首先尋找 HTTP 或 HTTPS 序列，然後刪除尾隨的句號、逗號、分號、冒號、驚嘆號和問號。清理是故意附加到匹配邊界的，而不是應用於整個檔案。當初始模式允許時，URL 中其他位置的標點符號仍然可用。
附有句號的連結：為什麼提取必須排除尾隨標點符號
URL 模式僅從 `http://` 或 `https://` 開始，一直持續到出現空格或幾個結束分隔符號之一。引號、尖括號、右括號和右方括號都會停止配對。此規則允許諸如 `(https://example.com/notes)` 之類的散文傳回不帶括號的位址。
這是一個實用的邊界規則，而不是每個可能的 URI 的通用解析器。左括號可以保留在匹配中，而右括號則終止匹配，因此其路徑真正包含該字元的位址可能會被縮短。提取器傾向於常見的散文邊界，並留下不尋常的情況供人工審查。
電子郵件匹配應該有多嚴格 - RFC 5322 技術上允許什麼，以及為什麼匹配所有這些都會在真實文字上產生更差的結果
電子郵件擷取也進行了類似的權衡。它在 `@` 之前尋找字母、數字和熟悉的郵箱標點符號，然後查找類似域的序列，後面跟著一個點和至少兩個字母。此模式捕獲嵌入在註釋中的普通地址，而無需嘗試重現完整電子郵件語法所承認的每個結構。
較窄的模式很有用，因為提取和驗證回答不同的問題。提取識別非結構化文字中可能的聯絡資訊；它不能確定郵箱是否存在、接受郵件或屬於指定的人。將結果視為可審查的列表，尤其是當標點符號或不常見的郵箱語法出現在附近時。
去重與排序 — 每個位址都有一個副本，按照首次出現的順序，因此清單反映了來源
對於 URL 和電子郵件地址，ToolAcre 會刪除帶有 `Set` 的重複項。 JavaScript 設定保留插入順序，因此第一次出現決定了專案在結果中出現的位置，隨後相同的符合項目消失。因此，輸出從上到下遵循來源，而不是未經許可按字母順序排列聯絡人或連結。
平等是准确的。 `https://example.com` 和 `https://example.com/` 保持獨立，字母大小寫不同的電子郵件地址也是如此。提取器不會規範化網域、刪除 URL 片段或確定兩個目標是等效的。這些更改可能會有意合併不同的文字，因此任何進一步的規範化都屬於單獨的檢查步驟。
數字也是如此——從散文中提取數字值，以及為什麼小數點和千位分隔符號使「數字」不像聽起來那麼明顯
數字提取接受可選的減號、一個或多個數字以及由句號引入的可選小數部分。它可以從散文中提取 `-12`、`48` 和 `3.75`。與 URL 和電子郵件提取不同，它直接傳回每個匹配項，因此重複值保持重複並保留其出現次數。
分組和本地化形式暴露了該緊湊規則的限制。 `1,250` 傳回為 `1` 和 `250`，而 `3,5` 也被分割而不是解釋為十進位逗號。貨幣符號、指數和前導加號不是匹配的一部分。在為任何提取的數字賦予含義之前，請閱讀附近的文字。
也是數字：有符號整數和小數，不會將分組值視為一個數字
嘗試以下注意事項：`Email sam@example.com, then review https://example.com/plan. Backup: sam@example.com. Budget -12.5; seats 24. Reference (https://example.com/help).` 提取電子郵件回傳 1 `sam@example.com`。提取 URL 依序傳回不帶句號或右括號的計畫和幫助地址。
手動掃描應找到兩個電子郵件外觀，但一個唯一的電子郵件結果、兩個不同的 URL 外觀和兩個數字匹配。提取數字返回 `-12.5` 和 `24`；示例域內的數字不會添加匹配項，因為不存在任何匹配項。此檢查將出現次數與刪除重複的聯絡人和連結清單分開。
這不包括什麼 - 驗證地址是否確實存在，以及實用模式遺漏的奇特但有效的地址
相符的電子郵件只是形狀與實現的模式相似的文字。 ToolAcre 不會查詢郵件伺服器、傳送測試訊息或檢查網域記錄。因此，看似合理的拼字錯誤可能會透過提取，而不常見但可用的地址可能會被遺漏。在依賴該清單之前，請透過適當的可信任管道確認重要聯絡人。
URL 提取同樣不會要求頁面、遵循重定向或測試目的地是否安全或可用。它還需要明確 HTTP 或 HTTPS 前綴，因此不會傳回裸露的 `example.com` 。這些限制使提取保持本地化和可預測，但它們使人工審核成為任何後續工作流程的一部分。
要點 — 文字工具包的提取按鈕明確地進行了這些權衡，並在瀏覽器中為您提供了一個乾淨的、去重複的列表
提取按鈕將混合的散文區塊轉換為瀏覽器中以換行符號分隔的匹配項。 URL 和電子郵件使用實用的模式，在常見的散文邊界處修剪或停止，並按首次看到的順序傳回唯一值。數字使用較小的有符號十進制模式並保留重複項，反映了不同的函數契約而不是通用提取策略。
僅貼上您需要的註釋，分別執行提取 URL 和提取電子郵件，並將每個清單與來源進行比較，然後再繼續複製。乾淨的輸出消除了重複掃描，而記錄的邊界顯示了仍然需要判斷的地方。對於不常見的語法，在審閱時將原始段落保留在提取結果旁邊。