Re: UTF-8 encoding
From: Chris Smith (cdsmith_at_twu.net)
Date: 04/21/04
- Next message: Phlip: "Re: why not Java?"
- Previous message: Chris Smith: "Re: why not Java?"
- In reply to: Nishi Bhonsle: "UTF-8 encoding"
- Next in thread: Nishi Bhonsle: "Re: UTF-8 encoding"
- Reply: Nishi Bhonsle: "Re: UTF-8 encoding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 20 Apr 2004 23:16:20 -0600
Nishi,
See below for an answer.
As a side note, would it be possible to convince you to choose a
reasonable line wrap size in the future? It's a real pain to reformat
all the quoting when responding to your message.
Nishi Bhonsle wrote:
> In an servlet application, I need to pass a UTF-8 encoded writer
> to an Java API, which will process the contents of a file through
> the writer. Thereafter, the file can be saved on the users machine
> through a OS specific "File Save As" dialog box. The UTF-8 encoding
> takes into account non-ascii data(users in non-english locale).
>
> I noticed that this works fine on IE as well as Netscape for English
> locale but for non-english locale, IE does not pop up the FileSaveAs
> box but displays the contents of the file in a same browser window
> whereas Netscape saves the file as a 0 byte file.
>
> Can someone please let me know what could be wrong with the below
> code?
Sure. Here are a few comments.
First, you are writing a file in UTF-8 encoding, then turning around and
reading that file with the system's default encoding. That has
undefined results, and will only do something sensible if the system
default encoding happens to be UTF-8. If you know that you've written
the file in UTF-8, you should create an InputStreamReader using the UTF-
8 encoding explicitly, and use that to read the file back again.
Second, the code you posted doesn't compile. There's some confusion
there where newLine is sometimes treated as a String (and declared as a
String), but used elsewhere as if it were a StringBuffer. I'm going to
assume that this is related to copying the code into your newsreader.
Copy/paste works great for that, and saves you from these kinds of
unintentional mistakes.
Third, you completely destroy any shot of writing working code when you
use the StringBufferInputStream class. There's a very good reason that
it's deprecated.
Fourth, why on earth do you have one variable called 'newline' and
another called 'newLine'. You'd have to try really hard to come up with
something so bug-prone as that.
If you can clarify what you mean to accomplish by everything past where
you create the BufferedInputStream, perhaps I can help more. Looks to
me like the only purpose of any code past this:
> //this page has the "download" property set, so the temp.txt will be saved on the users machine by providing the user with a File //SaveAs dialog box.
> try {
> java.io.Writer utf8Writer = new OutputStreamWriter(new FileOutputStream("temp.txt",false), "UTF-8");
>
> <APIname>(utf8Writer); //API call
> utf8Writer.flush();
>
> java.io.InputStream is = new BufferedInputStream(new FileInputStream("temp.txt"));
... is to break things. Just do the above, and as far as I can tell you
are done.
-- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
- Next message: Phlip: "Re: why not Java?"
- Previous message: Chris Smith: "Re: why not Java?"
- In reply to: Nishi Bhonsle: "UTF-8 encoding"
- Next in thread: Nishi Bhonsle: "Re: UTF-8 encoding"
- Reply: Nishi Bhonsle: "Re: UTF-8 encoding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
