Я думаю, что преобразователь «ASCII to HEX» возвратил другое шестнадцатеричное представление, потому что вход был указан как ASCII, а не UTF-8.
Второй символ в строке Æ выглядит как латинский верхний чехол AE diphthong.
Кодировка UTF-8, отображаемая как HEX, составляет C386
. Это то, что возвращала функция MySQL HEX.
Если в сеансе MySQL используется utf8, то оказывается, что функция MySQL HEX
возвращает строку, которую мы ожидаем. (Я только дошел до проверки этого второго символа.)
Похоже, что наблюдаемое поведение MySQL соответствует документированной спецификации.
Значение СИМВОЛ (20), но то, что CharacterSet является то, что значение? Из того, что мы видим, это не похоже на ASCII или расширенный ASCII. Это похоже на UTF-8.
Ссылки: (! ОТСУТСТВИЕ отговорки)
Абсолютный минимум каждый разработчик программного обеспечения Абсолютно положительно должны знать о Unicode и наборов символов,
https://www.joelonsoftware.com/articles/Unicode.html
Что каждый программист Абсолютно , Положительно нужно знать о кодировках и наборах символов для работы с текстом
http://kunststube.net/encoding/
Followup
SELECT HEX('_ÆúÛlw¦™‹Q|Ý"9Õ') AS utf8
utf8
------------------------------------------------------
5FC386C3BAC39B6C77C2A6E284A2E280B9517CC39DC2AD2239C395
SELECT HEX(CONVERT('_ÆúÛlw¦™‹Q|Ý"9Õ' USING latin1)) AS latin1
latin1
--------------------------------
5FC6FADB6C77A6998B517CDDAD2239D5
кодирование utf8
HEX('_') HEX('Æ') HEX('ú') HEX('Û') HEX('l') HEX('w') HEX('¦') HEX('™')
-------- -------- -------- --------- -------- -------- -------- --------
5F C386 C3BA C39B 6C 77 C2A6 E284A2
HEX('‹') HEX('Q') HEX('|') HEX('Ý') HEX('') HEX('"') HEX('9') HEX('Õ')
-------- -------- -------- -------- -------- -------- -------- ---------
E280B9 51 7C C39D C2AD 22 39 C395
latin1 кодирования
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
5F C6 FA DB 6C 77 A6 99 8B 51 7C DD AD 22 39 D5
, если мы начнем с шестнадцатиричное представление, что вы говорите, является «кор Rect», и показать кодировку UTF8 для этого ...
SELECT HEX(CONVERT(CONVERT(UNHEX('5FC6FADB6C77A6998B510C7CDD0419AD221A39D5') USING latin1) USING utf8))
-- ---- ---- ---- -- -- ---- ------ ------ -- -- -- ---- -- -- ---- -- -- -- ----
5F C386 C3BA C39B 6C 77 C2A6 E284A2 E280B9 51 0C 7C C39D 04 19 C2AD 22 1A 39 C395
^^ ^^ ^^ ^^
Мы видим, что строка содержит четыре непечатаемые символы. И эта кодировка требует 31 байта или 62 шестнадцатеричных разряда.
Если я перехожу на http://www.yellowpipe.com/yis/tools/encrypter/index.php и использую ASCII для ввода шестнадцатеричного кода и вводя этот код, я получаю соответствующую шестую строку, соответствующую шестнадцатеричной форме, в файлы, которые вам нужны чтобы совместить гекс в базе данных. Вот почему я сказал его ASCII, потому что этот сайт преобразован из ASCII в HEX. Оба cols - utf8. Char (20) - utf8_general_ci varchar (40) - utf8_unicode_ci – user6267695
Я думаю, что проблема, о которой вы сообщаете, произошла до функции HEX ... функция HEX просто раскрывает проблему. Функция MySQL 'HEX' корректно преобразует кодированное значение UTF-8 в шестнадцатеричное представление. Учитывая кодовые точки 'U + 005F U + 00C6 U + 00FA U + 00DB', кодировка UTF-16 будет выглядеть как' 0x 005F 00C6 00FA 00DB' '. Кодировка ASCII будет выглядеть как '0x 5F C6 FA DB''. И кодировка UTF-8 этих кодовых точек будет выглядеть так: «0x 5F C386 C3BA C39B'' – spencer7593
и что мне делать? – user6267695