Introdução
João ou Joao — e se fosse ジョウ?
No Japão, nomes podem ser escritos com kanjis distintos, mas pronunciados da mesma forma. Para resolver isso, usa-se furigana: uma forma de leitura fonética que evita confusões.
Em português, passamos por algo parecido quando um usuário digita "Joao" e espera encontrar "João".
A resposta técnica para esses dois mundos pode ser a mesma: criar um campo auxiliar que sirva como furigana para a sua base de dados.
O problema: acentos, grafias e a ilusão da igualdade
Em bancos de dados, mesmo uma diferença aparentemente sutil como "a" vs "á" é suficiente para impedir que uma busca simples por LIKE '%joao%' encontre "João da Silva".
E se estivermos lidando com nomes em japonês? O som "Takashi" pode ser escrito com dezenas de combinações de kanjis diferentes, cada uma com significado próprio. Veja alguns exemplos reais:
- 定史 (significando "história determinada")
- 高士 ("nobre elevado")
- 定嘉志 ("determinação, bondade e vontade")
Todos podem ser lidos como Takashi, e é por isso que o uso de furigana é essencial em registros japoneses: ele revela como ler aquilo que pode ter múltiplas escritas.
Solução 1: o "furigana digital"
Uma abordagem simples e poderosa é criar um campo auxiliar fonético, contendo uma representação "limpa" da informação original. Como um furigana que o sistema pode ler.
Exemplo:
| ID | Nome Original | NomeBusca |
|---|---|---|
| 1 | João da Silva | joao da silva |
| 2 | Jéssica Souza | jessica souza |
Consulta:
SELECT * FROM Clientes WHERE NomeBusca LIKE '%joao%';
Essa estratégia é extremamente eficiente e funciona em qualquer banco relacional. Bastam boas práticas de consistência.
Solução 2: Unicode + remoção de diacríticos
Outra abordagem elegante é usar normalização Unicode (Forma NFD) para decompor os caracteres acentuados em caractere base + sinal diacrítico, e então remover esses sinais.
function RemoveDiacriticos(const Texto: string): string;
begin
S := NormalizeNFD(Texto);
Result := FiltrarCaracters(S, ExcluirDiacriticos);
end;
Isso permite transformar "João" em "Joao" de forma padronizada, sem precisar manter um campo auxiliar. Ideal para buscas dinâmicas e sistemas multilíngues.
Solução 3: busca fonética
Lembra do SOUNDEX() no Clipper? Ele ainda existe!
Hoje temos algoritmos como:
- Soundex: simples, ainda usado;
- Metaphone / Double Metaphone: mais preciso;
- NYSIIS, Cologne Phonetic, entre outros
Em SQL Server:
SELECT * FROM Clientes WHERE SOUNDEX(Nome) = SOUNDEX('joao');
Essas buscas funcionam bem com nomes, mas geram falsos positivos. Ideal combinar com outros filtros.
Quando o mundo é multilíngue, os detalhes importam
Em ambientes monolíngues, ninguém se importa com isso. Mas quando você precisa lidar com nomes em múltiplos idiomas, como exemplo sistemas que atendem brasileiros fora do país, tudo muda.
"Em um projeto real de atendimento a brasileiros no exterior, presenciei falhas de sistema simplesmente por não aceitarem caracteres japoneses. O banco não estava preparado, o sistema falhava ao gravar nomes em kanji."
O problema era o collation do SQL Server. Bastou um ajuste técnico para resolver.
Esses detalhes são invisíveis até o dia em que se tornam inadiáveis. E às vezes, quem resolve isso não está no centro do sistema, mas na borda onde culturas se encontram.
Furigana: a sabedoria ancestral aplicada ao código
No Japão, o furigana resolve a ambiguidade da escrita complexa com uma solução fonética simples, escrita normalmente em katakana quando se trata de nomes estrangeiros.
Aplicar o mesmo princípio ao seu banco de dados é um sinal de maturidade. Criar um campo auxiliar, ou usar transformações fonéticas, é dizer ao sistema:
"Não importa como está escrito. Eu sei o que o usuário quis dizer."
E isso é, no fim das contas, o que torna um sistema inteligente, humano e global.
