HTML character encoding...
Dear List,
We are a german company. We have develped a web-based, database entry tool.
We in Europe use the � (Here us the Euro symbol!!) symbol. This is not included in the standard iso-8859-1 encoding.
We should use the iso-8859-15, which does support this symbol.
What would a US browser client normally deal with a html page, from our German web-server
where the page is encoded in iso-8859-15?
regards,
Ben
The UTF-8? If it's mostly Latin chars, then no, not at all. If it's a lot of higher value Asian language characters which need 3 bytes for UTF-8 to write out, then it would be cheaper to use UTF-16 or a more natural encoding like Big-5 or whichever, actually, as that's only 2 bytes.... But that's 2 bytes per char no matter whether it needs it or not. But most browsers, as far as I'm aware, do not support UTF-16.
Similar Messages
-
HTML character encoding in Tooltip????
Hi,
I am displaying text in a tooltip as HTML. The problem is that if I use funny characters such as the greater than and less than brackets, I get funny results.
Is there an easy way - something like a URLEncoder which will convert all my chars into HTML representations???
cheers,
OliverAll you need to do is format the field in CR to use HTML Text Interpretation. However note that CR does not support all HTML tags. For details see the following KBAs:
1217084 - What are the supported HTML tags and attributes for the HTML Text Interpretation in Crystal Reports?
1272676 - Not all the standard HTML tags are interpreted in Crystal Reports when using HTML Text Interpretation
- Ludek
Senior Support Engineer AGS Product Support, Global Support Center Canada
Follow us on Twitter -
Character Encoding in Crystal Reports
Hi,
We are using HTML character encoding to prevent SQL injection, i.e. when a special character like apostrophe (') is entered, it is saved as '. I wanted to know if we could manipulate the data in between the two operations of fetching the data from the DB and displaying the data using Crystal?
We could use formulae/functions in the design/query, but I am looking for a more generic solution using Crystal API. I have attached a screenshot of how Mc'Donald is displayed in the Report.
Thanks for the help!
NoopurAll you need to do is format the field in CR to use HTML Text Interpretation. However note that CR does not support all HTML tags. For details see the following KBAs:
1217084 - What are the supported HTML tags and attributes for the HTML Text Interpretation in Crystal Reports?
1272676 - Not all the standard HTML tags are interpreted in Crystal Reports when using HTML Text Interpretation
- Ludek
Senior Support Engineer AGS Product Support, Global Support Center Canada
Follow us on Twitter -
Character Encoding for JSPs and HTML forms
After having read loads of postings on character encoding problems I'm still puzzled about the following problem:
I have an instance (A) of WL 8.1 SP3 on a WinXP machine and another instance (B) of WL 8.1 without any SP on a Win2K machine. The underlying Windows locale is english(US) in both cases.
The same application deployed as a war file to these instances does not behave in the same way when it comes to displaying non-Latin1-characters like the Euro symbol: Whereas (A) shows and accepts these characters as request-parameters, (B) does not.
Since the war file is the same (weblogic.xml, jsps and everything), the reason for this must either be the service-pack-level or some other configuration setting I overlooked.
Any hints are appreciated!Try this:
Prefrences -> Content -> Fonts & Color -> Advanced
At the bottom, choose your Encoding. -
What every developer should know about character encoding
This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts.
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
Here's a key point about these text files – every program is still using an encoding. It may not be setting it in code, but by definition an encoding is being used.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
Wrapping it up
I think there are two key items to keep in mind here. First, make sure you are taking the encoding in to account on text files. Second, this is actually all very easy and straightforward. People rarely screw up how to use an encoding, it's when they ignore the issue that they get in to trouble.
Edited by: Darryl Burke -- link removedDavidThi808 wrote:
This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts. Pretty sure most Americans do not use character sets that only have a range of 0-127. I don't think I have every used a desktop OS that did. I might have used some big iron boxes before that but at that time I wasn't even aware that character sets existed.
They might only use that range but that is a different issue, especially since that range is exactly the same as the UTF8 character set anyways.
>
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
The above is only true for small volume sets. If I am targeting a processing rate of 2000 txns/sec with a requirement to hold data active for seven years then a column with a size of 8 bytes is significantly different than one with 16 bytes.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
The above is out of place. It would be best to address this as part of Point 1.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
The first part of that paragraph is odd. The first 128 characters of unicode, all unicode, is based on ASCII. The representational format of UTF8 is required to implement unicode, thus it must represent those characters. It uses the idiom supported by variable width encodings to do that.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Not sure what you are saying here. If a file is supposed to be in one encoding and you insert invalid characters into it then it invalid. End of story. It has nothing to do with html/xml.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
The browser still needs to support the encoding.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
I know java files have a default encoding - the specification defines it. And I am certain C# does as well.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
It is important to define it. Whether you set it is another matter.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Unicode character escapes are replaced prior to actual code compilation. Thus it is possible to create strings in java with escaped unicode characters which will fail to compile.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
No. A developer should understand the problem domain represented by the requirements and the business and create solutions that appropriate to that. Thus there is absolutely no point for someone that is creating an inventory system for a stand alone store to craft a solution that supports multiple languages.
And another example is with high volume systems moving/storing bytes is relevant. As such one must carefully consider each text element as to whether it is customer consumable or internally consumable. Saving bytes in such cases will impact the total load of the system. In such systems incremental savings impact operating costs and marketing advantage with speed. -
How can I tell what character encoding is sent from the browser?
Hi,
I am developing a servlet which supposed to be used to send and receive message
in multiple character set. However, I read from the previous postings that each
Weblogic Server can only support one input character encoding. Is that true?
And do you have any suggestions on how I can do what I want. For example, I
have a HTML form for people to post any comments (they may post in any characterset,
like ShiftJIS, Big5, Gb, etc). I need to know what character encoding they are
using before I can read that correctly in the servlet and save in the database.From what I understand (I haven't used it yet) 6.1 supports the 2.3
servlet spec. That should have a method to set the encoding.
Otherwise, I don't think you can support multiple encodings in one
instance of WebLogic.
From what I know browsers don't give any indication at all about what
encoding they're using. I've read some chatter about the HTTP spec
being changed so it's always UTF-8, but that's a Some Day(TM) kind of
thing, so you're stuck with all the stuff out there now which doesn't do
everything in UTF-8.
Sorry for the bad news, but if it makes you feel any better I've felt
your pain. Oh, and trying to process multipart/form-data (file upload)
forms is even worse and from what I've seen the API that people talk
about on these newsgroups assumes everything is ISO-8859-1.
Emmy Lau wrote:
>
Hi,
I am developing a servlet which supposed to be used to send and receive message
in multiple character set. However, I read from the previous postings that each
Weblogic Server can only support one input character encoding. Is that true?
And do you have any suggestions on how I can do what I want. For example, I
have a HTML form for people to post any comments (they may post in any characterset,
like ShiftJIS, Big5, Gb, etc). I need to know what character encoding they are
using before I can read that correctly in the servlet and save in the database. -
How to set XML character encoding for a SOAP response?
Hi,
We're using Oracle J2EE web services,
and are quite happy with them.
However, it's a problem that we need to have
characters outside the standard English alphabet
in our service responses. So far, we have not been
able to find a way to specify what encoding to use.
Our version (9.0.3 release) produces SOAP-responses
without any encoding specification in the XML header.
Any ideas?Hello,
If you are using the "Paper Layout", check the Reports's "Before Report Value" property:
Before Report Value :
<meta http-equiv="Content-Type" content="text/html; charset=&Encoding">
If you are using the "Web Layout", take a look to the document :
http://download-uk.oracle.com/docs/cd/B14099_17/bi.1012/b14048/pbr_nls.htm#i1006142
18.3 Specifying a Character Set in a JSP or XML File
Regards -
Some japanese character encoded to "?". Please help me..
My system is below listed.
J2SE 1.4.1
MySql Ver 11.18 Distrib 3.23.52,
Resin 2.1.4
Java application load html document encoded 'SHIFT_JIS' using HtmlURLConnection.
And read the document in 'SHIFT_JIS'.
Almost it appears properly but some of characters printed in '?'.
hm....
I will show my source code.
private String readDocument(URL url) {
String METHOD_NM = ".readDocument()";
try {
HttpURLConnection URLCon = (HttpURLConnection)url.openConnection();
BufferedReader in = new BufferedReader( new InputStreamReader(url.openStream(), "SJIS"));
String inputLine;
On my web server, input the character(printed '?') on textbox in IE6(japanese language pack). and submit. then the character translated the code(ex> #4575; )
The code inserted DB. select from DB the tuple.
and display the IE6. it's ok.
but loaded from japanese html. It's inserted to DB '?'.
and displayed '?' on IE6.
I want to translate the character to code(ex> #5455;).
OK?
Please reply...
p.s I'm sorry my poor english..Thank you for reply.
but I've already tried that.
I have tried all japanese encoding of "Supported Encodings" from java.
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
I want to convert that.
ex)
?fe? => & # 4532; fe & # 3456; => original charcater is removed blank
This is convert '?' to code number.
In this case '?' is Japanese character.
Please let me know the way.. -
Wrong character encoding from flash to mysql
Hi, im experiencing problems with character encoding not
functioning correctly when sending from flash to mysql. What i am
doing is doing a contact form in flash which then sends the value
to a php file which takes the values and inserts them into a table.
As i'm using icelandic charecters i need the char encoding to be
either latin1 or utf8 in mysql, or at least i think so. But it
seems that flash or the php document isn't sending in the same
format as i have selected in mysql because all special icelandic
characters come scrambled in the mysql table. Firefox tells me
tough that the html document containing the flash movie is using
utf-8.I don't know anything about Icelandic characters, but Flash
generally really likes UTF-8. So it should be sending that if that
is what it is starting with.
You aren't using any kind of useCodePage? That will mess it
up.
Are you sure that the input method is Icelandic?
In the testing environment can you list variables (from the
debug menu) and see if they look proper? If they do then Flash is
readying them correctly and the problem must be coming in further
down stream. -
Hi, i havent got any answer so i try to ask again...
I have created a page from Data Controls.
I have created parameter form. And table. Detail is showed at the bottom of page (there is shown current row through #bindings. . .
Everything works fine when i fill something into parameter form table is filtered by that criteria, when current row is changed, the detail is also changed. But when i fill some czech character into parametr form it works pretty bad.
The table is correctly filtered but when i make any other action after filtering, the table shows no rows.
I found what cause this problem. It is the Property in bindings that holds value for this parameter. When i first call bindings.findXXX.execute the Propertys value is "č" for example. That is correct and table shows filtered rows. After i perform another action (i think it is not dependent what the action is, but change current row fow example) the value in that Property has changed to "?" instead of "č" and because of this filter is applied again and table shows no rows. I have checked all encoding and character encoding is set to utf-8. Is this the problem and i miss some settings ?
1) menu tools-preferences-Environment
2) project properties- compiler-character encoding
3) in jspx
<?xml version='1.0' encoding='UTF-8'?>
<jsp:directive.page contentType="text/html;charset=UTF-8"
pageEncoding="UTF-8"/>
<afh:head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</afh:head>
is there other ? i dont know i set this settings long ago ...
Please if someone know, give me some hint , thanks for help.
Jdeveloper 10.1.3.0.4(SU5)check regional language settings on your machiner where u r application server is running. I faced this problem but was able to resolve by modifying the
NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1
NLS_LANG is under HKEY_LOCAL_MACHINE==>ORACLE
WE8ISO8859P1 is the standard encoding for my application developed in local indian language and works fine for me
THIS can help check out
Amit -
Hello Forum,
When I send a SearchRequest to OIM SPML Webservice, OIM returns this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Tue, 31 Jul 2012 12:03:28 GMT
<?xml version="1.0" encoding="UTF-8"?>
<ns6:attr name="Users.Last Name" xmlns:ns6="urn:oasis:names:tc:DSML:2:0:core"><ns6:value>P&_#_x_F_3;rtal</ns6:value></ns6:attr>
As you can observe, spml webservice seems that is using HTML Character Entity References for enconding "ó" (I had to underscore because of the interpretation of the browser it is ó ; ). This is causing me some headache with the other side integrators, that argue that messages are not coming in UTF-8 encoding.
We mantain that the message is still UTF-8, but somehow there's being an encoding. ¿Is this normal?¿Do we have any misconfiguration in our environment?
The most curious thing, is that SOAPUi on raw view of the response, shows the encoded data Pó ;rtal, but in the XML view shows "Pórtal", so SOAPUi is reencoding accordingly the data.
Is it possible that the spml message contains "ó" instead of its HTML Character Entity Reference encoding?
Thanks in advanced.
Xisco.
Edited by: user10084309 on 31-jul-2012 5:48
Edited by: user10084309 on 31-jul-2012 5:51Sorry, in the example I gave, the none-english letters looks like this:
&# 1490;&# 1497;&# 1488;(I made the space between the # and the number delibertly to prevent it from being presented as a letter ...). -
Hello All,
I am not clear about solving the problem.
We have a Java application on NT that is supposed to communicate with the same application on MVS mainframe through XML.
We have a character encoding for these XML commands we send for communication.
The problem is, on MVS the parser is not understaning the US-ASCII character encoding. And so we are getting the infamous "illegal character error".
The main frame file.encoding=CP1047 and
NT's file.encoding = us-ascii.
Is there any character encoding that is common to these two machines: mainframe and NT.
IF it is Unicode, what is the correct notation for it.
Or is there any way for specifying the parsers to which character encoding should be used.
thanks,
SridharOn the mainframe end maybe something like-
FileInputStream fris = new FileInputStream("C:\\whatever.xml");
InputStreamReader is= new InputStreamReader(fris, "ASCII");//or maybe "us-ascii" "US-ASCII"
BufferedReader brin = new BufferedReader(is);
Or give inputstream/buffered reader to whatever application you are using to parse the xml. The input stream reader should allow you to set your encoding even if the system doesnt have the native encoding. Depends though on which/whose jvm using you are using jdk1.2 at least supports following on this page http://as400bks.rochester.ibm.com/pubs/html/as400/v4r4/ic2924/info/java/rzaha/javaapi/intl/encoding.doc.html -
c:import character encoding problem (utf-8)
Aloha @ all,
I am currently importing a file using the <c:import> functionallity (<c:import url="module/item.jsp" charEncoding="UTF-8">) but it seems that the returned data is not encoded with utf-8 and hence not displayed correctly. The overall file header is:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=E67F9DAF44C7F96C0725652BEA1713D8;
Content-Type: text/html;charset=UTF-8
Content-Length: 6861
Date: Thu, 05 Jul 2007 04:18:39 GMT
Connection: close
I've set the file-encoding on all pages to :
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page pageEncoding="UTF-8"%>
but the error remains... is this a known bug and is there a workaround?Partially, yes. It turns out that I created the documents in eclipse with a different character encoding. Hence the entire document was actually not UTF-encoded...
So I changed each document encoding in Eclipse to UTF and got it working just fine... -
Quotation marks display as " in web pages, I'm using Unicode UTF-8 character encoding.
On many web pages, where a quotation mark character should appear, instead the page displays the text ". I believe this happens with other punctuation characters as well such as apostrophes although the text displayed in these other cases is different, of course. I'm guessing this is a problem with character encoding. I'm currently set to Unicode (UTF-8) encoding. Have tried several others without success.
Here's a link where the problem occurs. Note the second line of the main body of text.
http://www.sierratradingpost.com/lp2/snowshoes.html
BTW, I never use IE, but I checked this site in IE and it shows the same problem, so maybe it is the page encoding after all rather than what I thought.
In any case, my thanks for your help and would appreciate any solution you can suggest. -
Problems with Forms and character encoding
I'm having problems trying to read unicode data inputted into a Form on my JSP page.
I've used the meta tag <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> to set the charset of the page to UTF-8. I've inputted some chinese characters inot my form and when I try to read the subsequent request parameter in my servlet using request.getParameter() the string returned is this
"来源" which is the escape sequence required by HTML to display these characters.
From what I've read on the subject this doesn't seem like the expected value. I've tried other ways of getting the correct string value such as setting the character encoding request.setCharacterEncoding("UTF-8") and then converting the bytes using this encoding value but it doesn't seem to work.
I could write a method to split up the string using the ; as a token and working out the correct unicode character but this doesn't seem like the right thing to do.
Any help on how to pass the correct information from the Form in the JSP page to the servlet would be greatly appreciatedI don't believe that is correct, but if it's returning HTML escapes instead of URL Encoded characters, then it's the browser doing it. This is my test page for playing with Chinese...
<%@ page language="java" contentType="text/html; charset=UTF-8" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body bgcolor="#ffffff" background="" text="#000000" link="#ff0000" vlink="#800000" alink="#ff00ff">
<%
request.setCharacterEncoding("UTF-8");
String str = "\u7528\u6237\u540d";
String name = request.getParameter("name");
%>
req enc: <%= request.getCharacterEncoding() %><br />
rsp enc: <%= response.getCharacterEncoding() %><br />
str: <%= str %><br />
name: <%= name %><br />
<form method="GET" action="_lang.jsp" encoding="UTF-8">
Name: <input type="text" name="name" value="" >
<input type="submit" name="submit" value="GET Submit" />
</form>
<form method="POST" action="_lang.jsp" encoding="UTF-8">
Name: <input type="text" name="name" value="" >
<input type="submit" name="submit" value="POST Submit" />
</form>
</body>
</html>
Maybe you are looking for
-
Using iTunes on external drive with new computer
My mac died a few weeks ago but I had my iTunes library on an external drive. Trying to point my new mac at this same external drive so that I can get iTunes running again but can't seem to make it work. Is there any way around this without reimporti
-
I have an ipad 3rd gen with ios 5.1.1 and I can not update it to ios 7. It will take 13hours and when I try it stalls out halfway through and says software update failed. I have tried everything. Any help?
-
HD STB hooked up to Samsung LCD TV
Anyone having issues with their STB that is hooked up to a Samsung LCD TV via HDMI? It seems that I have to reset the STD by unplugging the power to the STB at least once weekly due to lost connection. The holdtime for tech support is "shall we say
-
Ipod camera black screen when opened and sync prob HELP!!!
hello i just went to open the camera on my ipod touch 4g and it just went black just a black screen when i press the home button it goes straight to the home screen everything else is fine i just open the camera and a black screen appears, it is work
-
Citation Manager for Pages 4.2 or later?
I have used RefWorks and EndNote and Mendeley to manage citations. As far as I know these only interface with MWord. Is there a plug-in or app that allows these citation managers to work with Pages? Are there other citation managers that work with Pa