MYSQL | ENCODE() outputs blob instead of text - mysql

Im trying to encode a simple string by the ENCODE()-function. Using a string it gives me text as output. But using a field it gives me BLOB. How can I get around BLOB and output text for encoded fields?
Here's what happens:
SELECT ENCODE('myText,'myPw')
- Output: baddade4b04e // Goal = This + using fieldname
SELECT ENCODE(Field,'myPw') FROM myTable
- Output: [BLOB - 14B]
What I've tried:
SELECT CAST(ENCODE(Field,'myPw') AS CHAR(1000) CHARACTER SET utf8) FROM myTable
- Output: Empty rows!
SELECT CONVERT(ENCODE(Field,'myPw') USING utf8) FROM myTable
- Output: % (Output is 1-2 chars, cant be right)
Imagine I have a column user. Now I want "PaulPeter" being encoded the same regardless of whether Im encoding the string "PaulPeter" or the field user where the value is "PaulPeter".
Could anyone explain this to me? Thanks very much!
Encrypted string:
Encrypted field:
MySQL-Client-Version: 5.5.41
user: text utf8_bin
EDIT:
I got another question according decoding here: Click
After being able to encode, I got the same problem there with AES_Encryption. When I encrypt a string I get the output as a string. When encrypting a field with a string-value I get blob. :( Totally annoying.

Your user column is of type TEXT. Try casting just that column to CHAR:
SELECT AES_ENCRYPT(CAST(Field AS CHAR(1000)),'myPw') FROM myTable

Related

Using REPLACE with CHAR(160) is Returning Hexadecimal as Value

I am trying to get rid of &nbsp characters in MYSQL, but am getting weird behavior where using REPLACE is returning a hexadecimal string.
The original value is some HTML stored in a field with the type BLOB:
<h3>This was just an appetizer. Are you ready for the full course?</h3><p>Dive into more business news, check out the latest tech trends, and get a couple quick tips from our health section.  </p></div>
The SQL I am using is this:
UPDATE tbl
SET field = REPLACE(field, CHAR(160), '');
And after executing, this is what is left in the database:
3C68333E5468697320776173206A75737420616E206170706574697A65722E2041726520796F7520726561647920666F72207468652066756C6C20636F757273653F3C2F68333E3C703E4469766520696E746F206D6F726520627573696E657373206E6577732C20636865636B206F757420746865206C61746573742074656368207472656E64732C20616E6420676574206120636F75706C6520717569636B20746970732066726F6D206F7572206865616C74682073656374696F6E2E20C23C2F703E3C2F6469763E
What is going on and how could I avoid this? Do I need to use VARCHAR for the field type?
You get (binary) BLOB back, after the replace.
so you have to convert it back to text
UPDATE tbl
SET field = CAST(REPLACE(field, CHAR(160), '')AS CHAR(10000) CHARACTER SET utf8);
Of course you have to check character set and size.
I found that CHAR codes didn't work, but a copy pasted whitespace worked. This looks like a normal space, but is in fact CHAR(160) and I don't have an error anymore. ' '

How can I convert BLOB to text in MySQL?

I have a BLOB field in one of tables and I used the following command to convert it to text:
ALTER TABLE mytable
ADD COLUMN field1_new TEXT;
update mytable set
field1_new = CONVERT(field1 USING utf8);
This did not work and gave me some random characters. Like:
9x
This result is returned as a content of message which does not make sense. I changed the character set to 'latin1'. This one gave me a larger sequence of characters yet still something non-sense. For example:
¢xœ}T]k1|/ô?¬Á/‡ZJpMK“–<$„Ô¥ôqO§»ÑI®¤³¹ß...
Is there anyway to figure out what character set the BLOB field is using so that I can convert it to text properly?
Any help with this problem will be much appreciated. Thanks
Edited: I have to also mention that I used CAST command and it returned:
�x�}T]k1|/�?��/��ZJpMK��<$�ԥ�qO���I������������$:���̬�4�...
try using cast:
CAST(field1 AS CHAR(10000) CHARACTER SET utf8)
you can see this post also for more:How do I convert from BLOB to TEXT in MySQL?

MySQL CONCAT("string",longtext) results in hex string

I'm experiencing a weird hex string result when trying to concat a string with a column that should be of LONGTEXT type.
The query goes like this:
SELECT concat("abc",t.LONGTEXT_VALUE,"cde") FROM mytable t
61626354657374696e67636465
The hex string 61626354657374696e67636465 is the correct value, just in hexadecimal form.
A SELECT on the column itself will return the normal string:
SELECT t.LONGTEXT_VALUE FROM mytable t
Testing
Have you tried casting? Usually works pretty well for me. Example:
SELECT CONCAT("abc",CAST(t.LONGTEXT_VALUE AS CHAR),"cde") FROM mytable t
When you concat a number without a cast it returns as a blob. This is intended functionality of MySQL as far as I can tell since, it was reported in this bug thread and they closed it and confirmed it was returning a Blob.

How to edit invalid UTF-8 strings in mysql database

I have some utf-8 strings in my database, they are stored as varbinary. (Generally, it's mediawiki database, but that's not important, i think). I found that some strings are not in a good shape, then i make
SELECT log_comment, CONVERT( log_comment
USING utf8 ) AS
COMMENT
FROM `logging`
WHERE log_id = %somevalue%
i have output table in phpmyadmin like this:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| d093d09ed0a1d0a220d0a020d098d0a1d09e2fd09cd0add09a20393239342d39332e20c2abd098d0bdd184d0bed180d0bcd0b0d186d0b8d0bed0bdd0bdd0b0d18f20d182d0b5d185d0bdd0bed0bbd0bed0b3d0b8d18f2e2e2e |NULL |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
What i need is to make this string readible, or upload new string with correct data. But this is varbinary field, how can i manage data inside it?
UPD:
found that phpmyadmin automatically added 2e2e2e for three dots at the end of each line - they were too long to show. Original binary data are, if somebody interested,
d09fd0a02035302e312e3031392d3230303020d09ed181d0bdd0bed0b2d0bdd18bd0b520d0bfd0bed0bbd0bed0b6d0b5d0bdd0b8d18f20d0b5d0b4d0b8d0bdd0bed0b920d181d0b8d181d182d0b5d0bcd18b20d0bad0bbd0b0d181d181d0b8d184d0b8d0bad0b0d186d0b8d0b820d0b820d0bad0bed0b4d0b8d180d0bed0b2d0b0d0bdd0b8d18f20d182d0b5d185d0bdd0b8d0bad0be2dd18dd0bad0bed0bdd0bed0bcd0b8d187d0b5d181d0bad0bed0b920d0b820d181d0bed186d0b8d0b0d0bbd18cd0bdd0bed0b920d0b8d0bdd184d0bed180d0bcd0b0d186d0b8d0b820d0b820d183d0bdd0b8d184d0b8d186d0b8d180d0bed0b2d0b0d0bdd0bdd18bd1
anyway those strings contains non-utf symbols at the line end, as it seems from
SELECT log_comment,CAST(log_comment AS CHAR CHARACTER SET utf8) AS COMMENT
FROM `logging`
WHERE log_id = %somevalue%
because last symbol is � - for me it seems as black rhomb with white question in it, and last 20-30 characters are missing
SELECT log_comment,CAST(log_comment AS CHAR CHARACTER SET utf8) AS COMMENT
FROM `logging`
WHERE log_id = %somevalue%
As it was said in Joni's comment,
"The length of the text is exactly 255 bytes, which is the limit of a
MySQL tinytext/tinyblob field, and also often used by programmers as
the size for varchar/varbinary. It looks like your original data has
been clipped. The last D1 in your original data starts a new UTF-8
character, but the second byte is missing; that's why the last
character is broken in the converted text."
In the MediaWiki DB in the field [log_comment] of the table [logging] should be stored headers of pages that was altered. Some of them appeared to be longer than 255 symbols, so while being logged they were clipped. That confused me; I thought that there was kind of database error, so i should just alter those strings - add to them missing symbols. Now i see it is slightly possible, so i just can gather necessary information from other fields.
try this:
SELECT log_comment,
CONVERT(log_comment,VARCHAR(65535)) AS COMMENT
FROM `logging`
WHERE log_id = %somevalue%

base64 decode a mysql column before performing a WHERE

Basically - its a long story - but I have a field in a database that is encoded as a base64 string.
EG: this is stored in the database:
YToyOntzOjIwOiJUeXBlX29mX29yZ2FuaXNhdGlvbiI7czoyMDoiTWVtYmVyIG9mIFBhcmxpYW1lbnQiO3M6ODoiUG9zdGNvZGUiO3M6NzoiUEUxIDFKQSI7fQ==
Which equals this:
a:2:{s:20:"Type_of_organisation";s:20:"Member of Parliament";s:8:"Postcode";s:7:"#postcode#";}
What I want to be able to do is select where this string LIKE '%Member of Parliament%'. Is there any way to base64 decode a mysql column before performing a WHERE?
eg: SELECT * FROM table WHERE base64_decode(column) LIKE '%Member of Parliament%'
Thanks
If you're using MySQL 5.6.1 or higher you can use the FROM_BASE64() function:
Takes a string encoded with the base-64 encoded rules used by TO_BASE64() and returns the decoded result as a binary string. The result is NULL if the argument is NULL or not a valid base-64 string. See the description of TO_BASE64() for details about the encoding and decoding rules.
This function was added in MySQL 5.6.1.
mysql> SELECT TO_BASE64('abc'), FROM_BASE64(TO_BASE64('abc'));
-> 'JWJj', 'abc'
http://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_from-base64
Otherwise you can use the User Defined Function from: https://github.com/y-ken/mysql-udf-base64