I am currently working on a site that connects a DB and bring the information, some of this information has special characteres because is in polish languague, for example, in the database I have this one ę and I get e printed at my web,I already added the meta
<meta charset="ISO-8859-2">
but doesnt work, only if I write & #281; which is not pract and needs a lot of work, my question is if somebody did this , get the character, like ę, and print it just like that?
Thanks.
Make sure that:
the data really is in ISO-8859-2
the data isn't be corrupted by the configuration of the database
the HTTP headers aren't claiming the data is encoded a different way
whatever you are using to pull the data out of the database isn't transcoding it
You should also ditch ISO-8859-2 (as it is very legacy) and move to UTF-8.
Use a Unicode entity. &#xxxx; where xxxx is the Unicode value for the character.
Related
I've got web-app (jsp) which is using database (mysql). I've put some data into database to test is it work to show in jsp what's in database There was issue with utf-8 characters (polish letters) but i fixed it by adding <parameter-encoding default-charset="UTF-8" /> into glasfish-web.xml. But i still got problem with putting data into database from form. In database instead of polish character i got "?????". I've tried many thinks and nothing Dont reallu now where to look to fixit
ok problem solved I'll put answer for other people having same problem
In jsp where i start my database connection for url="jdbc:mysql://localhost/databasename i changed it into
url="jdbc:mysql://localhost/databasename?useUnicode=true&characterEncoding=UTF-8"
and now everything in database looks like it shoudl
Problem you have faced is that java has escaped the UTF-8 character sequence.
you can use StringEscapeUtils provided by java in order to escape any characters which become ??? or anything else.
try this :
str = org.apache.commons.lang.StringEscapeUtils.unescapeJava(str);
From java
Because my database is about postage stamps there are a lot of half symbols in the descriptions. They type into mysql with no problem but when I get the results of a query all the half symbols have been replaced by a question mark.
Is there a special code I should be using when I input the descriptions instead of using the half symbol? Otherwise, is there another solution like changing the character set. I'm using utf-8 at the moment.
It seems like you are facing character encoding issue. You should use UTF-8 everywhere:
Make sure the column that contains text data is encoded as utf8_...
Check that when you get information from database, you keep this encoding. You can force it by sending SET NAMES utf8; before any request to MySQL.
Check that when you display this information the encoding is UTF-8 (in a webpage, that means <meta charset='utf-8'> in <head>).
I have Thai characters in MySQL but they don't transfer to my ASP generated web page correctly. I've linked to screen shots of the crucial factors showing the data is OK in the table but not on the website as seen in the last screen shot. Any thoughts what I'm doing wrong?
http://www.transum.com/Temp/ThaiScript.PNG
The first two pictures are from phpMyAdmin
The third picture is the header of my webpage.
The fourth picture shows what appears on the webpage.
I have already added the UTF-8 instruction to the connection:
Conn.execute ("SET NAMES utf8")
SQL = "select * from Phrases WHERE Checked = TRUE Order by English ASC"
set RSrecord = Conn.execute (SQL)
Response.CharSet = "utf-8"
Without seeing more of your source, my first question (or suggestion) is whether you are HTML encoding your output?
Response.Write Server.HTMLEncode(RSrecord.Fields("Thai_Script"))
If this doesn't work for you, can you show a bit more code?
I think I've worked this one out. First of all I should repeat that if you can possibly install MyODBC v5.1 then do so and don't bother trying to configure for 3.51. Unfortunately it would appear that the older driver is all that a certain large and well known web host seems to offer.
Here's a link to a version of my Russian Cyrillic page. It uses the old driver, (MyODBC 3.51)
http://clubdanceholidays.co.uk/aboutusruansi.asp
The crucial points to note are:
1) In the first line:
<%# LANGUAGE="VBSCRIPT" CODEPAGE="1252" LCID="2057" %>
Use 1252 rather than 65001 as your codepage value - I realise just how counterintuitive this is, but in this specific situation it works.
2) Your line
Conn.execute ("SET NAMES utf8")
Adding this query immediately before the query to populate my recordset was the missing piece of the jigsaw for me.
3) The Charset meta tag
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
This should definitely be UTF-8. Essentially we're telling the server that it's a Windows-1252 page and the browser that it's a UTF-8 page.
4) What kind of encoding to use when you save the file
This is a little more complicated. If you're using Notepad then you need to use ANSI. The UTF-8 option is actually UTF-8 + BOM, which seems to create a conflict with the codepage definition in point 1. The problem with ANSI comes if you need to hardcode any non-western characters into your page - you couldn't insert them as they are, you would need to manually encode them first, eg for เครื่องบิน you would need to insert เครื่à¸à¸‡à¸šà¸´à¸™
If you have a more powerful editor than Notepad, (I use Editplus - http://www.editplus.com/ - it's not free but it's quite cheap) you may find two UTF-8 options. Choose the one without BOM.
I am currently having an issue saving special characters (® & ©) to a mySQL database.
On a local stack (local to my development machine) the operation runs smoothly and what is entered in the front-end gets saved as what is expected.
With the same front-end code on the centralised server when saving to the DB the character is proceeded with other characters it is saved as ®.
This isn't an issue when viewing the record on the front-end as it reverses what it does and displays correctly.
The issue comes from another separate system which utilises the same database and doesn't do any alteration so appears as the ® instead of simply ®.
The reason for my confusion is that it seems to work as required on my local stack but not on the centralised server.
I am looking for ideas as to what to look for which might be causing this on the servers configuration compared to my local.
Thanks in advance
Mark
#Pranav Hosangadi (thanks) covers three areas to check for consistency of encoding. The following solution adds to that. It may also be worth considering (a variation of) #Soaice Mircea's answer (thanks also) for some scenarios whereby this answer doesn't fix the problem although this wasn't required when I was able to reproduce and find a solution to your problem. #Pranav's line of thinking seems to be successful for this problem as it's about consistency of using one character set everywhere rather than a particular one.
five things to do:
ensure database charset and tables use same charset throughout, inspect this in phpmyadmin for example, note and this charset for use below
use php header() function with database charset e.g.:
header('Content-Type: text/html; charset=latin1_swedish_ci');
insert meta tag in html header e.g.:
<meta http-equiv="content-type"
content="text/html;charset=latin1_swedish_ci">
add charset-accept in form tag
<form action=\"testsubmit.php\" method=\"post\" accept-charset=\"latin1_swedish_ci\">
set charset of mysql connection e.g.:
$con = mysql_connect("localhost","test","test");
mysql_set_charset ( "latin1_swedish_ci", $con );
after you select the DB in php code add this:
mysql_query("set names 'utf8'");
also check if the column where you store the text has utf8 encoding.
I'm working on a site that has users from other countries. For the most part we get English text but sometimes people use special characters like Chinese symbols or the E with the accent. These symbols are displaying as "?" when shown on the site.
The site has a UTF-8 charset declaration and the SQL Server database field is Nvarchar. I did a test by going to Google translate and having it translate "Good morning" into Japanese. When I copied the resulting Kanji to my site and saved it myself it worked fine.
What could be causing this issue? I'm guessing it's because the text is being entered in a charset that is not UTF-8. Will accept-charset="UTF-8" resolve the issue? If not what can I do? Even if there is no way to fix existing bad data can I prevent this issue in the future?
SQL Server 7.0 and SQL Server 2000 use
a different Unicode encoding (UCS-2)
and do not recognize UTF-8 as valid
character data.
See the following knowledge base article for dealign with storing/retreieving utf-8 data in a MS SQL Server database: http://support.microsoft.com/kb/232580