Padrões regex comuns

Use os padrões como ponto de partida e teste-os no mecanismo escolhido. Corresponder a um formato não comprova a validade de um endereço, data ou conta.

Funciona localmente no seu navegador
Caso de usoExpressão regularObservações
Endereço de e-mail ^[^\s@]+@[^\s@]+\.[^\s@]+$ Verificação sintática prática; a entrega exige confirmação.
URL HTTP ou HTTPS ^https?:\/\/[^\s]+$ Verifica o esquema e rejeita espaços; use um parser de URL para validação completa.
Endereço IPv4 ^(?:(?:25[0-5]|2[0-4]\d|1?\d?\d)\.){3}(?:25[0-5]|2[0-4]\d|1?\d?\d)$ Aceita octetos de 0 a 255.
UUID versões 1–5 ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$ Verifica o formato padrão com hífens e os bits de variante RFC.
Data no formato ISO ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ Verifica o formato YYYY-MM-DD, não o limite de dias de cada mês.
Horário de 24 horas ^(?:[01]\d|2[0-3]):[0-5]\d$ Aceita valores de 00:00 a 23:59.
Cor hexadecimal ^#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$ Aceita as notações RGB, RRGGBB e RRGGBBAA.
Versão semântica ^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$ Corresponde a versões básicas e metadados opcionais de prerelease e build.
Inteiro com sinal ^-?\d+$ Permite um sinal de menos opcional.
Número decimal ^-?(?:\d+|\d*\.\d+)$ Aceita inteiros e frações decimais, inclusive valores como .5.
Slug de URL ^[a-z0-9]+(?:-[a-z0-9]+)*$ Palavras ASCII em minúsculas separadas por hífens simples.
Tag semelhante a HTML <\/?[A-Za-z][^>]*> Útil apenas para extrações simples; processe HTML com um parser HTML.
Espaços no início ou no fim ^\s+|\s+$ Use a flag global ao remover espaços das duas extremidades.
Linha em branco ^\s*$ Use o modo multilinha para avaliar cada linha separadamente.
Palavra adjacente repetida \b([A-Za-z]+)\s+\1\b Use o modo sem diferenciação de caixa se as maiúsculas não forem relevantes.

Notas de portabilidade

JavaScript, PCRE, Python, Java, .NET, Go e Ruby não implementam exatamente os mesmos recursos regex. Verifique o mecanismo de destino antes de usar lookbehind, grupos nomeados, propriedades Unicode, quantificadores possessivos ou modificadores inline.

Em validações sensíveis à segurança, normalize primeiro a entrada, aplique limites explícitos de tamanho e use um parser específico sempre que o formato tiver um.

Como usar Padrões regex comuns

Quinze padrões prontos para os valores que costumam aparecer em um formulário, uma linha de log ou um arquivo de configuração: e-mail, URL HTTP ou HTTPS, endereço IPv4, UUID versões 1-5, data no formato ISO, horário de 24 horas, cor hexadecimal, versão semântica, inteiro com sinal, número decimal, slug de URL, tag semelhante a HTML, espaços no início ou no fim, linha em branco e palavra adjacente repetida.

A tabela é a página inteira: não existe campo para digitar nem nada para executar. Cada linha diz o que o padrão verifica e o que ele deixa passar, porque casar com um formato não é validar um dado real. A linha de data aceita 2024-02-31 e a de e-mail não tem como saber se um endereço recebe mensagens, então trate o padrão como ponto de partida e teste-o no mecanismo que vai executá-lo.

  1. Digite na caixa de busca, ou pressione / em qualquer ponto da página, para filtrar a tabela por caso de uso, padrão ou nota.
  2. Observe o contador abaixo do campo: ele sempre informa quantas das 15 linhas estão visíveis.
  3. Pressione o botão de copiar na célula do padrão para levar a expressão regular ao clipboard como texto simples.
  4. Leia a nota da mesma linha antes de adotar o padrão: ela nomeia os casos que a expressão tolera e os que escapam.
  5. Abra o Testador de expressões regulares para rodar o padrão em um texto de exemplo, ou o Gerador de código regex para adaptá-lo a uma linguagem.

O que cada padrão verifica e o que não verifica

Comportamento verificado no navegador

A linha IPv4 aceita 0.0.0.0 e 255.255.255.255 e rejeita 256.1.1.1, 1.2.3 e 1.2.3.4.5. A linha UUID exige o formato com hífens, dígito de versão de 1 a 5 e nibble de variante RFC igual a 8, 9, a ou b, portanto identificadores de versão 6 e 7 não casam. A linha de versão semântica aceita 1.0.0, 1.0.0-alpha.1 e 1.0.0+build.1, enquanto v1.0.0 e 01.0.0 falham.

Várias linhas são flexíveis de propósito. 2024-02-31 passa na linha de data porque o padrão não conhece a duração dos meses, e 2024-13-01 não passa. A linha de horário exige dois dígitos: 09:30 casa e 9:30 não. A linha de inteiro rejeita +5, a de decimal aceita .5 e rejeita 5., e a de slug mantém hífen único e letras minúsculas.

Buscar, contar e copiar

O filtro lê a linha inteira, não só o título: "octet" encontra a linha IPv4 pela nota, "^https" encontra a linha de URL pelo próprio padrão e "blank" encontra a linha em branco. O contador informa o total de 15, Escape limpa o campo quando ele está em foco e o botão Limpar faz o mesmo em tela sensível ao toque.

O botão da linha copia apenas a expressão regular, com âncoras e sem aspas adicionadas, para que o resultado entre direto no código, em um arquivo de testes ou em uma regra de validação. O caso de uso e a nota ficam na página: são contexto, não parte do padrão.

Flags e diferenças entre mecanismos

Três linhas só funcionam com as flags corretas: a de espaços no início ou no fim precisa da flag global para aparar as duas pontas, a de linha em branco precisa do modo multilinha para avaliar ^ e $ em cada linha, e a de palavra repetida precisa da flag de ignorar maiúsculas para ler "The the" como repetição.

O limite maior é a portabilidade. Lookbehind, grupos nomeados, propriedades Unicode e quantificadores possessivos não são implementados do mesmo jeito em JavaScript, PCRE, Python, Java, .NET, Go e Ruby, e um padrão copiado desta página carrega as suposições do mecanismo para o qual foi escrito. Consulte a documentação do mecanismo de destino e mantenha a expressão em um teste que rode nas strings que o seu serviço realmente vê.

Ferramentas recentes: