Use Cases (Aktualisiert: 2.6.2026)

Regex mit Claude Code erstellen, testen und reviewen

Praxisguide für Regex mit Claude Code: E-Mail, Telefonnummern, Logs, benannte Captures, Tests und typische Fehler.

Regex mit Claude Code erstellen, testen und reviewen

Reguläre Ausdrücke scheitern selten nur an der Syntax. Häufiger ist unklar, welche Eingaben erlaubt und welche verboten sind. Ein Muster akzeptiert user@example.com, lehnt aber user+tag@sub.example.co.jp ab, lässt user@.com durch oder wird nach dem nächsten Capture schwer reviewbar.

Claude Code hilft, weil es aus Beispielen einen prüfbaren Ablauf macht: erlaubte Strings, abgelehnte Strings, Regex, ausführbare Tests und Review-Kriterien. Eine Regex beschreibt die Form eines Textes. Eine benannte Capture Group gibt einem extrahierten Teil einen Namen wie timestamp oder requestId.

Wenn du neu startest, lies zuerst den Claude Code Einstieg. Für bessere Arbeitsaufträge passt dazu 5 Tipps für bessere Prompts. Als offizielle Referenzen nutze Claude Code overview und MDN Regular expressions.

Ablauf

flowchart LR
  A["Erlaubte Beispiele"] --> C["Claude Code beauftragen"]
  B["Abgelehnte Beispiele"] --> C
  C --> D["Regex und Helper"]
  D --> E["Node.js Tests"]
  E --> F["Risiken reviewen"]

Bitte nicht nur um “eine E-Mail-Regex”. Sage, ob du validieren, extrahieren, ersetzen oder Logs analysieren willst. Die Beispiele werden zum Vertrag, den die Tests absichern.

Erster Prompt

Erstelle einen JavaScript-Regex-Helper für E-Mail-Adressen, japanische Telefonnummern und Application Logs.

Anforderungen:
- Läuft direkt mit Node.js
- user+tag@sub.example.co.jp erlauben
- user..name@example.com und user@.com ablehnen
- 090-1234-5678, 03-1234-5678 und 05012345678 erlauben
- timestamp, level, service, requestId und message mit benannten Captures aus Logs extrahieren
- Tests mit node:test hinzufügen
- Erklären, wo Regex keine Business-Validierung ersetzen sollte

Der wichtigste Punkt ist der Umfang. Vollständige E-Mail-Validierung nach allen RFC-Regeln ist für ein Formular meist zu streng. Hier geht es um eine praktische Prüfung offensichtlicher Fehler; Zustellbarkeit und Existenz gehören in Bestätigungs-E-Mail oder Backend.

Beispiel 1: Helper für E-Mail, Telefon und Logs

Speichere den Code als regex-helper.mjs und führe node regex-helper.mjs aus.

import { fileURLToPath } from "node:url";

export const emailRegex =
  /^(?!.*\.\.)[A-Z0-9_%+-]+(?:\.[A-Z0-9_%+-]+)*@(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+[A-Z]{2,63}$/i;

export const emailSearchRegex =
  /[A-Z0-9_%+-]+(?:\.[A-Z0-9_%+-]+)*@(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+[A-Z]{2,63}/gi;

export const normalizedJapanesePhoneRegex = /^0(?:[5789]0\d{8}|[1-9]\d{8,9})$/;

export const looseJapanesePhoneSearchRegex =
  /0\d{1,4}[-\s]?\d{1,4}[-\s]?\d{3,4}/g;

export const appLogRegex =
  /^\[(?<timestamp>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{3})?Z)\]\s+(?<level>INFO|WARN|ERROR)\s+(?<service>[a-z][a-z0-9-]*)\s+requestId=(?<requestId>[A-Za-z0-9_-]+)\s+message="(?<message>[^"]*)"$/;

export function isEmail(input) {
  return emailRegex.test(input.trim());
}

export function normalizePhone(input) {
  return input.replace(/[()\s-]/g, "");
}

export function isJapanesePhone(input) {
  return normalizedJapanesePhoneRegex.test(normalizePhone(input));
}

export function extractContacts(text) {
  const emails = [...text.matchAll(emailSearchRegex)]
    .map((match) => match[0])
    .filter(isEmail);

  const phones = (text.match(looseJapanesePhoneSearchRegex) ?? []).filter(
    isJapanesePhone,
  );

  return {
    emails: [...new Set(emails)],
    phones: [...new Set(phones)],
  };
}

export function parseLogLine(line) {
  const match = line.match(appLogRegex);
  if (!match?.groups) return null;

  return {
    timestamp: match.groups.timestamp,
    level: match.groups.level,
    service: match.groups.service,
    requestId: match.groups.requestId,
    message: match.groups.message,
  };
}

if (process.argv[1] === fileURLToPath(import.meta.url)) {
  const text = "Contact: user+tag@sub.example.co.jp / 090-1234-5678";
  const log =
    '[2026-06-02T10:15:30.000Z] ERROR billing-api requestId=req_123 message="payment failed"';

  console.log(extractContacts(text));
  console.log(parseLogLine(log));
}

Telefonnummern werden vor der Prüfung normalisiert. Dadurch bleibt die Regex kürzer, und Bindestriche oder Leerzeichen verändern das Ergebnis nicht. Bei Logs machen benannte Captures das Review einfacher: match.groups.requestId ist klarer als match[4].

Beispiel 2: Tests sichern das Verhalten

Speichere den Code als regex-helper.test.mjs und führe node --test regex-helper.test.mjs aus.

import test from "node:test";
import assert from "node:assert/strict";
import {
  extractContacts,
  isEmail,
  isJapanesePhone,
  parseLogLine,
} from "./regex-helper.mjs";

test("validates practical email addresses", () => {
  assert.equal(isEmail("user@example.com"), true);
  assert.equal(isEmail("user+tag@sub.example.co.jp"), true);
  assert.equal(isEmail("user..name@example.com"), false);
  assert.equal(isEmail("user@.com"), false);
  assert.equal(isEmail("@example.com"), false);
});

test("validates Japanese phone numbers after normalization", () => {
  assert.equal(isJapanesePhone("090-1234-5678"), true);
  assert.equal(isJapanesePhone("03-1234-5678"), true);
  assert.equal(isJapanesePhone("05012345678"), true);
  assert.equal(isJapanesePhone("123-4567-8901"), false);
  assert.equal(isJapanesePhone("090-123-456"), false);
});

test("extracts contacts from free text", () => {
  assert.deepEqual(
    extractContacts("support: user+tag@example.com, tel: 090-1234-5678"),
    {
      emails: ["user+tag@example.com"],
      phones: ["090-1234-5678"],
    },
  );
});

test("parses application logs with named captures", () => {
  const parsed = parseLogLine(
    '[2026-06-02T10:15:30.000Z] WARN auth-service requestId=req_abc message="retry required"',
  );

  assert.deepEqual(parsed, {
    timestamp: "2026-06-02T10:15:30.000Z",
    level: "WARN",
    service: "auth-service",
    requestId: "req_abc",
    message: "retry required",
  });
});

Lass Claude Code die Tests ausführen.

Führe node --test regex-helper.test.mjs aus.
Wenn ein Test fehlschlägt, erkläre zuerst, ob die Regex oder die Testdaten falsch sind.
Wenn der E-Mail-Support erweitert wird, füge zuerst ein erlaubtes und ein abgelehntes Beispiel hinzu.

Beispiel 3: Prompt für Log-Extraktion

Logs sind ein guter Regex-Anwendungsfall, weil das Format von der Anwendung kontrolliert wird.

Lies logs/app.log, extrahiere nur ERROR-Zeilen und schreibe requestId und message in eine CSV.
Nutze dieselbe appLogRegex wie in regex-helper.mjs.
Nicht parsebare Zeilen nicht still verwerfen; gib am Ende die Anzahl aus.
Schreibe keine E-Mail-Adressen oder Telefonnummern in die CSV.

In echten Logs gibt es alte Formate, abgeschnittene Zeilen und temporäre Debug-Ausgaben. Ein Parser, der null zurückgibt, ist besser reviewbar als ein Skript, das Daten still ignoriert.

Review-Vorlage

## Regex review request

Files:
- regex-helper.mjs
- regex-helper.test.mjs

Review:
- Are allowed and rejected examples covered by tests?
- Are email, phone, and log responsibilities separated?
- Are named capture names readable?
- Is there any ambiguous repetition that could cause ReDoS?
- Could personal data leak into logs or CSV output?

Output:
- For each issue, include file, line, reason, and suggested fix
- Ask a question instead of guessing when the business rule is unclear
- Run node --test regex-helper.test.mjs after changes

ReDoS bedeutet, dass eine Regex bei bestimmter Eingabe extrem lange dauern kann. Bei verschachtelten Wiederholungen sollte Claude Code diesen Punkt explizit prüfen.

Häufige Fehler

FehlerBessere Anweisung
Nur Erfolgsbeispiele gebenMindestens 3 Ablehnungsbeispiele hinzufügen
Überall .* verwendenKonkrete Grenzen wie [^"]* nutzen
Eine g-Regex mit test() wiederverwendenValidierungs- und Such-Regex trennen
Von Capture-Indizes abhängenBenannte oder nicht erfassende Gruppen nutzen
Regex als Business-Validierung behandelnZustellbarkeit und Existenz im Backend prüfen

Regex eignet sich für die Form von Eingaben und das Extrahieren aus kontrolliertem Text. Sie beweist nicht, dass eine E-Mail zustellbar ist oder eine Telefonnummer existiert.

CTA

Regex-Verbesserungen liegen nah an Umsatzpfaden: Lead-Formulare, Checkout-Logs, Support-Eingänge und Download-Anmeldungen. Starte mit dem kostenlosen Claude Code Cheatsheet. Wiederverwendbare Vorlagen findest du unter Produkte. Für Team-Rollout mit Validierung, Log-Review und Review-Gates nutze Claude Code Training und Beratung.

Fazit

Claude Code funktioniert bei Regex am besten, wenn Beispiele, Gegenbeispiele, Tests und Review-Kriterien zusammen geliefert werden. In Masas Test war “Regex und Tests gemeinsam erstellen” stabiler als “nur eine Regex schreiben”: user+tag, Telefonnummern mit Bindestrichen und benannte Log-Captures wurden früher abgesichert.

#Claude Code #regular expressions #regex #debugging #testing
Kostenlos

Kostenloses PDF: Claude-Code-Cheatsheet

E-Mail eintragen und eine Seite mit Befehlen, Review-Gewohnheiten und sicheren Workflows herunterladen.

Wir schützen Ihre Daten und senden keinen Spam.

Masa

Über den Autor

Masa

Engineer für praktische Claude-Code-Workflows und Team-Einführung.