Ferramentas de texto e do dia a dia · Kit de ferramentas de texto
Como os geradores de slug dobram os acentos: explicação da decomposição NFD
· Como funciona
URL-slugs conversão de texto javascript
Explica como a decomposição canônica Unicode separa uma letra base de seu acento para que 'Café Crème' se torne café-creme em vez de caf-cr-me, e onde a decomposição por si só é insuficiente.
caf-cr-me — o bug comum que altera nomes e por que isso acontece
Uma rotina slug fraca pode transformar `Café Crème` em `caf-cr-me` quando exclui todos os caracteres fora de um intervalo estreito de ASCII. Os acentos visíveis desaparecem, mas as letras básicas subjacentes desaparecem com eles, deixando um URL que não se parece mais com o título do artigo. Esse dano é especialmente óbvio em nomes, lugares e categorias editoriais repetidas.
ToolAcre segue um caminho diferente em `slugify`. Primeiro normaliza a entrada e depois remove um intervalo específico de marcas de combinação, mantendo as letras resultantes. Só depois coloca em minúsculas os separadores de texto e forma. A ordem é a razão pela qual `Café Crème` se torna `cafe-creme` em vez de um fragmento sem vogais.
Um caractere, duas representações - como é pode ser um único ponto de código ou um e seguido por uma combinação de acento agudo
Texto que parece idêntico pode ter sequências internas diferentes. Um `é` pode chegar como um caractere pré-composto ou como um `e` comum seguido por uma marca aguda combinada. Um editor de conteúdo geralmente não consegue ver qual representação veio de um CMS, documento ou área de transferência, mas um filtro caractere por caractere pode tratar as duas entradas de maneira diferente.
Essa diferença oculta é importante quando uma regra de substituição reconhece uma forma, mas não a outra. ToolAcre evita escrever uma substituição separada para cada ortografia pré-composta. A normalização dá ao pipeline de slug uma forma intermediária mais consistente, de modo que os acentos suportados podem ser removidos em uma etapa posterior, enquanto as letras base permanecem disponíveis para URL.
Formulário de normalização D - como a decomposição canônica reescreve cada letra acentuada em uma letra base mais marcas de combinação
A implementação chama `.normalize("NFD")` antes de qualquer trabalho com letras minúsculas ou separador. Para caracteres que possuem uma decomposição canônica tratada pelo tempo de execução JavaScript, isso produz um caractere base seguido por uma ou mais marcas de combinação. A função não mantém seu próprio catálogo de grafias em francês ou espanhol e não inspeciona semanticamente as palavras.
O esboço diz que NFD reescreve todas as letras acentuadas, mas a fonte suporta uma declaração mais restrita. A decomposição depende do caractere, e a seguinte expressão de remoção cobre pontos de código de `U+0300` a `U+036F`. O artigo deve, portanto, descrever o comportamento demonstrado pelo código, em vez de prometer a remoção universal de acentos para cada script ou marca.
NFD decompõe caracteres suportados; a implementação não promete que cada letra acentuada separe
Após a normalização, `slugify` aplica `/[̀-ͯ]/g` e substitui cada marca correspondente por uma string vazia. Na forma decomposta de `é`, o `e` não corresponde a esse intervalo, enquanto a marca aguda sim. A remoção apenas da marca deixa a letra base legível que a abordagem anterior somente ASCII teria descartado.
Esta é uma dobra acentuada, não uma passagem geral de limpeza de texto. A expressão regular é colocada deliberadamente antes da regra para separadores, permitindo que a letra base participe como letra posteriormente. Se a remoção da marca acontecesse depois que as execuções não suportadas já tivessem sido recolhidas, uma marca decomposta poderia influenciar o posicionamento do separador e produzir um slug menos fiel.
O resto do pipeline de slug - letras minúsculas, recolhimento de execuções não alfanuméricas em hifens únicos, corte de separadores iniciais e finais, eliminação de emojis
O pipeline restante coloca o texto normalizado em minúsculas e substitui cada execução que não seja uma letra ou número Unicode pelo separador configurado, cujo padrão é um hífen. Uma segunda expressão corta separadores repetidos de ambas as extremidades. Os emojis e a pontuação desaparecem, portanto, como conteúdo, enquanto os caracteres adjacentes não suportados tornam-se um limite em vez de vários hífens.
O esboço descreve um colapso não alfanumérico, mas o padrão real usa escapes de propriedade Unicode, não um alfabeto somente ASCII. Letras de scripts não latinos podem permanecer no slug após serem colocadas em minúsculas. A configuração confirma que não há etapa de transliteração: os símbolos são removidos, mas as letras retidas não são reescritas automaticamente como grafias latinas aproximadas.
O restante deste pipeline de slug mantém letras e dígitos de qualquer script enquanto substitui outras execuções pelo separador escolhido
Siga `Café Crème & Co. — Été 2024!` durante a implementação. NFD separa os caracteres acentuados suportados em letras básicas e marcas. A expressão de remoção de marca deixa `Cafe Creme & Co. — Ete 2024!` e letras minúsculas produzem `cafe creme & co. — ete 2024!` antes que a pontuação seja processada.
As execuções sem letras e sem números tornam-se então hífens, produzindo a sequência significativa `cafe-creme-co-ete-2024` após os separadores iniciais e finais serem cortados. O "e" comercial, o ponto final, o travessão e o ponto de exclamação não recebem nomes falados ou substituições personalizadas. Eles servem apenas como limites entre execuções de letras e números nesta conversão.
O que a decomposição não pode fazer — letras como ø, ł, ß e æ não têm acento para serem retiradas e precisam de uma tabela de transliteração
Decomposição não é transliteração. Caracteres como `ø`, `ł`, `ß` e `æ` ainda são letras Unicode após esse pipeline, portanto, o filtro baseado em propriedades os mantém em vez de consultar uma tabela para `o`, `l`, `ss` ou `ae`. Afirmar que os usuários precisam de uma tabela de transliteração pode ser um conselho de design útil em outro lugar, mas tal tabela não existe nesta ferramenta.
Essa distinção também explica por que o resultado pode ser um slug de projeto válido sem ser apenas ASCII. Editores cujo sistema de publicação requer ASCII devem verificar essa restrição de sistema separada antes de usar a saída. ToolAcre promete dobramento acentuado para o intervalo de decomposição e marca implementado; não promete ortografia com reconhecimento de idioma, conversão reversível ou saída em latim para cada título.
Os caracteres sem marcas removíveis permanecem letras; esta ferramenta não possui tabela de transliteração
A conclusão confiável é processual: normalize primeiro, remova as marcas de combinação suportadas, letras minúsculas, recolha as execuções não suportadas e corte os separadores. Cada estágio tem uma responsabilidade visível e sua sequência preserva as letras básicas antes que a pontuação seja descartada. Isso é suficiente para evitar a falha comum `caf-cr-me` sem inventar regras de linguagem que a fonte não contém.
Cole o título trabalhado no conversor de maiúsculas e minúsculas de texto e selecione a opção slug para inspecionar o resultado final na mesma caixa de texto. Se um título incluir letras fora dos casos de acento demonstrados, analise o resultado em relação à plataforma de destino. O conversor fornece uma transformação previsível no navegador, enquanto o editor permanece responsável pelas convenções de rota.