Re: DBD::mysql path forward

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 <[email protected]> wrote:

> On 26 September 2017 at 12:15, Night Light <[email protected]> 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
>