File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Handling unicode character's in non-unicode browsers

 
Jason Keating
Greenhorn
Posts: 12
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm a long time lurker, and if memory serves a first time poster. Let me know if I put a foot astray.
I have a question regarding unicode support.
I have several sites using unicode characters, particularly the following.
#257 (macron over a)
#275 (macron over e)
#299 (macron over i)
#333 (macron over o)
#363 (macron over u)
#256 (macron over A)
#274 (macron over E)
#298 (macron over I)
#332 (macron over O)
#362 (macron over U)
Serving up these characters is no problem, but serving up readable alternatives to non-unicode browsers is. When I find a browser which I know does not support unicode characters by default I would like to display the character without a macron.
For example...
for a uni-code browser I would display a #257 (macron over a).
for a non-unicode browser I would display an 'a'.
My content will include unicode chars by default so I plan to replace the unicode chars with non-unicode chars when the occassion arises.
Is anyone able to point me in the right direction? so far I have found many references to provision/enabling of unicode support, but nothing covering extreme cases such this. I thought maybe jsp/servlets which provide internationalised support to WML might be a good place to start but I think its such a rare case that info is scarce.
Thanks in advance.
J
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it is not easy to detect whether the browser supports Unicode.
One way we can do is, if we are sure that a certain type of browsers support Unicode, like IE, then, we can perform a JS check, and send the request to the JSP.
When the client 1st send a request to the entry page, we show a blank page, and have an onload() method to check the browser. The method will the submit or redirect the client to the real JSP page, together with the browser type. For example, if the browser is IE, then send the request to support_unicode.jsp. If the browser is, say X which does not support unicode, then send the request to not_support_unicode.jsp.
And your JSP is able to print both unicode and non-unicode characters.
Does this help?
Nick.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic