Write a regular expression

Regexes look right and fail quietly. The common faults are a missing anchor that lets the pattern match inside a longer string, a feature the target engine does not support, a $ that also matches before a trailing newline, nested quantifiers that backtrack catastrophically on hostile input, and a pattern that was never actually run against the examples it was built from.

Write a javascript regular expression for: [INTENT]

Must match: [SHOULD_MATCH]

Must not match: [SHOULD_NOT_MATCH]

1. Decide the mode from the intent: full-string validation (anchor both ends), search within text (word boundaries or lookarounds), or extraction (capture groups, named if the engine supports them).
2. Respect the engine:

• javascript: use the u flag for Unicode; \d and \w are ASCII-only.
• python: use re.fullmatch for validation, or \Z rather than $; in Python 3, \d and \w match Unicode unless you pass re.ASCII.
• pcre: $ matches before a final newline; use \z for a strict end. Possessive quantifiers and atomic groups are available.
• go: RE2 has no lookaround and no backreferences. Rewrite the logic without them, or say that code must do that part.
• posix: ERE only. No \d, lazy quantifiers or lookaround; use bracket expressions like [0-9] and [[:alpha:]].

1. Prefer the simplest pattern that passes every example. Avoid nested quantifiers over overlapping classes such as (a+)+ or (\w|\d)*.
2. Test it. Walk every example through the pattern and record the result. If a code tool is available, run them for real and say so. If any example fails, fix the pattern and repeat.
3. Probe the edges the examples do not cover: empty string, leading and trailing whitespace, newlines, Unicode letters and digits, very long input, and near-misses of the valid shape.
4. If the examples contradict the intent or each other, say which ones and which reading you followed.

• Never claim an example passes unless you checked it.
• If a regex is the wrong tool (nested structures, full email RFC compliance, real date validity such as 31 February, HTML), say so in one sentence, give the pragmatic pattern anyway, and name what code must check.
• Show the pattern both as a literal and as an escaped string for the language when they differ.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Pattern

A code block with the pattern and flags, then one line on the matching mode.

How it works

| Part | Meaning |

Test results

| Input | Expected | Result | Every given example, then the edge cases you added.

Edge cases

Inputs it accepts that someone might not expect, and inputs it rejects that might be valid. One line each.

Usage

A 3 to 6 line snippet in the language of the chosen flavor (shell grep -E for posix).