Dati blob esportati diversi dai dati DB

Question

Sto tentando di esportare il nostro database MySQL molto grande (1,6 GB - per lo più BLOB) e l'importazione in un nuovo server. Ho lavorato nella maggior parte dei problemi e finalmente completato l'importazione senza errori. Utilizzo di MySQL Query Browser Ho eseguito una query su una tabella con BLOB di immagini e ne ho salvata una su disco (utilizzando l'icona di salvataggio nel browser di query). Quando ho provato ad aprire il file ho ricevuto un errore di "formato immagine non valido". Uh Oh.

Utilizzo del browser di query Ho ispezionato il valore nel database di origine e il nuovo database recentemente importato. I valori sono diversi, penso. Potrebbe essere solo problemi di codifica o qualcosa del genere. Ecco quello che ho visto:

Fonte (dati validi) server:

FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 60 
00 60 00 00 FF DB 00 43 00 08 06 06 07 06 05 08 
and so on... 

Nuovo server:

C3 BF C3 98 C3 BF C3 A0 00 10 4A 46 49 46 00 01 
01 01 00 60 00 60 00 00 C3 BF C3 9B 00 43 00 08 
and so on... 

In questo esempio appare ai miei occhi newbie che ci sono 3 byte di più dati nella parte anteriore dei dati sul "nuovo" server.

Ho quindi controllato il file di dump sql utilizzando 010 editor. Ho trovato la linea per questo particolare esempio ed ecco quello che vedo:

FF D8 FF E0 5C 30 10 4A 46 49 46 5C 30 01 01 01 
5C 30 60 5C 30 60 5C 30 5C 30 FF DB 5C 30 43 5C 
30 08 06 06 07 06 05 08 and so on... 

Ora sono sopra la mia testa. Vedo il modello, noto che la coppia HEX 5C 30 sembra essere la stessa di 00 ma non capisco PERCHE '. A questo punto ho un server di origine che sta per essere cancellato e uno nuovo che temo abbia importato dati corrotti in esso. Spero che questo sia un qualche tipo di problema di codifica che può essere risolto impostando una variabile globale in MySQL ma davvero non lo so.

Devo anche menzionare che quando salvi i file dal server di origine (di lavoro) e dal nuovo server (corrotto) la dimensione dei file è circa il 40% più grande per il file corrotto.

Ho controllato le variabili set di caratteri su entrambi i server: il server

SHOW VARIABLES LIKE '%char%' 

fonte:

character_set_client  utf8 
character_set_connection utf8 
character_set_database latin1 
character_set_filesystem binary 
character_set_results  utf8 
character_set_server  latin1 
character_set_system  utf8 

nuovo server:

character_set_client  utf8 
character_set_connection utf8 
character_set_database latin1 
character_set_filesystem binary 
character_set_results  utf8 
character_set_server  latin1 
character_set_system  utf8 

sono la stessa cosa.

Answer 1

I dati danneggiati dal nuovo database si presenta come il risultato di convertire i dati di origine da ISO-8859-1 a UTF-8 (per esempio U + 00FF - Y - è FF nel primo e nel secondo C3 BF).

Poiché i BLOB non hanno set di caratteri, la codifica dei caratteri non è controllata dalle variabili del server; Ho il sospetto che l'mysqldump stia emettendo i dati BLOB in un file con codifica UTF-8 (which is the default) e che sia codificato lungo il percorso in qualche modo, attraverso una combinazione di impostazioni del server e opzioni passate a mysqldump.

La soluzione migliore potrebbe essere quella di utilizzare l'opzione --hex-blob durante l'esportazione campi BLOB, che si tradurrebbe in qualcosa di simile:

INSERT INTO `table` VALUES (0xFFD8FFE0...);