Tag Info

Hot answers tagged

2

The chinese characters are decoded correctly with utl_i18n.unescape_reference. In fact they just aren't displayed properly in your query result which might not support those special characters. You can confirm that with this SQL Fiddle. It is the client which is respsonsible to display the characters appropriately. If the client can not display a ...


1

since you confirmed the character set in the database is AL32UTF8, you need to make sure the fonts is installed on the Linux machine, and install the message libraries. that will make ORA_NLS33 has been set appear when you execute alter session set nls_language=


1

If it is the "world" database downloaded from here, it is in latin1 encoding. Use that for importing. UTF-8 (utf8 or utf8mb4 in MySQL) has become the de facto standard nowadays for operating systems and global comunications (except in some countries and specific areas of knowledge), and utf8 is now the default encoding in MySQL (since 5.5). latin1 was the 1 ...


1

I had the same problem with an Ubuntu installation of MySQL 5.6.23. I had to edit /etc/mysql/my.conf and add these entries to these sections: [client] default-character-set=utf8mb4 [mysqld] character-set-server = utf8mb4 [mysql] default-character-set=utf8mb4 Then as root execute: service mysql restart Both my webserver connections and my local ...


1

MySQL has no way to split a cell into a bunch of values. (Yeah, it can split a piece of a cell off -- see LEFT(), etc. But not an arbitrary set.) You would be better off doing the task in PHP or some other language -- more powerful than SQL. (Yeah, it could be done in a Stored Procedure, the the code would be really messy.) Here is some pseudo code for ...


1

I assume you will do this for each table? ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4; One potential issue involves the maximum of 767 bytes per column in an INDEX. If you currently have a VARHAR(255) latin1 field in an index, you will need to rethink it. Decrease it to VARCHAR(191) if you are sure that 191 will suffice (into the future) Use a ...


1

I made some attempts to dig into this issue, here are the results. When you set a connection charset (i.e. SET NAMES utf8) MySQL transparently handle encoding conversion for you. For instance if I insert a à (\xE0 in latin1 \xC3A0 in utf8) in a latin1 table using a UTF8 connection it reads the UTF 8 value and store it in table as \xE0 mysql> SELECT ...


1

Thanks for the minimal test case. Your TEXT column is declared to be latin1; there is no "dotless i", in latin1, so it was converted from utf8's hex C4B1 to ? during INSERT. Change the table declaration, preferably to utf8. Also remove SET CHARACTER SET utf8; -- It seems to hurt! If you wish to complain about the "silent" conversion, file a bug with ...


1

I had this error, and now I have discovered the source of the problem. I had a hard time finding out, so maybe this will be useful to someone, even though I realize, my problem and workaround may not be spot on matching op's original trouble. I am migrating data from MSSQL to MySQL, and the content being migrated is html-content from Sitecore CMS (target ...


1

This shows the collation and character set for one table: SELECT column_name, character_set_name, collation_name FROM information_schema.columns WHERE table_name = 'your_table_name'


1

At MySQLBugs they suggested trying with binaries available at MySQL Community Downloads . Downloaded: mysql-5.5.8-freebsd8.0-x86_64.tar.gz Extracted to: /usr/local/mysql-5.5.8-freebsd8.0-x86_64 Linked to /usr/local/mysql And re-compiled/re-installed p5-DBD-mysql against it by doing the following: export PATH=/usr/local/mysql:$PATH cd ...



Only top voted, non community-wiki answers of a minimum length are eligible