Hi I am storing some images in MySQL DB in a LONGBLOB field. Whenever this image is stored MySQL sets the function for this column to UNHEX. I dont want this to be automatically set to that. My BLOBs used to work fine when this was not set. How do I remove this UNHEX being set by default.
I am using phpmyadmin, MySQL, InnoDB and PHP to retrieve those images. I used to get back the images perfectly fine before we migrated to a new version of phpmyadmin.
Please help.
If you check the phpmyadmin changelog (http://demo.phpmyadmin.net/master-config/changelog.php), it does appear there are a few issues noted regarding this problem with earlier versions of PMA (see the note under 3.4.0.0 about defaulting to UNHEX). You might want to upgrade to the latest version and see if these problems still exist.
Related
This question already has answers here:
UTF-8 all the way through
(13 answers)
Closed 12 months ago.
I'm migrating my existent database into another server. To achieve that I've exported and imported the database using phpMyAdmin SQL queries. Everything works fine, except that some UTF-8 characters appear broken in the website. I fetch them using the same PHP code (on a different server but with same PHP extensions and version).
Example of a string as I see it on the new website and on the databases (both old and new) (using phpMyAdmin): péri-prothétique
Example of a string as I see it in the old website péri-prothétique
As you can see, PHP used to automatically encode the characters the right way even thought the characters are mangled in the database, but doesn't do so anymore (not even if i explicitly utf8_encode or utf8_decode the result). I even tried forcing $mysqli->set_charset("UTF8") on every connection to no avail.
Both the web server, the database server,server connection, PHP and the tables use UTF-8 or utf8mb4 charset and collation, and are setup the same way as the old ones.
The only difference I see is that the new database server is MariaDB instead of MySQL and its webserver is nginx instead of Apache.
New database specs picture from phpMyAdmin:
Old database specs picture:
New webserver specs on which the website and PHP runs (same specs as old one but different server):
Apache 2.4 PHP 7.0
How can I get back that old correct encoding? Why doesn't PHP automatically decode them right anymore?
UPDATE:
Using mb_detect_encoding I see that PHP in both new and old version detects ASCII or UTF-8 on the query results, depending on whether there's at least an UTF-8 symbol or not.
The issue is that on the new version PHP doesn't display the UTF-8 symbols right even thought it detects the string encoding as UTF-8.
UPDATE 2:
thanks to this question I figured out why my entries were mangled: double encoding arose from the fact that the database collation was latin1_swedish_ci while the tables collation was utf8_general_ci.
This doesn't answer the question thought since the old website was automatically "translating" those mangled characters, rendering them right in the HTML, and I want to replicate that behavior into the new website which is a different one but with the same code and php.ini settings.
To check for double encoding, use SELECT HEX(col)... é should come back C3A9 (proper utf8), but instead shows C383C2A9 (double encoding).
See: Trouble with UTF-8 characters; what I see is not what I stored
If you have actually determined that you have double encoding, then the fix involves
UPDATE tbl SET col = CONVERT(BINARY(CONVERT(col USING latin1)) USING utf8mb4);
See http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases
Yes, "double encoding" is a silent bug -- two wrongs make a right (sort of).
I think that you should check for your MariaDB configuration.
First check your php code in order to know if there isn't misleading typo ( but i think it doesn't)
Second, check for your MariaDB database/tables structure [extracted from here ]:
SELECT * FROM INFORMATION_SCHEMA.SCHEMATA;
Third, check for your MariaDB files config (my.cnf)[extracted from here ] :
[client]
default-character-set = utf8mb4
[mysqld]
character-set-server = utf8mb4
Then restart your server :
mysql.server restart
Hope it will help you to fix your problem bro.
Bye
Are you expecting the changes on existing data? It will not work. You need to add the data again to see the changes. Remove all the data from the new database and add again.
I'm using Laravel 5.1 on Ubuntu PHP5.6 and the GUID to string conversion is working just fine. However on my development environment in PHP 7 it's pritining out like how it used to when I had to use the old mssql driver that came with php.
So all my string comparisons are failing on 7 for GUID's saved in mysql.
My gut says that some PDO setting that's not being set correctly. The query in question is using the DB class to fetch data through a raw sql. I think Eloquent is rendering correctly, I've not seen this problem before and I've been using it throughout (this is an older code base before I leaned additional tricks I currently use to work with this database)
Any ideas where I can start looking.
Turns out it was the particular set of credentials and set up for the software that was causing the byte problem. I was logging in fine but changing the connection string fixed the problem.
I have a Multilingual Wordpress website on my host (which someone else built), and I want to install a copy of this site on Xampp so that I can make changes.
I don't know phpmyadmin & mysql very well. Usually I just use utf8_general_ci for everything.
After exporting and importing, I kept getting syntax errors. So... I figured this was due to the collation & charset of the database? I checked in the database and next to some of the columns it says "utf8_general_ci", and next to others it says "utf8_unicode_ci", and then at the bottom of the table it says "latin1_swedish_ci". So now I have no clue what the collation of this database is...
How do I know what the collation & charsets of this database is? And how do I export and import everything as is? I heard phpmyadmin automatically converts databases during export... is this true? What must I do to get this database exported and imported correctly?
I use Macs.
For years I have been updating the content of an ExpressionEngine website based on PHP/MySQL. This process involves linking the content of InDesign pages to a Filemaker database, exporting specified fields to an Excel spreadsheet and using Navicat to update corresponding fields in the MySQL database. I know from experiments in linking Filemaker directly to MySQL that character encoding is a minefield.
The process I have outlined has always worked OK, provided in the Navicat import step I specify that the Excel spreadsheet is using Mac OS Roman encoding. This year, however, the result of the updating was garbage where I should have accented characters or fancy "typesetting" characters - en rules, inverted commmas etc.
What had changed? Well, I am using a new Mac, running Yosemite. I still have my old iMac, now in use as a second display, so I went back to that. Result: perfect. No garbage.
I have of course checked that the Excel file's text looks OK. (I am using the same file on both Macs, shared via Dropbox.) I'm running the same version of Navicat on both Macs.
So what is Yosemite doing to cause Navicat to stuff different characters into MySQL? And how can I stop it?
Chris
I was learning some web design about 18+ months ago and got caught up on some other things and had to stop for a while. I'm getting back into web design again. I used xampp back then and using xampp now also. I found my old xampp zip of the entire folder. I extracted it thinking I might get lucky and get my databases back from mysql. I go into the xampp\mysql\data and I copied all the folders with the databases I wanted to put into the new mysql. I loaded up phpmyadmin and the databases are there but they are all empty.
The main database I want to save has these files inside of it...
db.opt
pcms_categories.frm
pcms_meta.frm
pcms_posts.frm
pcms_users.frm
so I see the table files there but mysql isn't loading them. I assume maybe it's an older version and it won't read these files because they are obsolete. I'm not sure. After transferring the files I stopped mysql and reloaded it so just wanted to mention that.
It's been so long ago that it doesn't exactly matter if I can recover this data. I was working on a blog though would be cool to get that back and finish what I started.
try to dump it to .sql perhaps?
in other word, export/import.
First, I'd check for permission issues. MySQL usually requires special permissions on its datafiles. Check to see if MySQL has created its own user/group. Next, I'd try to find out what version of MySQL you previously had, create an installation of said version, and use it to dump the datafiles to SQL.