Regular Expressions 101

Community Patterns

22

Get path from any text

Created·2023-01-31 14:38
Updated·2023-07-23 20:17
Flavor·PCRE2 (PHP)
Recommended·
Get path (windows style) from any type of text (error message, e-mail corps ...), quoted or not. THIS IS THE SINGLE LINE VERSION ! If you want understand how it work or edit it, go https://regex101.com/r/7o2fyy Relative path are not supported The goal is to catch what "Look like" a path. See the limitations UNC path and prefix path like //./], [//?/] or [//./UNC/] are allowed some url path like [file:///C:/] or [file://] are allowed Catch path quoted with ["] and [']. But these quotes are include with the catch Quoted path is not concerned by limitations Limitations : (only unquoted path) [dot] and [space] is allowed, but not in a row [dot+space] or [space+dot at end of file name isn't catched INSIDE A NAME FILE (or last directory if it is a path to a directory) : [comma] is not supported (it stop the catch) after a first [dot], any [space] stop the catch after a [space], catch is stoped if next character is not a [letter], [digit] or [-] so, double [space] stop the catch Compatibility compatible PCRE, PCRE2 AutoHotkey : don't forget to escape "%" in "`%" /!\ Powershell and .Net /!\\ : this regex need some modification to be interpreted by powershell. You have to replace each (?&CapturGroupName) by \k. Use this powershell code to do this replacement : ` $powershellRegex = @' [Put here the regex to replace (?&CapturGroupName) with \k] '@ -replace '\(\?&(\w+)\)', '\k' ` This example code must return : [Put here the regex to replace \k with \k]
Submitted by nitrateag

Community Library Entry

0

Regular Expression
Created·2023-04-20 12:21
Flavor·JavaScript

/
^[a-z0-9]+([+._-][a-z0-9]+)*@([a-z0-9]+\.[a-z0-9]+[a-z0-9])$
/
i
Open regex in editor

Description

This expression follows the rules displayed at https://knowledge.validity.com/hc/en-us/articles/220560587-What-are-the-rules-for-email-address-syntax-. Note that their rules DO NOT exactly match those of the applicable RFC 5322 (sections 3.2.3 and 3.4.1) and RFC 5321, but rather supports a pattern which is more commonly accepted by the majority of servers which also support plus addressing. Note also that since this expression is attempting to test the allowances of multiple expression segments, it is not possible to enforce maximum address length specifications. For this reason, you should use a 2-pass verification method, with the first pass being the length tests (to improve efficiency). An example of that first pass is as follows: /^[a-z0-9+.-_]{1,64}@[a-z0-9.-_]{3,253}$/

I hope this help some of you!

Submitted by Eric Bewley