O problema está claro. A URL do nexustoons tem um padrão diferente: 0001_84d6d46ddbdd1ff1.webp — o número está no início do nome do arquivo, seguido de um sufixo hash. A função parseExampleUrl atual só detecta números no final do nome (regex ^(.*?)(\d+)$). Preciso ampliar a detecção para capturar o número no início também, e ignorar a parte hash que não muda.
Padrão detectado:
0001_84d6d46ddbdd1ff1.webp → número = 0001, sufixo fixo = _84d6d46ddbdd1ff1https://cdn.nexustoons.com/manga_pages/211/89d84c7d7c28c668_130/{num}_84d6d46ddbdd1ff1.webpAgora atualizo o card de padrão detectado para mostrar o novo formato (prefixo + número + sufixo):
Também atualizo o placeholder de exemplo para incluir o padrão do nexustoons:
O parser foi reescrito para detectar o número em qualquer posição do nome do arquivo usando a regex ^([^0-9]*)(\d+)(.*)$, que separa em: prefixo (antes do número), número e sufixo (depois do número). Assim 0001_84d6d46ddbdd1ff1.webp é corretamente decomposto em prefixo="", num=0001, sufixo=_84d6d46ddbdd1ff1 — e as URLs geradas ficam 0001_84d6d46ddbdd1ff1.webp, 0002_84d6d46ddbdd1ff1.webp, etc. O card de preview do padrão também foi atualizado para mostrar o novo formato.
Sua mensagem parece ter sido cortada — recebi apenas "qu". O que você gostaria de fazer? Por exemplo:
https://cdn.nexustoons.com/manga_pages/211/89d84c7d7c28c668_130/0001_84d6d46ddbdd1ff1.webp)Me conta o que precisa.