tre
TRE 0.9.0
該項目正在尋找維護者。首先，有一些拉動請求等待審查。
如果您想加緊努力，請通過[email protected]告訴我！
TRE是一個輕巧，健壯且高效的POSIX REGEXP匹配庫，具有一些令人興奮的功能，例如近似（模糊）匹配。
TRE中使用的匹配算法在搜索文本的長度上使用線性最差的時間，以及在使用的正則表達式的長度中使用二次最差的時間。
換句話說，算法的時間複雜性為o（m^2n），其中m是正則表達式的長度，n是文本的長度。二手空間在正則長度上也是二次的，但不取決於搜索的字符串。這種二次行為僅發生在實際上很少見的病理病例上。
這是處理此代碼的方法。
您將需要係統上安裝的以下工具：
首先，準備樹。更改為源目錄的根並運行
./utils/autogen.sh
這將使用先決條件工具重新生成各種東西，以便您最終得到可建造的樹。
之後，您可以運行配置腳本並照常構建TRE：
./configure
make
make check
make install
在準備好的樹中，此命令創建一個源代碼tarball：
./configure && make dist
或者，您可以運行
./utils/build-sources.sh
它可以構建源代碼軟件包並將其放置在dist子目錄中。該腳本需要一個工作的zip命令。
TRE不僅是另一個RegexP匹配器。 TRE具有一些在大多數免費POSIX兼容實現中不存在的功能。因此，這些功能中的大多數也不存在於非免費實現中。
近似模式匹配允許匹配是近似的，也就是說，在某種程度上，匹配可以接近被搜索的模式。 TRE使用編輯距離度量（也稱為Levenshtein距離），其中可以在搜索文本中插入，刪除或替換字符以獲得確切的匹配。
每個插入，刪除或替換都會增加比賽的距離或成本。 TRE可以報告其成本低於某些給定閾值值的比賽。 TRE也可以用於搜索成本最低的比賽。
TRE包括一個以GREP風格的近似Regexp匹配的sunsp（近似GREP）命令行工具的版本。與其他同意實施（例如亞利桑那大學的Sun Wu和Udi Manber的一項）不同，TRE CLESP允許任何長度，任何數量的錯誤以及插入，刪除和替換的非統一費用的全部糾正措施。
POSIX精確地定義了Regexp函數的行為。 TRE試圖盡可能嚴格遵守這些規格。例如，TRE總是返回subpattern的正確匹配項。很少有其他實現正確執行此操作。實際上，除了我知道的（免費或不正確的）之外，唯一的其他實現是湯姆·洛德（Tom Lord），約翰·馬多克（John Maddock）的Regex ++以及Glenn Fowler和Doug Mcilroy的AT＆T AST Regex。
標準TRE試圖符合IEEE STD 1003.1-2001，或開放式基本規格第6期，通常稱為“ POSIX”。相關零件是針對正則表達式（和基本原理）的基本規格以及regcomp() API的描述。
有關POSIX REGEXP匹配器的出色調查，請參見AT＆T Labs Research的Glenn Fowler的TestRegex頁面。
由於TRE中使用的匹配算法，任何regexec()調用所消耗的最大時間始終與搜索字符串的長度成正比。有一個例外：如果使用了返回引用，則匹配可能會花費時間呈指數增長，並隨著字符串的長度而成倍增長。這是因為匹配的引用是NP的完整問題，幾乎可以肯定需要在最壞情況下匹配的指數時間。
regexec()調用切勿從堆中分配內存。 TRE在regcomp()調用期間分配了所需的所有內存，以及在regexec()調用期間，堆棧框架的一些臨時工作空間。在匹配過程中，所需的臨時空間量是恆定的，並且不取決於搜索的字符串。對於合理尺寸的REGEXP，TRE需要在regcomp()調用過程中動態分配的內存小於50K，對於編譯的模式緩衝區小於20K，在regexec()調用期間，從堆棧框架中少於2千的臨時工作空間。沒有時間 /內存權衡。 TRE的代碼尺寸也很小；靜態鏈接與TRE相連的可執行文件大小小於30k（GCC-3.2，X86，GNU/Linux）。
TRE支持多重字符集。這使得可以無縫地使用Regexps，例如日本地區。 TRE還提供了廣泛的字符API。
TRE提供的API允許在Regexps和搜索字符串中允許二進制零字符。標準API不能輕鬆地用於搜索二進制數據中的可打印單詞（儘管有些黑客攻擊是可能的）。使用標準API搜索包含嵌入二進制零的模式。
TRE完全安全。所有導出的功能都是重新輸入的，並且可以在多個上下文中同時使用單個編譯的Regexp對象。例如，在main()和信號處理程序中，或在多線程應用程序的許多線程中。
TRE在多個平台上都是便攜式的。以下是用於開發和測試TRE的平台和編譯器的表：
| 平台 | 編譯器 |
|---|---|
| FreeBSD 14.1 | 叮噹18 |
| Ubuntu 22.04 | GCC 11 |
| MacOS 14.6 | 叮噹聲14 |
| Windows 11 | Microsoft Visual Studio 2022 |
TRE應該在大多數現代POSIX式平台上進行編譯，而無需更改，並可以輕鬆地用於任何具有託管C實現的平台。
根據平台，您可能需要安裝libutf8才能獲得廣泛的字符和多型字符集支持。
TRE的許可與NetBSD中使用的“ 2條” BSD式許可證基本相同。有關詳細信息，請參見文件許可證。
目前有兩個功能，兩種功能都與整理元素有關，而100％POSIX合規性缺少。這些都是：
支持整理元素（例如[[.<X>.]] ，其中<X>是整理元素）。由於POSIX並未定義一個方法來確定字符序列是否是多字符整理元素，因此不可能支持多字符整理元素。
支持等價類，例如[[=<X>=]] ，其中<X>是整理元素。等效類匹配任何具有與<X>相同的主排列權重的字符。同樣，POSIX不提供可移植機制來確定整理元件的主要整理權重。
請注意，其他便攜式REGEXP實現也不支持整理元素。單個例外是Regex ++，它帶有其自己的數據庫，用於整理不同地區的元素。對整理元素和等效類的支持尚未得到廣泛要求，目前在待辦事項列表中的支持不太高。
這些是我計劃盡快實施的其他功能：
GNU正則啟用了所有缺失的GNU擴展，例如[[:<:]]和[[:>:]] 。
REG_SHORTEST regexec()標誌，用於返回最短匹配，而不是最長的匹配。
與Perl兼容語法：
[:^class:]除了課堂中的字符外，其他任何東西都匹配。請注意， [^[:class:]]已經有效，這只是一個便利速記。
A僅在字符串開始時進行匹配。
Z僅在字符串的末端或在末尾進行匹配。
z僅在字符串末端匹配。
l小寫下一個char（思考vi）。
u Pupercase next char（think vi）。
L小寫直到E （思考vi）。
U uppercase直到E （思考vi）。
(?=pattern)零寬度的正往外斷言。
(?!pattern)零寬度負相位主張。
(?<=pattern)零寬度的正面觀察主張。
(?<!pattern)零寬度的負外觀主張。
文檔尤其是針對TRE的非標準功能（例如近似匹配），這是一項正在進行的工作（“進度”寬鬆地定義了...），如果您想找到用於使用的擴展名，請閱讀include/tre/tre.h標頭如果您對C源代碼感到滿意，可能會提供一些其他提示。
