Entendendo a lógica por trás dos símbolos no teclado
A maioria das pessoas vê apenas o caractere estampado na tecla e assume que aquele é o único valor possível. A realidade é mais complicada. Cada tecla fisicamente envia um scan code, e o sistema operacional traduz esse código para um caractere dependendo da disposição do teclado ativa no momento. Quando você aperta Shift mais uma tecla, o driver de layout aplica uma transformação de nível shift. AltGr adiciona um terceiro nível. E existem teclas especiais que não geram caractere algum, apenas eventos. O nome dos simbolos do teclado varia conforme a variante do layout e a região. O símbolo "&" pode ser acessado de formas diferentes no ABNT2 brasileiro, no US International, ou num layout personalizado. A confusão começa exatamente aqui: o que você vê na tela nem sempre corresponde ao caminho mais direto pelo hardware.
O que são os nomes corretos dos símbolos do teclado e como encontrá-los na prática
No Windows, a ferramenta mais confiável para mapear tecla por tecla é o Teclado e Métodos de Entrada nas Configurações, combinado com o utilitário do Sysinternals chamado ShowKey. Ele imprime na tela o scan code e a tradução em tempo real. No Linux, o comando xev mostra os eventos X11 com keycode, keysym e string. No macOS, o utilitário Console com o filtro de IOKit revela códigos de tecla brutos. Se você está configurando um keybind em uma aplicação ou criando um layout personalizado, precisa saber o keysym exato, não apenas a aparência. Por exemplo, o til (~) e o acento circunflexo (^) compartilham a mesma tecla base em muitos layouts americanos, mas o keysym muda conforme o estado da tecla morta. Isso é importante porque ferramentas como AutoHotkey ou Karabiner-Elements trabalham com keysyms, não com glifos visuais.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um problema concreto que encontrei recentemente envolveu um script de automação em Python que lia pressionamentos de tecla via pynput para disparar ações em um software de controle financeiro. O script funcionava perfeitamente no meu laptop, mas falhava em estações de trabalho com teclado ABNT2. O motivo era o acento crase (`). No meu layout, a tecla ao lado de Z enviava Backquote. No ABNT2, aquela posição física carrega o til (~). O script procurava pelo keysym de Backquote e nunca o encontrava. A correção foi mapear pelo scan code em vez do keysym, usando a tabela de referência do layout ativo, e adicionar uma verificação de fallback que procurava por Tilde quando Backquote não era reconhecido. O problema inverse também existe. Em alguns teclados chineses compatíveis com Windows, a tecla com o símbolo do euro (€) está fisicamente presente, mas o driver padrão não atribui um keysym internacional. A solução mais simples é forçar o layout US International ou usar uma ferramenta como KeyTweak para sobrescrever o mapeamento. Isso resolve 90% dos casos, mas quebra a correspondência física visual, então precisa ser documentado.
Outra armadilha comum é a confusão entre dead keys e combos ativos. No layout US International, digitar AltGr + N produz Ñ, mas AltGr + S produz ¢. Muitos tutoriais simplificam dizendo "tecle AltGr mais a letra", mas omitem que a combinação depende do keysym atribuído pelo layout, não da posição física. Se você tentar reproduzir isso num layout ABNT2, vai achar que AltGr + N não funciona como esperado. O keysym correspondente é diferente e, em muitos casos, a combinação é capturada pelo sistema como um atalho composto em vez de produzir o caractere. Para quem precisa de referências técnicas, a lista oficial de keysyms do X.Org Project é a fonte mais precisa. Ela enumera códigos como U+00A3 para a libra (£) e U+00B6 para o pilcrow (§). Ferramentas de automação frequentemente usam esses valores hexadecimais internamente. Se você está criando um mapeamento cross-platform, converter os nomes por extenso para esses pontos de código elimina ambiguidade.
O maior gargalo atual é a falta de padronização entre SOs. O mesmo teclado físico gera events diferentes no Windows, no Linux e no macOS. Se seu fluxo de trabalho depende de símbolos como §, ¶, ©, ™, ou @em conjunções com modificadores, teste o mapeamento em todos os ambientes antes de depender deles em scripts automatizados. A diferença costuma ser de microssegundos na captura, mas suficiente para quebrar pipelines de integração. Se a automação de teclas for crítica, considere usar uma camada intermediária como QMK para firmwares de teclado customizado ou Keyboard Viewer no macOS para validação visual. A maioria dos erros acontece porque o mapeamento lógico não reflete o mapeamento físico real do dispositivo.
