Regex Exercises in R: 25 Real-World Practice Problems

Explanation: The caret ^ anchors the match to the start of the string, and the trailing space inside the pattern is what prevents "Mrs Park" from matching. Without the space, "Mrs" would also start with "Mr" and slip through. Anchoring is almost always cheaper to read and faster than startsWith() chains when you also want regex flexibility.

Explanation: \\.csv$ requires a literal dot (escaped, since . matches any character) followed by csv followed by end-of-string. The regex(..., ignore_case = TRUE) wrapper lets the same pattern match both .csv and .CSV. Without the end anchor, "data.csv.bak" would slip through because the substring .csv appears inside it.

Explanation: Both anchors are required: ^\\d{3} alone would happily match "9999" (the first 3 digits), and \\d{3}$ alone would match "a456b" if you stripped the last char. The fixed quantifier {3} means exactly three, not "three or more". \\d is equivalent to [0-9] in stringr's ICU engine and reads faster.

Explanation: Inside a character class, the dash is a range operator (as in A-Z), but when it is placed at the very start or end of the class, it loses that meaning and matches a literal hyphen. The + quantifier requires at least one character, which is what rejects the empty string. Anchors ^ and $ ensure that any forbidden character anywhere in the string causes the match to fail.

Explanation: str_count() returns the number of non-overlapping matches per string, which is exactly what counts of a single-character class give you. No anchors are needed: every digit anywhere in the string is a separate match. For multi-character tokens like full numbers, use a quantified pattern such as \\d+ and the count drops to one per run.

Explanation: The ? quantifier makes the preceding group optional, so (\\+1 )? matches zero or one occurrence of the country prefix. The + inside the group is escaped because + is a regex metacharacter. Anchoring with ^...$ ensures the whole string conforms; without it, "+44 20 7946 0958" could still match a substring and pass.

Explanation: The range quantifier {4,6} means at least four and at most six repeats. The character class [A-Za-z] rejects digits, so "jaguar7" fails even though the alphabetic portion is six characters long. Anchors ^ and $ are essential: without them, "leopard" would match its first six letters and pass.

Explanation: str_match() returns a matrix: column 1 is the whole match and columns 2 onward are each capture group. Subscripting [, 2] pulls the first group, which is [^@]+ (one or more non-@ characters). The negated class is the trick that keeps the match from being greedy across the @. "bademail" has no @, so the whole row is NA.

Explanation: Capture groups in the pattern become numbered placeholders \\1, \\2, etc. in the replacement. The double backslash is required in R string literals because \1 would be interpreted by R first. Anchors ^...$ ensure the regex only matches well-formed two-word names; "Ada B. Lovelace" would not match because the second \\w+ cannot cross the dot.

Explanation: Each \\d+ is greedy by default so "0.10.3" correctly assigns "10" to minor, not "1". The literal dots must be escaped or they would match any character. as.integer() on the match matrix converts character captures and propagates NA for the "bad" row. This pattern is the basis for sortable version comparisons.

Explanation: [^/]+ greedily matches the last path segment up to a slash without crossing one. The literal escaped dot \\. separates the basename from the extension, and [^.]+$ at the end captures only the final extension token. That makes "file.tar.gz" split into basename "file.tar" and ext "gz", the conventional Unix interpretation of multi-suffix filenames. "noext" has no dot at all, so both captures return NA.

Explanation: A lookbehind asserts that text before the current position matches the lookbehind pattern, but it does not consume those characters. So (?<=\\$)\\d+\\.\\d{2} returns just the digits and decimal, with no dollar sign in the result. Compared to capture groups, lookbehinds are cleaner when you only want the asserted prefix as a guard, not a value to extract.

Explanation: The lookahead (?!,) asserts that the next character after the word is not a comma. Word boundaries \\b...\\b ensure full-word matches rather than substring matches. Because str_extract_all() returns a list (one element per input string), [[1]] unwraps the single-input case into a flat character vector.

Explanation: Each (?=...) is a zero-width assertion that scans the remainder of the string for one required character class without consuming input. Stacking four of them lets one pattern enforce four independent rules. After all assertions pass, .{8,}$ enforces the length floor. Trying to express this without lookaheads would require an alternation of every ordering of the four character types, which is hopeless to maintain.

Explanation: The lookbehind (?<=<td>) requires the literal opening tag immediately before the match without including it. The lookahead (?=</td>) does the same for the closing tag. [^<]+ stops at the next < so the match never crosses into the closing tag. For tightly-structured snippets this is fine, but for messy real-world HTML (nested tags, attributes, comments) reach for rvest::html_text() rather than regex.

Explanation: Word boundaries \\b ensure the 5-digit run is not part of a longer number, so "221" in "221B" is rejected (only 3 digits) and "89501" in "89501-1234" is accepted (the hyphen acts as a word boundary). Without boundaries, you would silently match 5-digit substrings of longer numbers. str_extract() returns the first match per element, which is what we want here since a row should not have more than one ZIP.

Explanation: https? makes the s optional with the ? quantifier, covering both http and https. \\S+ is one or more non-whitespace characters, which is the simplest stop rule for URLs inside log lines because spaces are the natural delimiter between log fields. For HTML or JSON inputs you would need a stricter terminator that also excludes quotes and angle brackets.

Explanation: Fixed-width digit groups separated by literal punctuation are the safe way to extract structured timestamps without false positives. The literal "T" and "Z" act as anchors inside the string, so we do not need ^ or $. For loose timestamp formats (with optional sub-second precision or offsets) you would relax the pattern, but this rigid version is faster and rejects malformed dates outright.

Explanation: Literal text like "ORD-", "SKU", and "Q" outside the capture groups anchors the structure of each field and rejects malformed inputs. The greedy \\d+ after "SKU" and "Q" cleanly absorbs variable-width numbers. Compared to splitting on "-" and indexing, str_match() makes each field self-documenting and survives unexpected dash characters inside non-structured tokens.

Explanation: The word boundaries \\b prevent matching inside longer numeric runs and reject malformed octet groups that bleed into adjacent text. Each \\d{1,3} accepts a 1-3 digit octet without validating the 0-255 range; that bound is best enforced afterwards by parsing the captured octets to integers and filtering. str_extract_all() returns a list with one slot per input line, including character(0) when nothing matches.

Explanation: str_squish() is shorthand for str_trim() plus str_replace_all("\\s+", " "). It treats tabs, multiple spaces, and newlines uniformly as whitespace, which is what you almost always want for form input. A string of only whitespace collapses to the empty string. For more selective cleanup (preserving tabs, for example), build the pieces yourself with str_replace_all().

Explanation: The pattern only inserts an underscore at a lowercase-to-uppercase boundary, which means "userID" becomes "user_ID" (a single insertion between "r" and "I") and not "user_I_D". After lowercasing, the result is the canonical "user_id". Inputs already in snake or lowercase (like "email") pass through untouched because no [a-z0-9][A-Z] boundary exists.

Explanation: The anchors guarantee the input is exactly 16 digits with no surrounding text, so 15-digit Amex numbers and non-digit strings stay unchanged (no match means no substitution). Capturing the first 4 and last 4 digits lets the replacement weave the literal "XXXXXXXX" between them. For real PCI work, also consider tokenization rather than masking, since masked PANs are still considered cardholder data in some jurisdictions.

Explanation: Splitting the problem in two (normalize then format) is much easier than writing one regex that accepts every input variant. \\D is the negation of \\d and removes parentheses, dots, dashes, and spaces in one pass. The length gate ^\\d{10}$ rejects "1-415-555-2671" (11 digits with country code) and "555-2671" (7 digits) without complicated logic. The final str_replace() weaves the three captures into the canonical form.

Explanation: <[^>]+> matches a tag opening <, any non-> content, and the closing > in one shot; the negated class is what stops the match from greedily spanning multiple tags. The named-vector form of str_replace_all() applies each pattern = replacement mapping in turn across every input string, which is cleaner than three chained calls. For production HTML cleanup with nested or malformed markup, prefer rvest::html_text(), which handles entity decoding and attribute parsing correctly.