Remover acentos

O Unicode, o padrão que define como computadores representam texto em praticamente todos os idiomas do mundo, foi criado em 1991 por um consórcio que incluía Apple, Microsoft, IBM e outras empresas. Antes do Unicode, cada empresa ou região usava tabelas de caracteres incompatíveis entre si: o Brasil usava ISO 8859-1 (Latin-1) para representar ã, é, ç e outros acentos do português; o Japão usava Shift-JIS para o japonês; os países árabes tinham seus próprios padrões. Trocar um arquivo de texto entre sistemas com codificações diferentes produzia o temido mojibake — aqueles caracteres estranhos e ilegíveis que apareciam quando o ã virava algo como ã ou ã. O Unicode resolveu isso com elegância: cada caractere de qualquer idioma tem um ponto de código único, de U+0000 a U+10FFFF, e as implementações mais comuns hoje são UTF-8 (padrão na web) e UTF-16 (usado internamente no JavaScript e no Java).

A remoção de acentos — ou normalização para ASCII — resolve um conjunto específico de problemas que não sumiram com o Unicode. Sistemas legados e bancos de dados antigos às vezes têm colunas indexadas em ASCII sem suporte a collation correta, e buscas com acento encontram resultado diferente de buscas sem acento. URLs amigáveis geralmente convertem títulos com acentos para versões sem acento: `Ação pré-venda` vira `acao-pre-venda` no slug. Comparação de nomes próprios em sistemas de cadastro onde um usuário digitou `João` e outro digitou `Joao` — sem normalização, são strings diferentes. Exportações de CSV para sistemas que não suportam UTF-8 corretamente. Inputs de formulários onde o validador de campo aceita apenas `[a-z0-9]` por regex simples. Nesses contextos, remover diacríticos é a solução pragmática.

A abordagem correta é a normalização Unicode NFD (Canonical Decomposition): cada caractere composto como `ã` é decomposto em dois pontos de código separados — o `a` base (U+0061) e o til combinante (U+0303). Após a decomposição, filtrar todos os caracteres da categoria Unicode Mn (Mark, Nonspacing) remove os diacríticos, deixando apenas as letras base. Em JavaScript: `str.normalize('NFD').replace(/\p{Mn}/gu, '')`. Essa técnica funciona perfeitamente para o português e o espanhol. Uma exceção notável: o `ç` é um caractere composto e será simplificado para `c` — correto para URLs, mas incorreto se você precisar de texto em francês ou turco onde o ç tem valor semântico próprio. Esta ferramenta aplica a normalização NFD e remove marcas combinantes; revise manualmente os casos onde letras específicas devem ser preservadas.

Unicode, the standard that defines how computers represent text in virtually every language in the world, was created in 1991 by a consortium that included Apple, Microsoft, IBM, and others. Before Unicode, each company or region used mutually incompatible character tables: Brazil used ISO 8859-1 (Latin-1) to represent ã, é, ç and other Portuguese accents; Japan used Shift-JIS for Japanese; Arab countries had their own standards. Transferring a text file between systems with different encodings produced the dreaded mojibake — those strange unreadable characters that appeared when ã turned into something like ã or ã. Unicode solved this elegantly: every character in any language has a unique code point, from U+0000 to U+10FFFF, and the most common implementations today are UTF-8 (the web standard) and UTF-16 (used internally by JavaScript and Java).

Stripping accents — or normalizing to ASCII — solves a specific set of problems that did not disappear with Unicode. Legacy systems and older databases sometimes have columns indexed in ASCII without proper collation support, where searches with accents return different results from searches without. Human-friendly URLs typically convert accented titles to unaccented versions: `Ação pré-venda` becomes `acao-pre-venda` as a slug. Comparing proper names in registration systems where one user typed `João` and another typed `Joao` — without normalization, these are different strings. CSV exports for systems that do not properly support UTF-8. Form inputs where field validators only accept `[a-z0-9]` using simple regex. In these contexts, removing diacritics is the pragmatic solution.

The correct approach is Unicode NFD (Canonical Decomposition) normalization: each composed character like `ã` is decomposed into two separate code points — the base `a` (U+0061) and the combining tilde (U+0303). After decomposition, filtering all Unicode category Mn (Mark, Nonspacing) characters removes the diacritics, leaving only the base letters. In JavaScript: `str.normalize('NFD').replace(/\p{Mn}/gu, '')`. This technique works perfectly for Portuguese and Spanish. One notable exception: `ç` is a composed character and will be simplified to `c` — correct for URLs, but incorrect if you need text in French or Turkish where ç carries its own semantic value. This tool applies NFD normalization and removes combining marks; manually review cases where specific letters should be preserved.

Unicode, el estándar que define cómo los ordenadores representan texto en prácticamente todos los idiomas del mundo, fue creado en 1991 por un consorcio que incluía a Apple, Microsoft, IBM y otras empresas. Antes de Unicode, cada compañía o región usaba tablas de caracteres incompatibles entre sí: Brasil usaba ISO 8859-1 (Latin-1) para representar ã, é, ç y otros acentos del portugués; Japón usaba Shift-JIS para el japonés; los países árabes tenían sus propios estándares. Intercambiar un archivo de texto entre sistemas con codificaciones distintas producía el temido mojibake — esos caracteres extraños e ilegibles que aparecían cuando la ã se convertía en algo como ã o ã. Unicode resolvió esto con elegancia: cada carácter de cualquier idioma tiene un punto de código único, de U+0000 a U+10FFFF, y las implementaciones más comunes hoy son UTF-8 (el estándar en la web) y UTF-16 (utilizado internamente por JavaScript y Java).

Eliminar acentos — o normalizar a ASCII — resuelve un conjunto específico de problemas que no desaparecieron con Unicode. Los sistemas heredados y las bases de datos antiguas a veces tienen columnas indexadas en ASCII sin soporte correcto de collation, donde las búsquedas con acento devuelven resultados distintos a las búsquedas sin acento. Las URLs amigables suelen convertir los títulos con acentos a versiones sin ellos: `Ação pré-venda` se convierte en `acao-pre-venda` como slug. La comparación de nombres propios en sistemas de registro donde un usuario escribió `João` y otro escribió `Joao` — sin normalización, son cadenas distintas. Exportaciones de CSV para sistemas que no admiten UTF-8 correctamente. Campos de formulario donde el validador solo acepta `[a-z0-9]` mediante una expresión regular simple. En esos contextos, eliminar los diacríticos es la solución pragmática.

El enfoque correcto es la normalización Unicode NFD (Descomposición Canónica): cada carácter compuesto como `ã` se descompone en dos puntos de código separados — la `a` base (U+0061) y el tilde combinante (U+0303). Tras la descomposición, filtrar todos los caracteres de la categoría Unicode Mn (Marca, Sin espacio) elimina los diacríticos, dejando solo las letras base. En JavaScript: `str.normalize('NFD').replace(/\p{Mn}/gu, '')`. Esta técnica funciona perfectamente para el portugués y el español. Una excepción notable: la `ç` es un carácter compuesto y se simplificará a `c` — correcto para URLs, pero incorrecto si necesitas texto en francés o turco donde la ç tiene valor semántico propio. Esta herramienta aplica la normalización NFD y elimina las marcas combinantes; revisa manualmente los casos donde letras específicas deban conservarse.