Os símbolos menor e maior na prática técnica
O simbolo menor e maior (\< e \>) aparece o dia inteiro em qualquer stack técnico, mas a forma como as ferramentas lidam com eles varia muito dependendo do contexto. A maioria das pessoas os usa nos tutoriais de introdução e acha que entendeu. Na hora da implementação, os problemas começam.
Como o simbolo menor e maior funciona em HTML e XML
No markup, esses caracteres são reservados porque indicam o início e o fim de uma tag. Se você colocar um < direto no corpo do documento, o navegador tenta interpretá-lo como elemento e quebra a renderização. A solução padrão é usar as entidades de texto: < para o menor e > para o maior. Isso parece óbvio, mas tem um detalhe que quase ninguém menciona. A entidade < funciona tanto no HTML 4.01 quanto no HTML5, mas se o seu documento está em XHTML ou XML bem-formado, você pode ter que usar as entidades numéricas < e > em alguns parsers mais rigorosos que não reconhecem os nomes mnemônicos. Encontrei isso num projeto antigo de integração com um sistema legado que processava XML via XSLT 1.0 num servidor Linux com libxml2 desatualizado. A entidade < era rejeitada e o transformador retornava erro silencioso. O workaround foi mapear as entidades numéricas antes da transformação e isso resolveu. Gastei cerca de três horas pra chegar nesse ponto porque o log não mostrava nada útil.
Sintaxe de comparação em linguagens de programação
Em Python, JavaScript, C, Java e praticamente qualquer linguagem derivada do C, o operador de comparação é o mesmo: \< e \>. A lógica é direta. Mas aí entra a armadilha que começa a dar problema quando você programa em mais de uma linguagem ao mesmo tempo. No JavaScript, a comparação de strings com \< e \> faz ordenação lexicográfica baseada nos pontos de código Unicode. Isso significa que "banana" \> "azeite" retorna true, mas "2" \> "10" também retorna true porque a comparação é caractere por caractere, não numérica. Já em Python, str \< str também é lexicográfico, mas a conversão implícita de tipos que o JS às vezes faz em comparações mistas simplesmente não existe. Em Python, "10" \< "2" é true, mas "10" \< 2 gera TypeError. Se você migra de uma linguagem para outra sem prestar atenção, esse tipo de inconsistência gera bugs que demoram pra achar porque o comportamento depende do runtime.
Operadores de deslocamento de bits
Outro uso comum, dessa vez completamente diferente, é o \>\> e \<\< para deslocamento bit a bit. Aqui o perigo é outro: em algumas linguagens como JavaScript, o operando é truncado para 32 bits assinados. Isso quer dizer que deslocar um número grande pode resultar em comportamento inesperado. Em Python, não há essa limitação, então 1 \<\< 100 funciona perfeitamente e gera um int de qualquer tamanho. Se você escreve código que precisa ser portável entre linguagens, trate deslocamento de bits como uma operação que precisa de validação explícita de faixa antes de executar.
O problema que ninguém avisa sobre escape em queries
Quando você constrói uma query SQL dinamicamente e precisa comparar valores textuais, o uso de \< e \> costuma aparecer junto com concatenação de strings. Isso é um vetor clássico de injeção SQL. A solução não é escapar os símbolos, é usar parameterized queries. A diferença é que parameterized queries também resolvem o problema de formatação e costumam ser mais rápidas porque o banco pode reutilizar o plano de execução. Em produção, essa troca de concatenação por parâmetros reduziu o tempo de resposta de uma consulta que fazia filtro por intervalo de datas de algo em torno de 800ms para cerca de 45ms num banco PostgreSQL com milhões de linhas.
Regex e âncoras
Em expressões regulares, \< e \> às vezes são usados como word boundaries em ferramentas mais antigas ou em bibliotecas específicas. No PCRE e no JavaScript moderno, os word boundary são representados por \b, mas em alguns engines de busca como o grep do POSIX, \
e \> indica início e fim de palavra. Confundir essas convenções já me custou horas depurando um script de validação de entrada que funcionava em desenvolvimento e falhava em produção por causa de uma diferença entre as versões do grep instaladas nos servidores.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Limitações reais
Esses símbolos não são uma solução universal. Eles dependem do contexto de parseamento do parser ou compilador que está lendo seu código. Um character\ less-than\< pode ser operador de comparação, entidade HTML, word boundary em regex ou operador de deslocamento, tudo baseado no ambiente. A maior fonte de bug é assumir que o símbolo faz a mesma coisa em contextos diferentes. Sempre verifique a documentação do runtime específico antes de confiar no comportamento padrão que você aprendeu em outra ferramenta.
Recursos práticos
Se você precisa consultar rapidamente os comportamentos de \< e \> em diferentes linguagens, a tabela abaixo resume o essencial: HTML/XML: use < e > para exibir literalmente. Entidades numéricas < e > para parsers estritos.
JavaScript: comparação lexicográfica para strings, coerção de tipo para números. Cuidado com "10" \> "2". Python: comparação estrita de tipos em strings, deslocamento de bits ilimitado por tamanho de int.
SQL: nunca concatene valores em queries. Use prepared statements com parâmetros nomeados ou posicionados. Regex: \
e \> são word boundary apenas em POSIX grep e similares. Em PCRE e engines modernas, use \b.
O domínio desses detalhes evita retrabalho. A maior parte dos erros relacionados a \< e \> aparece quando o código é copied de um contexto para outro sem adaptação. Leitura atenta da especificação do ambiente que você está usando economiza muito mais tempo do que depurar o resultado depois.
