I'm aware that this question was already asked a couple of times, but I didn't get the problem solved even with the hints mentioned in other posts.
For a small webproject I created some html/jsp pages that are calling links to two servlets. The servlets themselves are talking to a PostgreSQL database. Everything is working instead of the encoding. When I'm typing in special characters (UTF-8) like "ü", "ä" or "ö", I can see them:
correctly inserted into the web page
correctly listed inside of the java objects (Debug mode) correctly inserted into the database
Since the web tool reloads the data with every change (a simultaneously work should be provided), I can also see the following steps working:
after the tool was re-loading the data from the database, the special characters are listed inside of the java objects (Debug mode)
the attribute inside of the request-object has the correct value
Nevertheless, after reload the data is not shown correctly anymore inside the web page - just cryptic signs.
Can you please support? I already checked the following points:
encoding of Eclipse
encoding of database
encoding of servlets
encoding of the application server (Wildfly)
encoding of the JSP files
encoding inside of Chrome
Best greetings,
Jesfreric
Related
I have a Java Servlet running on a Tomcat Server with a MySQL database connection using JDBC.
If I have following piece of code works in, the hard-coded-HTML code works, but everything that comes from the database is displayed incorrectly.
response.setContentType("text/html;charset=UTF-8")
If I remove the line the text from the database gets displayed correct, but not the basic HTML.
In the database, and Eclipse everything is set to UTF-8.
On first sight it looks as if you were converting the text from the database again, once too much.
So the first check is the database. For instance the length of "löl" should be 3. Whether the data stored is correctly, read correctly. As #StanislavL mentioned, not only the database needs the proper encoding, in MySQL also the java driver that communicates needs to be told the encoding with ?useUnicode=yes&characterEncoding=UTF-8.
Maybe write or debug a small piece of code reading the database.
If stored correctly the culprit might be String.getBytes() or new String(bytes).
In the browser inspect the encoding or save the pages.
With a programmer's editor like NotePadd++ or JEdit inspect the HTML. These tools allow reloading with a different encoding, to see what the encodings are.
It should be that the first page is in UTF-8 and the second in Windows-1252 or something else.
Ensure that the HTML source text is correct: you might use "\u00FC" for ü in a JSP.
Project is based on
Postgres database version 9.3.5,
Java 7, org.hibernate hibernate-core 3.6.10.Final
Problem :
I have two separate system running the same web application. One on of the systems everything is persisted correctly on the other Strings sent to Postgres database contain unicode characters and text like 'nnés' is persisted as 'nns' or 'nnés-2' . The only difference I noticed between those two systems Is one displaying UNICODE and the otherUTF8 as client encoding when doing SHOW client_encoding; in the console. The one running unicode works correctly the other does not.
My question is
Is it possible that client encoding got stuck/hardcoded somehow and it is not being selected based on real client encoding which would mean the strings sent in unicode arent converted to UTF8 but just persisted.
What can be the reasons for such a behavior.
try request.setCharacterEncoding("UTF-8");
I have an application running on Jelastic. The Java based web application is running on Glassfish and the database server is MySql.
I developed the project on Netbeans and there was no character problem when running the project on the local machine (Turkish Windows 8).
When running on Jelastic, there is no character problem related to the web pages. However, there is problem when form based interactions are called.
Some Turkish characters are not processed when a search query or customer registration tasks are executed. Those characters missing (recorded to the MySql as ?)are the ones differing from the Latin. For example "ö", which is also used in German is not the problem.
Problematic characters: http://en.wikipedia.org/wiki/Wikipedia:Turkish_characters
As I said previously, I dont have such problem when working on local Glassfish rolled in Netbeans.
I checked out the phpMyAdmin server, and I think that some values (that are set by default such as latin1_swedish_ci) might be the cause for loss of Turkish characters.
I tried to change the values on , but those are reset to the defaults when the server is restarted. Could this be the source of my problem? If so, how could I set them permentantly?
Your kind support will be greatly appreciated.☺
where exactly you are applied changes?
As I know these settings can be changed at etc/my.cnf via Jelastic Dashboard in MySQL.
Concerning Character Setting you will help this link:
Change MySQL default character set to UTF-8 in my.cnf?
If the problem persists ask your hosting provider for help with this issue.
I am building a web application using JSF and Spring in eclipse indigo using Glassfish server 3.1.2 . Everything is going great but it is showing me this error in firebug in 2 JavaScript files.
When I check in those files I didn't find any illegal character in those files but firebug still showing this.
I have used these files in one of ASP.Net project and they didn't mess there so i checked and matched their content type from both projects then I found that in ASP.Net project these files have
Content-Type = application/x-javascript
And in my JSP-Spring(JAVA) project there
Content-Type = text/javascript;charset=ISO-8859-1
is this.So you can see that sames files have changed their content scheme. I found that this scheme can be change by configuration in glassfish server.So I want to change my JS files content-Type to same as in ASP type.
If anyone have any other solution then please share because I haven't found any solution other than changing the scheme from glassfish serverThanks
Those strange characters you are seeing is the UTF-8 Byte Order Mark. They are a special set of bytes that indicate how a document is encoded. Unfortunately, when interpreted as ISO-8859-1, you wind up with the problem you have. There are two ways to resolve this.
The first way is to change the output character set to UTF-8. I believe this can be done in your server configuration, in your web.xml configuration, or by setting the character set on the HTTP request object in code; for example: yourServletRequest.setCharacterEncoding("UTF-8");
The second way is to remove the BOM from your Javascript files. You can do this by opening them in Notepad++, going to Encoding > Convert to ANSI, and then saving them. Alternatively, open them in Notepad, then go to Save As and ensure that the Encoding option is set to ANSI before saving them. Note that this may cause issues if you have non-ISO-8859-1 text in your Javascript files, although this is unlikely.
I'm running into an encoding issue that has stumped me for a few weeks and nothing seems to work. I have a website that works fine on my local machine, but when I push the jsp files to a Linux box for review, characters that previously rendered fine are now displaying as funky characters.
For some reason, some characters display just fine, but other characters will not encode properly. All text on the page is being read from java .properties files and output to the page using beans.
I've added a meta tag to the page to set encoding, which did nothing. I also added <%# page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> but this did nothing on the linux box and actually made the encoding errors appear on my local windows machine.
Any help would be greatly appreciated.
Check that the method loading the properties is using the character encoding that the property files are actually written in.
Without explicit setting this, the default encoding for the file system is used, and it is ISO-Latin-1 on Windows, and UTF-8 on some Linux distributions.
The following need to play together for character encoding to work properly in Nixes and Nuxes:
file system encoding
database encoding (does not seem to apply)
database connector encoding
Java-internal string encoding (UTF-16, if I remember correctly)
Java output encoding
HTML page encoding
With your page directive, you only addressed the last bullet. In other words, you are instructing the brower to decode the page as UTF-8, but that's not what you are sending.
Take a look at this (admittedly a few years old) paper, chapter 11 in particular.
Also, check the physical files on both machines. I've seen several FTP clients muck up files during transfer. A quick check is to push your file as html instead of jsp. You'll get garbage for all the <% %> sequences, but the other text should show up unchanged. You've also taken the app server out of the equation. If the text is still funky, it's your FTP or WebDAV client trying to "help".
Look at the http headers sent by the server. That is the first place the browser looks for encoding before anything else.