hope you are all doing well.
So to the question, we have an asp website, (asp classic 2.0) with MSSQL server 2008, IIS7 in "a" server. We moved the whole website to another server that has exact environment, but we have a problem.
The data inside the DB is properly in chinese character. But when I want to display the data onto the website, it shows weird characters.
As for my code, I have put
response.charset = "gb2312"
and at the very top after html tag
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
But still it shows weird characters.
On its former server, it served well.
The only part that is not displaying correctly is the data from the DB. While the hand coded characters display correctly.
Is there anything I need to add/set?
Thanks
You'll need to find the codepage value for your character set. Eg, if you were using utf-8 you would begin your pages with
<%#language="VBScript" codepage="65001"%>
If you can, you're better off using utf-8 than a language specific set, but if your database is full of gb2312 encoded copy then I can understand why you wouldn't want to change it.
This blog post contains a lot of useful info
http://www.hanselman.com/blog/InternationalizationAndClassicASP.aspx
Related
I put opengraph tags on MediaWiki. I checked with the developer tool, and it seems that it went in without any problems. However, when I shared documents, I found that the Unicode string appears as follows:
The same problem occurs in Wikipedia in my native language. There is a problem only with the title. Maybe it's because the url address contains the same Unicode string. Do you know how to solve this problem?
I am making a multilingual website and storing data into database. The problem I am facing is, some of the character in some languages other then English are not being inserted into data base. For example if I enter "cliënten" [Dutch language] into form text area or input box, when I submit this. it only insert "cli" but nothing after this character ë the problem is clear. it seems a special charterer.
Now can anybody tell me how to insert characters like this into database from all other languages?
Thanks in advance to all you experts out there.
:-)
You could start by checking the character set and the collation of the database. If you are using phpMyAdmin, open the database and you will probably see a column titled 'collation' for each of the tables. Ideally I think you will want utf8.
More info: http://dev.mysql.com/doc/refman/5.6/en/charset-database.html
If the database looks good, then if you are loading details via a web page, check that you have specified the charset there as well with something like this in the page head:
<meta charset="UTF-8">
I have a problem with a WordPress site (it's in Swedish). For some reason I can't use all characters when I'm writing posts - the characters å, ä and ö become Ã¥ ä ö. The site is a webshop and I have the Woocommerce plugin installed. The same problem with åäö occurs in the long product descriptions of Woocommerce.
Anyone know what I can do to solve this? The character encoding in WordPress admin panel is set to UTF-8 and so is the database charset in wp-config.
In the database in phpmyadmin the collation of the wp-posts tables are set to "utf8_general_ci". Is that the problem?
This thing has never happened to me before, even though I have built a lot of WP sites in the past. Therefore I don't know what to do. Maybe the solution is simple but I want to know what I'm doing before doing anything so I don't risk messing up the site.
Would really appreciate some help with this, thanks.
When "national special characters", ie. non-ASCII characters, are displayed wrong, you probably have an error related to charset. The easiest way to fix this is usually to make sure that you are using UTF-8 everywhere.
(For Swedish in particular, you can use ISO-8859-1 (worst), ISO-8859-15 (better) or UTF-8 (best).)
You need to use the same charset everywhere, from the database to the HTML declaration.
In your theme's header.php file, please make sure that the declared charset is
UTF-8.
In your text editor or on your server, please make sure your theme files are being saved as UTF-8.
In MySQL, please make sure that the table schema is set to use utf-8.
In MySQL, please make sure that connections default to use UTf-8: mysql --default-character-set=utf8
In PHP, try setting the connection to utf-8 with mysqli_set_charset
In order to fix the Character Encoding Mismatch Problem in WordPress,
Open the ‘wp-config.php’ file in a text editor(the wp-config.php file can be found on the directory where you installed WordPress).
Find the following two lines and comment them out:
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ”);
They should look like the following after you comment them out:
//define(‘DB_CHARSET’, ‘utf8′);
//define(‘DB_COLLATE’, ”);
Now upload the updated ‘wp-config.php’ file to your webhost.
This character encoding problem can happen after a database upgrade too so it doesn’t hurt to keep this trick in your mind just in case.
In another case, if you are using PHP Dom (loadHTML) somewhere, there is a need to load HTML as UTF-8. I have fixed it by:
Replacing
#$dom->loadHTML($html);
to
#$dom->loadHTML('<?xml encoding="UTF-8">' . $html);
I'm trying to work out how to use SQL server management studio properly with multi-byte unicode characters. even something as simple as:
select N'动漫'
just returns square boxes in the result pane. I know the underlying database is set up correctly to handle unicode and other apps on the PC work fine with chinese characters
any clues very much appreciated
Changing the font to Arial Unicode MS did the trick for me.
I don't understand why Text Results displays fine with Fonts where Grid Results does NOT, and why other Unicode Fonts don't work but oh well.
After many frustrating hours with this problem, I just discovered a solution (if not an explanation).
Changing the Query Results font had no effect on my system (Win 7 Enterprise, 64-bit).
After much Googling I discovered this: My Chinese Word Suddenly Appear As Square Box
In short: create a new Windows user account, then log in as that user - you should find that your Chinese characters display correctly. Now log in to your original account, and you should find this also now displays Chinese characters correctly.
So creating the new account has the effect of fixing the behaviour for both (possibly all?) accounts. Now - anyone have an explanation?
I have a form that accepts text and is posted to the server.
If a user were to input a French character such as 'à', it will be read as 'Ã' by Classic ASP code and be stored as 'Ã' in a SQL Server 2005 database.
A similar affect happens to other accented characters. What's happening?
It's a problem of character encoding. Apparently your server and database are configured with charsets Windows-1252 or ISO-8859-1, and you're receiving UTF-8 data.
You should check that your server sends a Content-Type or a Content-Encoding header with values ending with "charset=iso-8859-1".
I guess your server doesn't send the charset of the documents, and people with default configuration set to UTF-8 send UTF-8 characters which are stored as iso-8859-1 (or Windows-1252) in your database.
See my answer here for the detail on what is likely happening.
Utlimately you need to ensure the encoding used in the form post matches the Response.CodePage of the receiving page. You can configure the actual character set sent by a form by placing the accept-charset attribute on the form element. The default accept-charset is the documents char-set.
What exactly do you have the ASP files codepages set to (both on the page containing the form and the page receiving the post)?
What are you setting the Response.CharSet value to in the form page?
I have just gone around in circles trying to fix this once and for all in my old classic asp app which uses jquery ajax posts to store info in a database. Tried every combination with no luck..
Ended up modifying any sql selects by using the stored proc mentioned here and magic happened. Data is still stored corrupted in the database, but is displayed correctly on the site.