Как вставить произвольные двоичные данные в столбец VARCHAR?

Question

У меня есть таблица MySQL с столбцом VARCHAR(100) с использованием сопоставления utf8_general_ci.

Я могу видеть строки, в которых этот столбец содержит произвольные последовательности байтов (т.е. данные, содержащие недопустимые последовательности символов UTF8), но я не могу понять, как написать инструкцию UPDATE или INSERT, которая позволяет вводить данные такого типа ,

Например, я попытался следующие:

UPDATE DataTable SET Data = CAST(BINARY(X'16d7a4fca7442dda3ad93c9a726597e4') AS CHAR(100)) WHERE Id = 1; 

Но я получаю ошибку:

Incorrect string value: '\xFC\xA7D-\xDA:...' for column 'Data' at row 1 

Как я могу написать заявление INSERT или UPDATE, которая обходит параметры сортировки столбца-адресата, позволяя мне вставлять произвольные последовательности байтов?

Answer 1

Считаете ли вы использование одного из типов данных Blob вместо varchar? Я считаю, что это избавит вас от боли.

EDIT: В качестве альтернативы существуют функции HEX and UNHEX, которые поддерживает MySQL. Hex принимает либо str, либо числовой аргумент и возвращает шестнадцатеричное представление вашего аргумента в виде строки. Unhex делает обратный; взяв шестнадцатеричную строку и вернув двоичную строку.

Answer 2

Вы должны base64 кодировать значение заранее, так что вы можете создать действительный SQL с ним:

UPDATE DataTable SET Data = from_base64('mybase64-encoded-representation-of-my-value') WHERE Id = 1; 

Answer 3

Короткий ответ, что это не должно быть возможным, чтобы вставить значения с недопустимыми символами UTF8 в VARCHAR столбца, объявленного для использования символов UTF8.

Это цель дизайна MySQL, чтобы запретить недопустимые значения. Когда есть попытка сделать это, MySQL вернет либо ошибку, либо предупреждение, либо (более снисходительно?) Молча урезает предоставленное значение при первом недействительном символе.

Более обычное разнообразие проблем с символами связано с тем, что MySQL выполняет преобразование символов, когда преобразование символов не требуется.

Но проблема, о которой вы сообщаете, заключается в том, что недопустимые символы были вставлены в столбец UTF8. Это похоже на кодирование latin1 (ISO-8859), и требуется преобразование символов, но было выполнено , но не.

Насколько это касается ... Я считаю, что это возможно в более ранних версиях MySQL. Я считаю, что можно было присвоить значение BINARY, а затем деформировать его в CONVERT(... USING UTF8), а MySQL не будет выполнять проверку набора символов. Я не знаю, возможно ли это с текущими соединителями MySQL.

Если возможно, то это (IMO) ошибка в соединителе.

Единственный способ, которым я могу думать о том, чтобы обойти эту проверку/проверку набора символов, это заставить сервер MySQL доверять клиенту и определить, что проверка набора символов не требуется. (Это также означает, что сервер MySQL не будет делать преобразование символов, клиент лежит на сервере, клиент говорит серверу, что он снабжает действительные символы UTF8.

В принципе, клиент будет сообщать серверу «Привет, сервер, я собираюсь отправлять кодировки символов UTF8».

И сервер говорит: «Хорошо, тогда я не буду преобразовывать символы, потому что мы согласны. И я просто верю, что то, что вы отправляете, является допустимым UTF8».

И тогда клиент озорно хихикает: «Хе-хе, я соврал. Я фактически отправляю кодировки символов, которые недействительны UTF8».

И я думаю, что гораздо более вероятно, чтобы быть в состоянии достичь такого вреда, используя подготовленные заявления со старой школой MySQL C API (mysql_stmt_prepare, mysql_stmt_execute), снабжая nvalid UTF8 кодировок в качестве значений параметров строки связывания. (Бремя на самом деле на клиенте, чтобы предоставить действительные значения для параметров привязки.)