Set Google Cloud SQL character-set-server - java

I'd like to use Google Cloud SQL for my app, but I require that utf8mb4 be set as the server character set in order to correctly process 4 byte utf8 characters (emoji).
It is not enough to simply set the table or database character set because the driver connection (mysql-connector-java) is negotiated based on the server character set.
Is it possible to set the server character set with Cloud SQL?
If not, is there another workaround that could allow me to force the driver connection to utf8mb4?
Here is a copy of my connection string: jdbc:mysql://<host>/<db_name>?useUnicode=true&characterEncoding=utf-8
Note that setting the characterEncoding variable in the driver connection string to utf-8mb4 or utf8mb4 is illegal. My best information say that it has to be set to utf-8 and then it will upgrade to utf8mb4 if the server is using that character set.

It looks like this feature has been added to the new instance menu on the console as of 5/29/2014. There is now a "character_set_server" flag that can be set to either utf8 or utf8mb4.
This does not allow setting the server character set to any arbitrary character set, but it does solve my problem and should suffice for most people.

Related

utf8_unicode_ci String is inserted incorrectly?

I have java application through which I do different operations on MySQL DB. The probleam is that when inserting utf8 String it is not inserted correctly. The charset of DB is utf8 and I have set collation to utf8_unicode_ci. Server connection collation is also utf8_unicode_ci. Furthermore when I insert data from phpMyAdmin it is inserted correctly, but when I do it from Java application using JOOQ - it is not. Example:
Result<ExecutorsRecord> executorsRecord =
context.insertInto(EXECUTORS, EXECUTORS.ID, EXECUTORS.NAME, EXECUTORS.SURNAME, EXECUTORS.REGION, EXECUTORS.PHONE, EXECUTORS.POINTS, EXECUTORS.E_TYPE)
.values(id, name, surname, region, phone, 0, type)
.returning(EXECUTORS.ID)
.fetch();
where name = "Бобр" and surname = "Добр", produces tuple with ???? as a name and ???? as surname. I have checked both strings, they are passed correctly to the method correctly.
As #spencer7593 suggested the problem could be in JDBC connector. So I added into url of connection following: ?characterEncoding=utf8 so that final url was "jdbc:mysql://localhost:3306/mydb?characterEncoding=utf8", where mydb is a name of database. This has sorted out my problem. Also I would like to add the following statement (again by #spencer7593):
When we've got things configured correctly, and things aren't working, our goto suspect is the JDBC driver. To get timezone differences between the JVM and the MySQL database sorted out, to prevent the JDBC driver from "helping" by doing an illogical combination of various operations, we had to add two extra obscurely documented settings to the connection string.
Further reading

Unicode messages in oracle raise_application_error

I am working on enabling globalization support in my DB.
I have done migrating character set to UTF (AL16UTF16).
After migration, I can pass Unicode characters from Java to Oracle and store in table's NVARCHAR2 column. Also I can retrieve from DB and pass to Java.
But, If I do a raise_application_error with the Unicode data. It sends the error message to java like below
; nested exception is java.sql.SQLException: ORA-20001: ¿¿¿ ¿¿¿¿¿¿¿¿¿
Can anyone tell me what's wrong? and how can I get the Unicode error messages in java?
Thanks in advance.
The problem is I have done character set migration using the below steps, but it doesn't work for me.
1.Backup the database.
2.Run CSSCAN command.
3.Restart the DB with RESTRICT mode.
4.Run CSALTER script.
5.Restart the DB.
After that I have tried using the below steps.
1.Take backup of the DB using expdp command.
2.Create a new database with required character set (Unicode AL32UTF8).
3.Import the backup dump file into the newly created DB.
That's all. It works!
Now I don't need to use NVARCHAR2 data type to store unicode data (VARCHAR2 itself stores Unicode). raise_application_error also works fine (sends error messages with Unicode data to Java).
Thanks.

Inserting spanish text in mysql

I do a HTTP GET call in Java to get content which may contain spanish characters, for example: Ñañez
But what I get as a response from Mysql - Ñañez
So far I searched online and did the below:
Appended utf-8 as encoding in connection String(Using Java)
jdbc:mysql://localhost:3306/dbname?useUnicode=true&characterEncoding=UTF-8
Updated the table's encoding
ALTER TABLE test CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
The problem is still there..
Anything I am missing??
Server is Tomcat 6
try altering table column
ALTER TABLE `test` CHANGE `columnname` `columnname` VARCHAR(200)
CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
you must run this query before your insert query in mysql:
SET NAMES 'utf8'
Mojibake is usually caused by
The bytes you have in the client are correctly encoded in utf8 (good).
You connected with SET NAMES latin1 (or set_charset('latin1') or ...), probably by default. (It should have been utf8.)
The column in the tables may or may not have been CHARACTER SET utf8, but it should have been that.
Include characterEncoding=utf-8 in the connection string.

UTF-8 Queries with JDBC

i want to ask the MYSQL an UTF-8 Query but it does not work fine . when i try the following query , the result comes up truly :
String query = "select * from Terms where Term = 'lol'";
but with the following query doesn't make a response :
String query = "select * from Terms where Term = 'خدابخش'";
where the
'خدابخش'
part is in Persian and UTF-8 .
note that the connection to the database is fine .
Chances are that you may need to set your character encoding in your JDBC connection. If you are using MySQL JDBC Connector you do it using the property characterEncoding. Somewhat like this:
jdbc:mysql://localhost/some_db?useUnicode=yes&characterEncoding=UTF-8
You may want to read the reference on encoding and character sets in your connector JDBC documentation.
This is the one that mentions the use of characterEncoding for the MySQL JDBC Connector:
Connector JDBC: Using Character Sets and Unicode
One or more of the following is true:
The Java compiler, compiling your code, is set to read the source file with a different encoding in which the source file was actually stored. In other words, there is a discrepancy between the encoding that your editor uses, the encoding in which the file is actually saved, and the encoding with which the Java compiler is reading your source code.
Your database isn't set correctly to accept/store Unicode characters. Ensure that your database is set correctly. Looks like you're using MySQL. You may want to create a dump of the database using mysqldump and witness how the database was created with respect to character sets.

Problem logging utf-8 strings in MySQL from Java

I am trying to log a string sent from client side to MySQL database from a Java application. The string sent from client is UTF-8 encoded. I have confirmed this as I have taken packet traces using tool like wireshark. The string that the client sends are 3 characters which are Latin OE (0xc593), and beta (0xc39f), Euro sign (0xE2 0x82 0xAC). I am using prepared statement way of setstring to log the string into database. The table is created with support for utf-8 char encoding. Now, when I see the logged string in database I find this
select hex(message) from table1
C385 C293 C383 C29F C3A2 C282 C2AC
Seems like something is changing the string in the middle. Could anyone help me to solve this problem?
Thanks.
According to the MySQL docs,
Client applications that need to
communicate with the server using
Unicode should set the client
character set accordingly; for
example, by issuing a SET NAMES 'utf8'
statement.
You should also check the character_set_client and character_set_connection system variables to get an idea of how MySQL is attempting to interpret your string.
You can check the collation that individual tables are using by running the SHOW TABLE STATUS IN database query, as well.
Hopefully that will give you a clearer picture of exactly what the MySQL server is trying to do with the strings you're sending from the client. Reading up in the docs should be enlightening, as well.
Good luck :-)

Categories