Fo#4-s3 para o PHP

Pela 2ª vez esta semana, só me apetece mandar o PHP para o k4r41$0. E desta vez, pode levar o MySQL com ele. Um dia destes, largo isto e passo-me para o Ruby.

Passei um dia inteiro, das 10 da manhã até agora, a resolver uma merdice que me fez perder 15 horas. Vou deixar isto escrito para ver se não me acontece mais vez nenhuma. Nem aos meus queridos leitores!

Estive a passar tudo para UTF-8: textos em ficheiro e em BD, para poder colocar as línguas que for preciso, no caso do jogo começar a expandir-se. O UTF-8 (Unicode em pedaços [eventualmente múltiplos] de 8 bits) é porreiro, pois permite albergar todos os caracteres de todas as línguas. E como o MySQL suporta UTF-8, decidi tentar.

Primeiro passei os ficheiros PHP todos para UTF. Ainda demorei uns minutos. Depois foi a BD. A 1ª passagem para UTF correu mal. Passei todas as tabelas com strings SQL com este formato:

ALTER TABLE tabela CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

e o MySQL começou a reiniciar-se automaticamente de 2 em 2 minutos. Porra! Lá peguei no backup que tinha feito imediatamente antes e recuperei a BD. Voltei à versão anterior dos ficheiros PHP também e testei: estava tudo OK.

Experimentei de novo. Correu mal outra vez. Voltou tudo ao início.

Brincar, assim, com uma BD que tem mais de 4.2 milhões de registos dá tempo para ir almoçar, fumar um charuto, ver o CSI e sei lá mais o quê.

3ª tentativa. Desta vez comecei a converter por partes. Quando me estava a aproximar do fim, decidi não converter tabelas com campos binários (que é só uma) e correu bem.O PHP estava porreiro, o MySQL também, mas o jogo não funcionava. Talvez fossem só uns pormenores, pensei eu.

Descobri que o Firefox estava a embirrar com os dados em UTF que vinham via Ajax. Mais cegada. Ao fim de mais duas horas, encontrei uma solução. Retirei a linha seguinte, do meu objecto de comunicação Ajax, que estava a obrigar o FF a interpretar o XML de forma estrita e isso colidia com o facto dos dados chegarem em UTF:

xmlHttpReq.overrideMimeType(‘text/xml’);

Depois de retirar esta linha, o Ajax passou a funcionar. Comecei a receber dados. Fui testar o jogo de novo. Agora eram as imagens que não vinham. Tenho as imagens dos objectos do jogo em BD, pois a gestão é muito mais eficaz. E sempre que o PHP lia uma imagem da BD e a enviava para o browser, acrescentava-lhe uns bytes à cabeça (e retirava uns à cauda).

Depois de mais umas 3 horas de “trabalho”, e de consulta de muitos relatórios de bugs, lá encontrei uma solução. Encontrei, não. Percebi. Pois não havia uma solução directa para este problema.

Aqui vai ela: Para ler imagens de bases de dados e enviá-las para o browser com PHP, nenhum dos ficheiros PHP envolvidos pode ser gravado em UTF. Nem o ficheiro de base, nem os includes nem os requires. Caso contrário, o PHP envia uns bytes (BOM = byte mark order) no início da imagem e estraga tudo. Este BOM dá indicação ao browser de que se trata de um ficheiro utf, e é o suficiente para estragar a imagem. O BOM é uma sequência de caracteres: EF BB BF EF BB BF EF BB BF EF BB BF … Aparentemente, pode ser qq sequência de EFBBBF.

Voltei a gravar todos os ficheiros envolvidos na criação de imagens como ANSI e lá comecei a receber as imagens. Merda para isto. Com este nível de produtividade até pareço um funcionário público.


Publicado

em

,

por

Etiquetas:

Comentários

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *