Mi sembra una leggenda metropolitana.
bin2hex() mappa ogni byte nell'input su due byte nell'output ('a' -> '61' ), quindi dovresti notare un aumento significativo della memoria dello script che esegue la query:dovrebbe utilizzare almeno tanta memoria in più rispetto alla lunghezza in byte dei dati binari da inserire.
Inoltre, ciò implica l'esecuzione di bin2hex() su una lunga stringa ci vuole molto più lungo dell'esecuzione di mysql_real_escape string() , che - come spiegato nella Documentazione di MySQL - esegue solo l'escape di 6 caratteri:NULL , \r , \n , \ , , e 'Control-Z'.
Era per la parte PHP, ora per MySQL:il server deve eseguire l'operazione inversa per archiviare i dati correttamente. L'annullamento di una delle funzioni richiede quasi quanto l'operazione originale:la funzione inversa di mysql_real_escape_string() deve sostituire i valori con escape (\\ ) con quelli senza caratteri di escape (\ ), mentre il contrario di bin2hex() dovrebbe sostituire ogni tupla di byte con un nuovo byte.
Da quando ho chiamato mysql_real_escape_string() sui dati binari è sicuro (secondo MySQL e documentazione di PHP o anche solo considerando che l'operazione non effettua altre conversioni oltre a quelle sopra elencate), non avrebbe assolutamente senso eseguire un'operazione così costosa.
