Whenever I try to add any japanese characters to the mysql database through jdbc, the characters are converted to question marks. I want to add those actual japanese characters. How can I do so?
There are similar questions on stackoverflow but none addresses the same issue as this.
PS. The mysql database is an AWS RDS database.
This has more to do with the encoding of your database than your actual SQL client. Your database should be configured to use an encoding that will allow Japanese characters. UTF-8 is recommended.
Specifying the encoding of your database is usually done during DB set-up time, not with your (Java) code. As you mentioned that you are using Amazon RDS I'm not sure what specific steps you should take. However, I usually do this per table on my MySQL set-ups. See here for the particular MySQL documentation.
Additionally, it may be that the Japanese characters are getting inserted fine but your viewing client (terminal, browser, etc.) is not configured to the proper encoding.
Related
I am able to enter supplementary chars in textbox but it doesn't get save in database. I am using MySql database. I have used spring and hibernate in my application. What change should I make to enable supplementary chars support in my application?
Following is my database connection string:
url="jdbc:mysql://localhost:3306/users?useUnicode=true&characterEncoding=utf8"
You need to do following changes to make your application supplementary character compatible:
Remove characterEncoding i.e. utf8 from your url and make it as below:
url="jdbc:mysql://localhost:3306/users?useUnicode=true"
You need to edit my.ini file from MySQL Server directory. If you have Windows 64bit OS, then you may find it at following location:
C:\ProgramData\MySQL\MySQL Server 5.6\my.ini
Open this file using any text editor such as Notepad++ and change the following parameter value:
From
character-set-server=utf8
To
character-set-server=utf8mb4
After making the above changes your application should support Supplementary characters.
I am building an app and I can't seem to handle the data that contain diacritics or other type of UTF-8 characters. In my case I'm in need of this chars: ă-Ă-â-Â-î-Î-ş-Ş-ţ-Ţ.
Now, first, there is a input on the front-end that gathers some info from the users, sends it via AngularJS http module to the API. The headers are all good, the data goes to the API all good. Then, on the server side, if I log the info, it outputs: ?-?-â-Â-î-Î-?-?-?-?, and of course, the same info is put in the db (checked with phpmyadmin).
The weird thing is, as my app pulls the data from the db to print it to my app, all goes well, it prints as it should be ă-Ă-â-Â-î-Î-ş-Ş-ţ-Ţ, until I restart the server, after which it prints as it is shown in the db.
I want to point out that it isn't the cache, I'm testing the app in cache-free environment. I even tried to access from different end-points just to be sure it is not from some local issue.
Anyone has any ideas ?
I solved it myself: the problem was from JPA persistence level from Java. It didn't interpret the UTF-8 right because I was giving it inside the url. Actually what I needed to do was to create a parameter in glassfish jdbc.
I designed a java desktop application using jdbc technology to connect to mysql database.
But when I want to store a data in my db which is in persian language it saved like some ????
I tried creating the database with both
CREATE DATABASE 'db' CHARACTER SET 'utf8';
and
CREATE TABLE `Table1` (
[...]) DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
I tried every other COLLATEs but they seem not working properly.
What should I do?
Make sure the driver properties are set. Check that useUnicode is true, characterEncoding is "UTF-8". I assume you are using the Connector/J JDBC driver.
Refer to this answer.
A brief version of what the answer says is that you should add
?useUnicode=true&characterEncoding=UTF-8
To the end of JDBC connection URL.
For example:
jdbc:mysql://localhost:3306/db_name?useUnicode=yes&characterEncoding=UTF-8
Say I have created a desktop application in Java to keep notes. I used MySQL for storage. On my computer it connects to database I have created(using my root username and password). But what if I want to distribute my program? Are the other users should have MySQL installed on their system? If they have to isnt tat a problem that I have my MySQL username and password embedded in code?
In general, I am asking how can I make a desktop program in Java which can store data from its users??
Sounds like you want SQLite, There is another SO question here about it.
SQLite as IanNorton mentioned is a good alternative. Other good alternatives are Apache Derby or the H2 database, both providing an embedded (install-free) java database.
Does MySQL have its own embedded version?
Normal "embedded MySQL" is a native code library (libmysqld) that is not really suitable for use with Java. However, there is something called mysql-je that purports to be a Java compatible wrapper. The problem is that it is based on a rather old version of MySQL, and hasn't been updated since 2006.
There are also postings on the MySQL forums about using embedded MySQL with Java, but there's no sign that it is supported.
So I think you'd be better of going with a one of the alternatives; e.g. SQLite, Derby or H2.
No need of multiple installations of MYSQL database if all the machines where you want to access are in a LAN. In that case you can have single database installation and access it from multiple systems using the IP address of the database machine. We can access a remote database through Internet as well, using the IP Address of the machine in which database exists..
I am developing an application connecting to a database in Java. The customer has SQL Server and I tried the SQLExpress version von Microsoft as long as we don't want to buy a licence for the developement time. Sadly, the SQL Server Express does not allow network access so we can't work over network on the same database and have to install the SQL Server Express server on every developer client.
Today morning I decided to switch to MySQL during the developement process. I created a MySQL database with UTF8 charset and exported the data into CSV files which I also converted to UTF8 and imported them.
I connect with Java with the JDBC driver and now got weird behavior during execution. The results completetly differ from the client connecting to SQL Server. I have written the SQL to Java glue code myselft and am not using a framework like Hibernate or JPA.
I guess that the problem has to do with character encoding. The source code files are - dont't hit me - encoded with CP1252, because I just started developing in Eclipse on Windows and trusted the default settings. I query the database getting a ResultSet object and then read out the data with the getter methods provided by the ResultSet. I don't do any character conversion during the data fetching.
The problem is now that I don't get cryptic not well encoded output but instead NullPointerExceptions and weird data handling. For example: I have written a method which compares Jobs (an object representing a Job with a name, id, cargo and all that stuff). The results during the runtime differ. Some Jobs are equal on SQL Server and some on MySQL but the SQL Server result is the correct one.
I just viewed the database properties and saw that the character encoding of the SQL Server is in ISO-Latin-1.
Thanks for your help and regards from Cologne,
Marco
I know little about MS SQL, but if the MS SQL data is latin1 encoded, importing it into a UTF-8 database on the mySQL end must fail and result in broken data.
I would try to get the data fixed first. Can you retry the process without converting the dump file, and a latin1 database in mySQL?
Plus, there seem to be notable differences in data types between mySQL and MS SQL:
Be careful when planning this: you want to match data types by capacity and not necessarily by name. For example: a MySQL VARCHAR can hold up to 255 characters, whereas a SQL Server VARCHAR can hold up to 4000 characters. In this case you would need to use a MySQL TEXT column type instead of VARCHAR.