I use an existing db on our SQL-Server 2008 with Laravel 5.
Many tables and columns contain german umlauts. I've set the charset of the connection to "utf8" and can access tables like Läger without problems.
But I couldn't access columns with umlauts. Every query returns something like
["Stra�e"]=> string(15) "Mainzer Str. 97"
instead of
["Straße"]
I've tested it with charset utf8 and latin1 but it's always the same result.
Any idea how to fix this without changing the existing db?
Related
In a large system based on Mysql 5.5.57 Php 5.6.37 setup
Currently the whole system is working in utf8 including SET NAMES utf8 at the beginning of each db connection.
I need to support emojis in one of the tables so I need to switch it to utf8mb4. I don't want to switch other tables.
My question is - if I change to SET NAMES utf8mb4 for all connections (utf8 and utf8mb4) and switch the specific table only to utf8mb4 (and only write mb4 data to this table). Will the rest of the system work as before?
Can there be any issue from working with SET NAMES utf8mb4 in the utf8 tables/data/connections?
I think there should no problem using SET NAMES utf8mb4 for all connections.
(utf8mb3 is a synonym of utf8 in MySQL; I'll use the former for clarity.)
utf8mb3 is a subset of utf8mb4, so your client's bytes will be happy either way (except for Emoji, which needs utf8mb4). When the bytes get to (or come from) a column that is declared only there will be a check to verify that you are not storing Emoji or certain Chinese characters, but otherwise, it goes through with minimal fuss.
I suggest
ALTER TABLE ... CONVERT TO utf8mb4
as the 'right' way to convert a table. However, it converts all varchar/text columns. This may be bad...
If you JOIN a converted table to an unconverted table, then you will be trying to compare a utf8mb3 string to a utf8mb4 string. MySQL will throw up its hands and convert all rows from one to the other. That is no INDEX will be useful.
So... Be sure to at least be consistent about any columns that are involved in JOINs.
This question is not a duplicate of PHP string comparison between two different types of encoding because my question requires a SQL solution, not a PHP solution.
Context ► There's a museum with two databases with the same charset and collation (engine=INNODB charset=utf8 collate=utf8_unicode_ci) used by two different PHP systems. Each PHP system stores the same data in a different way, next image is an example :
There are tons of data already stored that way and both systems are working fine, so I can't change the PHP encoding or the databases'. One system handles the sales from the box office, the other handles the sales from the website.
The problem ► I need to compare the right column (tipo_boleto_tipo) to the left column (tipo) in order to get the value in another column of the left table (unseen in image), but I'm getting no results because the same values are stored different, for example, when I search for "Niños" it is not found because it was stored as "Niños" ("children" in spanish). I tried to do it via PHP by using utf8_encode and utf8_decode but it is unacceptably slow, so I think it's better to do it with SQL only. This data will be used for a unified report of sales (box office and internet) in variable periods of time and it has to compare hundreds of thousands of rows, that's why it is so slow with PHP.
The question ► Is there anything like utf8_encode or utf8_decode in MYSQL that allows me to match the equivalent values of both columns? Any other suggestion will be welcome.
Next is my current code (with no results) :
DATABASE TABLE COLUMN
▼ ▼ ▼
SELECT boleteria.tipos_boletos.genero ◄ DESIRED COLUMN.
FROM boleteria.tipos_boletos ◄ DATABASE WITH WEIRD CHARS.
INNER JOIN venta_en_linea.ventas_detalle ◄ DATABASE WITH PROPER CHARS.
ON venta_en_linea.ventas_detalle.tipo_boleto_tipo = boleteria.tipos_boletos.tipo
WHERE venta_en_linea.ventas_detalle.evento_id='1'
AND venta_en_linea.ventas_detalle.tipo_boleto_tipo = 'Niños'
The line ON venta_en_linea.ventas_detalle.tipo_boleto_tipo = boleteria.tipos_boletos.tipo is never gonna work because both values are different ("Niños" vs "Niños").
It appears the application which writes to the boleteria database is not storing correct UTF-8. The database column character set refers to how MySQL interprets strings, but your application can still write in other character sets.
I can't tell from your example exactly what the incorrect character set is, but assuming it's Latin-1 you can convert it to latin1 (to make it "correct"), then convert it back to "actual" utf8:
SELECT 1
FROM tipos_boletos, ventas_detalle
WHERE CONVERT(CAST(CONVERT(tipo USING latin1) AS binary) USING utf8)
= tipo_boleto_tipo COLLATE utf8_unicode_ci
I've seen this all too often in PHP applications that weren't written carefully from the start to use UTF-8 strings. If you find the performance too slow and you need to convert frequently, and you don't have an opportunity to update the application writing the data incorrectly, you can add a new column and trigger to the tipos_boletos table and convert on the fly as records are added or edited.
I create a table with different collation column that included:
utf8_persian_ci
cp1256
Why different collation? Because some of them address and correct charset for PHP that be able create Persian folder/files is windows-1256 therefore I thought I need to set charset cp1256 for saving path into mysql.
It shows ???? instead of farsi characters When I fetch rows from the table to show in PHP. My default charset sets to UTF8.
Now what is the problem that row store with ??? or php shows ??? instead persian keywords?
i hav a database that contains spanish characters. to populate the database i am getting the values from client page which has character encoding=UTF-8. when i insert the values in mySql database the rows contain altered data. for example if i insert 'México', the entry in the database is 'México'. the impact this has is when i do a query on the table specifying 'México', i get no results. my question is how do u insert spanish or other latin accent in mysql database? i hav tried all the collations, htmlentities() etc but nothing works!!
when making mysql query i checked what data is being sent and it is in its correct form 'México' but when i see the table entry through phpmyadmin, its altered!!
Change your mysql database/ table / column encoding to UTF-8 (and also set the collation to a compatible value).
ALTER TABLE mytable CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mytable
MODIFY country CHAR(50)
CHARACTER SET utf8 COLLATE utf8_general_ci;
Also specify the char set at the PHP side when connecting.
mysql_set_charset('utf8',$conn);
Take a look at this article for further info and a script to batch change every table / column in a database.
I just wasted 4 hours on the same problem as you.
Everything is in UTF-8
EG:
<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
The MySQL database is in UTF-8 PHP is in UTF-8
After four hours and on many occasions tearing my hair out I have found a solution that works.
$content = htmlentities($row[mystring], ENT_QUOTES, "ISO-8859-1");
$content = html_entity_decode($content);
It takes the accents converts them to html characters then converts them back into UTF-8
This is a great hack and it works perfectly.
For some inexplicable reason, the data in my MYSQL database is not in the UTF-8 format even though I have gone to extreme measures like exporting the data to a text file in phpmyadmin saving it as UTF-8 in a text editor and re-importing it. None of this worked.
Check two things first:
Are you inserting the data as UTF-8? If the data is coming from a web page, make sure the page's encoding is set to UTF-8 (encoding meta tag is set in the page header).
Are you sure the data is not saved as Unicode? This is the reverse situation: if phpMyAdmin uses something else other than UTF-8, you'd see the garbled characters when it displays the contents.
I'm re-designing a Web site and I have a problem with the existing data base:
The database collate is set to utf8_unicode_ci and in the table row I'm calling the collate seems to be set to latin1_swedish_ci the characters store in it are Japanese (but even in phpmyadmin) you see other characters (I guess because of the latin1_swedish_ci).
When I print the result from the query I get a bunch of ??? now using
mysql_query('SET NAMES utf8');
mysql_set_charset('utf8',$conn);
Will output 2009â€N10ŒŽÂ†2009?N10???2009â€N11ŒŽÂ†2009?N11???
Any ideas?
Because the table was set to use latin1_swedish_ci, it was unable to correctly store the UTF-8 data that was entered. You need to switch that table to use utf8_unicode_ci for data going forward, but any existing data is essentially corrupted. You would have to re-enter the data after switching the collate to get the correct Japanese characters for the existing records.
You need to change the charset to utf8. The collation do not need to be changed to display japanese characters (but to be able to sort and compare texts it might be a good idea to change it to utf8_general_ci).
Hi all thanks for your reply's this is what happened, I couldn't really change anything in the DB since there's another version of the site that still uses that DB and will be up. So the solution I found was the following:
Case scenario:
The DB is set to use UTF8 -> (utf8_general_ci) but the field (at least the one's I needed where set to latin1_swedish_ci.
Solution:
After mysql_connect I put the following:
mysql_query("SET NAMES 'Shift_JIS'",$conn);
mysql_set_charset('Shift_JIS',$conn);
Then in the PHP file:
$titleJP = $row['titleJP'];
$titleJP = mb_convert_encoding($titleJP, "UTF-8", mb_detect_encoding($titleJP,"Shift_JIS,JIS,SJIS,eucjp-win"));
Now that worked perfectly the characters are displayed in correct Japanese.
I tried every other solution I could think of with no luck (utf-8_decode/encode php functions, etc.. etc..)