Extrator de Texto

Sobre o Extrator de Texto

O Extrator de Texto tira dados estruturados de texto não estruturado usando expressões regulares afinadas. Cole uma fatura, uma thread de e-mail, um log de chat, uma saída de servidor ou uma página web copiada e isole instantaneamente cada e-mail, link, telefone, endereço IPv4/IPv6, hashtag ou @menção que precisar. Profissionais de marketing usam para listas de leads, desenvolvedores para triagem de logs, pesquisadores para coleta de citações e equipes de suporte para parsear tickets. Tudo roda localmente em JavaScript para que contatos sensíveis nunca saiam da sua máquina, e você pode deduplicar, ordenar e filtrar por maiúsculas antes de exportar.

Que padrões regex vocês usam para extrair e-mails e qual a precisão?

Usamos um subconjunto pragmático do RFC 5322 que combina ~99% dos e-mails reais rejeitando a maioria dos falsos positivos. O padrão /[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}/g aceita pontos, plus-aliases ([email protected]) e TLDs de 2 caracteres (.br) em diante. Não valida formas exóticas como local-parts entre aspas ("joao silva"@example.com) ou comentários — esses representam menos de 0,01% das caixas e incluí-los explodiria a regex em algo ilegível. Para 100% de conformidade RFC você precisaria de um parser de verdade, mas para geração de leads, parsing de logs ou coleta de contatos esta regex captura tudo prático e roda em microssegundos mesmo em entradas de megabytes.

Como vocês detectam telefones internacionais — suportam E.164?

Combinamos vários formatos heuristicamente. O padrão principal pega código de país opcional (+1 a +999), parênteses opcionais de DDD e grupos de dígitos separados por espaços, hífens, pontos ou nada — cobrindo EUA/Canadá (123) 456-7890, brasileiros (11) 91234-5678 e E.164 +5511912345678. E.164 puro é um padrão ITU-T estrito que exige + seguido de até 15 dígitos sem separadores; combinamos ele mas também aceitamos as variantes formatadas que as pessoas realmente escrevem. Atenção: este padrão produzirá falsos positivos em strings numéricas longas como IDs de pedido ou timestamps — sempre valide listas de telefones extraídas com libphonenumber se a precisão importa para faturamento ou compliance.

Por que algumas URLs no meu texto não estão sendo extraídas?

Nossa regex de URL exige esquema explícito (http://, https://, ftp://) ou prefixo www. Domínios nus como exemplo.com mencionados em prosa são pulados de propósito — distinguir 'visitei exemplo.com ontem' (URL) de 'veja meu e-mail [email protected]' (só domínio) é impossível sem contexto, então preferimos menos falsos positivos. Domínios IDN punycode (xn--80akhbyknj4f) funcionam. Domínios internacionalizados em escrita nativa (例え.jp) não, porque sua detecção requer tabela de lookup. URLs terminando em pontuação (ponto, vírgula, parêntese) têm a pontuação final removida automaticamente, já que quase sempre pertencem à frase circundante e não ao link.

Há limite de tamanho na entrada e qual a velocidade da extração?

Limite prático é cerca de 10 MB de texto — além disso, os navegadores começam a estrangular a thread de UI. Em um laptop típico, extrair todos os tipos de entidade de 1 MB de texto misto leva 50-150 ms; de 10 MB leva 1-3 segundos. O gargalo é o motor regex V8, não memória. Rodamos padrões sequencialmente em vez de em paralelo porque Web Workers adicionam overhead que excede a economia para entradas abaixo de 50 MB. Se precisa extrair de corpora enormes (escala GB), faça do lado servidor com grep -oE ou ripgrep em vez do navegador — essas ferramentas streamam os dados e evitam carregar tudo na memória de uma vez.

Posso extrair entidades que a ferramenta não suporta nativamente, como datas ou códigos de produto?

Ainda não pela UI, mas você pode pós-processar a saída 'Todos os Números' com uma regex própria rápida no DevTools ou planilha. Pedidos comuns: ISBN-13 (978-85-7522-403-8), cartões de crédito (validados Luhn), endereços bitcoin (base58 com 1 ou 3 inicial), CPFs (XXX.XXX.XXX-XX), endereços MAC (00:1A:2B:3C:4D:5E) e IBANs. Pulamos cartões de crédito e CPF deliberadamente para não criar ferramenta de coleta de PII. Se você tem um padrão específico que extrai sempre, abra um pedido de funcionalidade — adicionar uma regex leva minutos uma vez que sabemos que o caso de uso é amplo o bastante para justificar um checkbox na UI.

Como o case-sensitive afeta detecção de duplicatas?

Quando 'Remover Duplicatas' está ligado, hasheamos cada match em um Set. Com case-sensitive OFF (padrão), passamos para minúsculas primeiro, então '[email protected]' e '[email protected]' colapsam em uma entrada — geralmente o que você quer para e-mails (case-insensitive pelo RFC 5321) e domínios. Com case-sensitive ON, a capitalização original importa, o que é correto para URLs (caminhos após o domínio SÃO case-sensitive em servidores Unix), hashtags (#Bitcoin vs #bitcoin podem ser campanhas diferentes no Twitter) e Menções. O toggle existe porque não há resposta universalmente correta — e-mails se comportam de um jeito, caminhos de URL de outro, e você deve combinar com a convenção do sistema que consome sua lista extraída.

Por que a extração acontece no navegador em vez do servidor?

Três razões. Privacidade: e-mails, telefones e IPs frequentemente se qualificam como PII sob a LGPD/GDPR — mantê-los do lado cliente significa que nunca armazenamos, logamos ou processamos seus contatos em nossos servidores, eliminando risco de vazamento. Velocidade: round-trip ao servidor adiciona 50-300 ms de latência de rede que regex local evita totalmente; para fluxos em batch isso acumula. Custo: processamento client-side escala para milhões de usuários a custo de computação zero para nós, deixando a ferramenta gratuita para sempre. O trade-off é nenhuma inteligência server-side (sem reconhecimento de entidades por ML, sem matching com correção ortográfica) — para esses casos, serviços pagos como Google Cloud Natural Language API ou AWS Comprehend são apropriados, mas para extração estilo regex, o navegador é mais rápido, seguro e gratuito.