Regex 생성기

아니요. 이 패턴(\b(?:\d[ \-]?){13,16}\b)은 13~16자리 숫자가 공백이나 하이픈으로 구분되어 있는지만 확인하며, Luhn 체크섬 검증이나 카드사별 BIN(첫 자리) 검사를 전혀 하지 않습니다. 실제로 "0212345678901"처럼 카드와 무관한 13자리 숫자(전화번호, 주문번호 등)도 이 패턴에 매칭됩니다.

아니요. 이 패턴은 점(.)으로 구분된 세 구간이 각각 영문자·숫자·언더스코어·하이픈 2자 이상이면 매칭되도록 되어 있어, "12.34.56" 같은 버전 번호나 "ab.cd.ef" 같은 임의의 점 구분 문자열에도 매칭됩니다. 실제 JWT는 각 구간이 Base64URL로 인코딩된 JSON이라 훨씬 길고 특정 패턴(헤더가 보통 "eyJ"로 시작)을 갖지만, 이 정규식은 그런 세부 구조를 검사하지 않습니다.

이미 "이 문자열이 신용카드 번호일 가능성이 있는 필드"라는 문맥이 확실한 경우(예: 결제 폼의 카드번호 입력칸)에 형식만 빠르게 검사할 때는 유용합니다. 하지만 자유 텍스트에서 신용카드 번호나 JWT를 "탐지"하려는 목적이라면 오탐(false positive)이 많이 발생할 수 있어 부적합합니다.

문자열 패턴을 표현하는 언어입니다. 이메일 형식 검사, 특정 단어 추출, 문자열 치환 등 다양한 용도로 사용됩니다.

g(global)는 첫 매칭 외에 문자열 내 모든 매칭을 찾고, i(case-insensitive)는 대소문자를 구분하지 않으며, m(multiline)은 ^와 $가 전체 문자열이 아닌 각 줄의 시작·끝에 매칭되도록 합니다.

const re = /pattern/flags; 리터럴 형식이나 new RegExp('pattern', 'flags') 생성자 형식으로 사용합니다.

일반적인 이메일 형식은 검사하지만, RFC 5322 표준을 완전히 준수하려면 훨씬 더 복잡한 패턴이 필요합니다. 실무에서는 형식 검사 후 실제 인증 메일 발송으로 최종 확인하는 것이 안전합니다.

네. "또는 직접 입력" 필드에 정규식을 입력하면 미리 정의된 패턴과 마찬가지로 실시간 매칭 테스트가 가능합니다.