That's a nifty function. Good to know that it can be reversed. I noticed that it was mentioned in DBD::mysql # 117 that DBD::mysql does know that a column in a returned resultset is a BLOB. One should also consider the performance penalty of encoding/decoding BLOB's as they can be big.
On Tue, Sep 26, 2017 at 12:34 PM, demerphq <demer...@gmail.com> wrote: > On 26 September 2017 at 12:15, Night Light <nightligh...@gmail.com> wrote: > > The corruption is caused by the fact that the data type of a BLOB can > not be > > recognized and is therefore UTF8 encoded like a string before being sent > to > > MySQL. > > Which means it can be fixed. And in a sane scenario will be detectable. > > Corruption implies the inability to reverse the operation. > > UTF8 encoding can be reversed. > > Any sane use of BLOB for binary data that MIGHT be corrupted by this > bug would be repairable by something like recurse_decode_utf8(). > > Consider the only case where something like recurse_decode_utf8() > would fail is where you *deliberately* want to store multiply encoded > utf8 in the database as binary. > > Any "sane" data that contained *any* sequence of bytes which was not a > valid UTF8 sequence would be trivially restored by a function like > recurse_decode_utf8(). > > I totally agree that the driver messing up data is undesirable. But it > is not "corrupted". It is transformed in a way that can be reversed > and fixed. > > Yves >
