I used an Oracle 11g EE to create my database and access it through PHP using PDO, and all was working good. But i had to change to 11g XE because i wanted to use it freely inside my company. Now, greek characters won't display on PHP (i get �������� instead). I tried to change the character set with :
shutdown immediate;
startup mount;
alter system enable restricted session;
alter system set job_queue_processes=0;
alter database open;
alter database character set internal_use EL8MSWIN1253;
shutdown immediate;
startup;
But i ended up corrupting the CLOBs.
Now, after reverting to the last known good backup i am trying to use CSSCAN but i cannot find it inside my bin folder or anywhere to download.
Any thoughts on this??
I really need to make it work..
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?
If I have a .php file with some Oracle code previously accessing a Oracle DB, but have setup a MySQL DB and want to edit the existing .php file to be compatible with the MySQL DB, how would I go about doing this? Do I have to manually go through each line and search for the equivalent MySQL statement, and if so, is there a library I can access that gives me the Oracle to MySQL equivalent command?
There is this website with a good compilation of tips and tools to help you out on this task: http://www.sqlines.com/oracle-to-mysql
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