I'm using the MySQL Command Lind Tool on MacOS using the command: mysql -u root -p;
To avoid repetition and to save time, I tried using TextEdit (MacOS's Notepad counterpart) to type queries and then copy them into the MySQL command prompt.
Here I noticed a problem when I was copy-pasting syntactically correct queries.
e.g. select * from club where COACHNAME=‘coolname’;
I finally found that the problem was with the apostrophes.
In any text editor, the apostrophes are tilted in different directions: ‘See the left and right tilted apostrophes on both sides’
But the same doesn't take place in the terminal, or in MySQL (not sure whose default it is).
Wherein the same apostrophes are used for both the start and the end: 'Notice the un-tilted and uniform apostrophes on both sides'
Hence when I was copy pasting: select * from club where COACHNAME=‘coolname’;
I was meant to change the titled-apostrophes to the uniform kind that are built-in, i.e.
select * from club where COACHNAME='coolname';
You can even notice that the apostrophes on Stack Overflow by default are the uniform kind,
whereas those in TextEdit and Notes (and maybe also in Notepad, if somebody could confirm that) are the tilted kind.
Related
I have recently moved from a classic Linux server (using phpMyAdmin 3.3.5) to a cPanel server (using phpMyAdmin 4.0.10) and after multiple attempts was able to import my MediaWiki database. However, I noticed any value that contained non-English characters (Japanese letters or other symbols) appeared entirely in hexadecimal. I have tried pasting in a non-hex equivalent to a hex line, but the result is in 0 lines changing and the value changing back to hexadecimal.
Example of working names on the previous server, seen with values "KrzesłaKonferencyjne" and "Zgłoszenie szkody warta".
Example of non-working names on the current server, seen with values "4b727a6573c582614b6f6e666572656e63796a6e65" and "5a67c5826f737a656e696520737a6b6f6479207761727461".
What can be done to fix this?
I am using JSP servlets and have a mysql database. I have an input field "Introduction". The error is when a user copy pastes a para from word then the character "(double quotes) is entered as ? in my table but only when the character is copied from a word or some other source. Also, if a user copies two paragraph's with spaces in between then a buggy character enters my sql table and the JS which is trying to load the introduction in my jsp page fails. i have also attached the screenshot for this. Please help me how can i resolve this.
MicroSoft, in its infinite wisdom, decided to have non-standard double quotes -- a left version and a right version. But that should be fixable, since those quotes do exist somewhere in the huge world of utf8 characters.
However, the data from your 'copy' was probably not copied in utf8 encoding. Since is is unclear how that is being done, we can't give you complete details on fixing it.
The "best" plan is to establish "utf8" at all stages of data/client/server/database/table/column/etc.
The quick-and-dirty fix is to replace the funny quotes with ascii quotes.
Somewhere along the way, between all the imports and exports I have done, a lot of the text on a blog I run is full of weird accented A characters.
When I export the data using mysqldump and load it into a text editor with the intention of using search-and-replace to clear out the bad characters, searching just matches every "a" character.
Does anyone know any way I can successfully hunt down these characters and get rid of them, either directly in MySQL or by using mysqldump and then reimporting the content?
This is an encoding problem; the  is a non-breaking space (HTML entity ) in Unicode being displayed in Latin1.
You might try something like this... first we check to make sure the matching is working:
SELECT * FROM some_table WHERE some_field LIKE BINARY '%Â%'
This should return any rows in some_table where some_field has a bad character. Assuming that works properly and you find the rows you're looking for, try this:
UPDATE some_table SET some_field = REPLACE( some_field, BINARY 'Â', '' )
And that should remove those characters (based on the page you linked, you don't really want an nbsp there as you would end up with three spaces in a row between sentences etc, you should only have one).
If it doesn't work then you'll need to look at the encoding and collation being used.
EDIT: Just added BINARY to the strings; this should hopefully make it work regardless of encoding.
The accepted answer did not work for me.
From here http://nicj.net/mysql-converting-an-incorrect-latin1-column-to-utf8/ I have found that the binary code for  character is c2a0 (by converting the column to VARBINARY and looking what it turns to).
Then here http://www.oneminuteinfo.com/2013/11/mysql-replace-non-ascii-characters.html found the actual solution to remove (replace) it:
update entry set english_translation = unhex(replace(hex(english_translation),'C2A0','20')) where entry_id = 4008;
The query above replaces it to a space, then a normal trim can be applied or simply replace to '' instead.
I have had this problem and it is annoying, but solvable. As well as  you may find you have a whole load of characters showing up in your data like these:
“
This is connected to encoding changes in the database, but so long as you do not have any of these characters in your database that you want to keep (e.g. if you are actually using a Euro symbol) then you can strip them out with a few MySQL commands as previously suggested.
In my case I had this problem with a Wordpress database that I had inherited, and I found a useful set of pre-formed queries that work for Wordpress here http://digwp.com/2011/07/clean-up-weird-characters-in-database/
It's also worth noting that one of the causes of the problem in the first place is opening a database in a text editor which might change the encoding in some way. So if you can possibly manipulate the database using MySQL only and not a text editor this will reduce the risk of causing further trouble.
I have a MySQL database containing a table with a binary-typed column. I'd like to be able to project that column without having to run it through, e.g., HEX(). Does the mysql CLI tool have a configuration option or other means to display a representation of binary data in a manner that won't output arbitrary bytes for my console to interpret in hilarious/annoying ways?
Start MySQL CLI with param --binary-as-hex
Example:
mysql --binary-as-hex
Set mysql client options in /etc/my.cnf works for me:
[client]
binary-as-hex = true
[mysql]
binary-as-hex = true
Since you want to look at the table mostly for convenience, create a view:
CREATE OR REPLACE VIEW myview AS
SELECT col1, HEX(col2) AS col2, col3, etc....
FROM table;
Then, all you have to do is reference myview instead of table:
SELECT * FROM myview;
The behavior of the MySQL command line client when viewing result sets with binary data has always been an annoyance to me, in fact I found this page because I was once again annoyed by the MySQL command line client (dumping binary data into my terminal when looking at a result set with binary UUID columns) and I wanted to solve the issue once and for all :-)
Creating views really isn't an option for me (I'm looking at dozens of tables with binary UUID columns) and I also found that it's really annoying to switch from SELECT * to typing out all of the column names instead (just so HEX() can be applied to the value of one column).
Eventually I came up with a creative hack that provides inspiration for alternative solutions to this annoyance: Using a custom pager command to sanitize output for terminal rendering. Here's how it works:
Create an executable (chmod +x) Python script with the following contents:
#!/usr/bin/python
import binascii, string, sys
for line in sys.stdin:
line = line.rstrip()
column, _, value = line.partition(': ')
if any(c not in string.printable for c in value):
sys.stdout.write("%s: %s\n" % (column, binascii.hexlify(value)))
else:
sys.stdout.write("%s\n" % line)
Start the MySQL command line client as follows:
$ mysql --pager=/home/peter/binary-filter.py --vertical ...
Change the pathname of the Python script as applicable. You can also put the script in your $PATH, in that case you can just pass the name to the --pager option (similar to how you would use less as a pager for the MySQL client).
Now when you SELECT ..., any line that shows a column whose value contains non-printable characters is rewritten so that the complete value is rendered as hexadecimal characters, similar to the results of MySQL's HEX() function.
Disclaimer: This is far from a complete solution, for example the Python snippet I showed expects SELECT ... \G format output (hence the --vertical option) and I tested it for all of five minutes so it's bound to contain bugs.
My point was to show that the problem can be solved on the side of the MySQL command line client, because that's where the problem is! (this is why it feels backwards for me to define server side views - only to make a command line client more user friendly :-P)
For me there is no problem with database size, so I will use two different column in every table, one as binary(16), and the second as char(32) without indexing. both of them will have the same value.
when I need to search I will use binary column, and when I need to read I will use char(32).
is there any problem with this scenario?
I'm using MySQL Workbench CE 5.2.30 CE / Rev 6790 . When execute the following statement:
SELECT OLD_PASSWORD("test")
I only get back a nice BLOB icon, I need to left-click to select the cell, right-click and choose "Open Value in viewer" and select the "Text" tab.
Using the same with phpMyAdmin, I get directly back the value of the OLD_PASSWORD call. It's just an example, but is there a way to directly see such results in the output?
In short:
Go to Edit > Preferences
Choose SQL Editor
Under SQL Execution, check Treat BINARY/VARBINARY as nonbinary character string
Restart MySQL Workbench (you will not be prompted or informed of this requirement).
In MySQL Workbench 6.0+
Go to Edit > Preferences
Choose SQL Queries
Under Query Results, check Treat BINARY/VARBINARY as nonbinary character string
It's not mandatory to restart MySQL Workbench (you will not be prompted or informed of this requirement).*
With this setting you will be able to concatenate fields without getting blobs.
I think this applies to versions 5.2.22 and later and is the result of this MySQL bug.
Disclaimer: I don't know what the downside of this setting is - maybe when you are selecting BINARY/VARBINARY values you will see it as plain text which may be misleading and/or maybe it will hinder performance if they are large enough?
I'm not sure if this answers the question but if if you right click on the "blob" icon in the field (when viewing the table) there is an option to "Open Value in Editor". One of the tabs lets you view the blob. This is in ver. 5.2.34
Perform three steps:
Go to "WorkBench Preferences" --> Choose "SQL Editor" Under "Query Results": check "Treat BINARY/VARBINARY as nonbinary character string"
Restart MySQL WorkBench.
Now select SELECT SUBSTRING(<BLOB_COLUMN_NAME>,1,2500) FROM <Table_name>;
casting works, but it is a pain, so I would recommend using spioter's method unless you are using a lot of truly blob data.
SELECT CAST(OLD_PASSWORD("test") AS CHAR)
You can also cast as other types, and even restrict the size, but most of the time I just use CHAR:
http://dev.mysql.com/doc/refman/5.5/en/cast-functions.html#function_cast
select CONVERT((column_name) USING utf8) FROM table;
In my case, Workbench does not work. so i used the above solution to show blob data as text.
Doesn't seem to be possible I'm afraid, its listed as a bug in workbench:
http://bugs.mysql.com/bug.php?id=50692
It would be very useful though!
had the same problem, according to the MySQL documentation, you can select a Substring of a BLOB:
SELECT id, SUBSTRING(comment,1,2000) FROM t
HTH, glissi
I pieced a few of the other posts together, as the workbench 'preferences' fix did not work for me. (WB 6.3)
SELECT CAST(`column` AS CHAR(10000) CHARACTER SET utf8) FROM `table`;
Work bench 6.3
Follow High scoring answer then use UNCOMPRESS()
(In short:
1. Go to Edit > Preferences
2. Choose SQL Editor
3. Under SQL Execution, check Treat BINARY/VARBINARY as nonbinary character string
4. Restart MySQL Workbench (you will not be prompted or informed of this requirement).)
Then
SELECT SUBSTRING(UNCOMPRESS(<COLUMN_NAME>),1,2500) FROM <Table_name>;
or
SELECT CAST(UNCOMPRESS(<COLUMN_NAME>) AS CHAR) FROM <Table_name>;
If you just put UNCOMPRESS(<COLUMN_NAME>) you can right click blob and click "Open Value in Editor".
there is few things that you can do
SELECT GROUP_CONCAT(CAST(name AS CHAR))
FROM product
WHERE id IN (12345,12346,12347)
If you want to order by the query you can order by cast as well like below
SELECT GROUP_CONCAT(name ORDER BY name))
FROM product
WHERE id IN (12345,12346,12347)
as it says on this blog
http://www.kdecom.com/mysql-group-concat-blob-bug-solved/
NOTE: The previous answers here aren't particularly useful if the BLOB is an arbitrary sequence of bytes; e.g. BINARY(16) to store 128-bit GUID or md5 checksum.
In that case, there currently is no editor preference -- though I have submitted a feature request now -- see that request for more detailed explanation.
[Until/unless that feature request is implemented], the solution is HEX function in a query: SELECT HEX(mybinarycolumn) FROM mytable.
An alternative is to use phpMyAdmin instead of MySQL Workbench - there hex is shown by default.