Um emoji destruiu minha tarde.
Eu estava processando 10 mil registros de avaliações de clientes em um pipeline de análise de sentimento no mês passado. Trabalho limpo, fluxo tranquilo: raspar dados, normalizar texto, jogar no TextBlob, extrair scores de sentimento. O script de limpeza funcionava perfeitamente no meu dataset de teste com 500 linhas. Aí mandei pra produção.
Depois de 48 minutos, a coisa toda simplesmente… parou. Sem mensagem de erro. Sem exception. Sem aviso. Só congelado, travado indefinidamente na linha 6.842.
O Pesadelo de Debug Que Ninguém Te Prepara
Meu primeiro instinto? Vazamento de memória. Dez mil linhas não deveriam engasgar uma máquina moderna, mas talvez algo estivesse se acumulando. Reiniciei o processo com memory tracking ligado. Mesmo comportamento exato—travava na linha 6.842. Toda maldita vez.
Abri o CSV e encarei a linha 6.842 manualmente. Nome do cliente: ok. Texto da avaliação: “Este produto é 💩 não comprem.” Rating: 5 estrelas (contraditório, claro, mas sintaticamente válido). Nada que me saltasse aos olhos.
Aí eu vi.
O emoji.
Agora, aqui entra a minha própria negligência. Meu encoding estava travado em encoding='latin-1' porque uma versão anterior do dataset tinha caracteres em espanhol (ñ, á, é, etc.) que quebrava com UTF-8. Aí eu tinha travado ali mesmo.
Latin-1 se dá bem com caracteres europeus. Mas emoji? Isso são caracteres UTF-8 multibyte. Quando o CSV reader do Python encontrou aquele emoji de cocô, não conseguiu decodificar usando Latin-1. E em vez de lançar uma exception—em vez de me dar qualquer feedback—só ficou ali, silenciosamente sufocado.
Meu test set de 500 linhas tinha zero emojis. Os dados de produção tinham 147 emojis espalhados nas 10k linhas. Se tivesse testado com dados reais, teria pegado isso antes do deploy.
Essa é a parte que me irrita. Se eu tivesse testado de verdade com dados representativos de produção em vez de alguma amostra sanitizada, teria pego isso antes de colocar em produção. Mas não é assim que fazemos no mundo real, é? Testamos com datasets de brinquedo e rezamos.
Por Que Falhas Silenciosas São Piores Que Crashes
Um crash teria sido uma benção. Um crash te dá um traceback, um número de linha, uma pista. Isso era um travamento silencioso—o pior tipo de bug. Python só desistiu sem me contar por quê. O módulo csv não lança um erro de encoding nesse cenário; só bloqueia forever tentando decodificar algo que não consegue lidar.
O fix, uma vez que descobri, foi vergonhosamente simples:
import pandas as pd
df = pd.read_csv(
'reviews.csv',
encoding='utf-8',
on_bad_lines='skip' # Pula linhas malformadas em vez de explodir
)
# Se você precisar remover emojis (apesar de eu não ter precisado):
import re
df['review_text'] = df['review_text'].apply(
lambda x: re.sub(r'[^\x00-\x7F]+', '', str(x))
)
df.to_csv('cleaned_reviews.csv', index=False, encoding='utf-8')
Use UTF-8 em tudo. Banco de dados, CSV, respostas de API, logs. Chega de misturar encodings só porque seus dados legados têm alguma peculiaridade estranha de 2019.
Também comecei a fazer logging agressivo de progresso—a cada 1.000 linhas—então se algo quebra de novo, sei exatamente onde sem ter que cavar manualmente em CSVs. Só isso teria cortado meu tempo de debug de 48 minutos para uns 8.
A Lição Real (Spoiler: Não é Sobre Emojis)
Olha, a história do emoji é fofinha. Todo mundo adora um bom “foi derrubado por emoji” para contar na firma. Mas o problema real aqui é disciplina de testes.
Testei com 500 linhas limpas e sanitizadas. Produção tinha 10 mil linhas com lixo real: emojis, edge cases Unicode, mojibake de exports CSV dados errado. Meu test set não era representativo. Culpa minha.
E o segundo problema? Eu não sabia sobre o parâmetro encoding_errors do pandas. Esse parâmetro teria silenciosamente substituído caracteres não parseáveis em vez de travar, ganhando tempo pra investig
