f



UTF-8 encoding

--------------30B96FF7F2435C15992C860D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi:
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 FileSave As 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?

//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"));
      BufferedReader in = new BufferedReader(new InputStreamReader(is));

      //Make sure that the contents get saved in readable format
      String inputLine;
      String newLine = " ";
      String newline = System.getProperty("line.separator");

      while ((inputLine = in.readLine()) != null)
     {
       newLine=newLine.concat(inputLine);
       newLine=newLine.concat(newline);

     }
   StringBufferInputStream sis = new StringBufferInputStream(newLine);
//set the stream for download to be sis
//download the temp.txt through a download bean
   is.close();
   utf8Writer.close();
   }
    catch (Throwable t)
    {
        handleError(t);
    }
  }


--------------30B96FF7F2435C15992C860D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hi:
<br>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&nbsp; takes into account
non-ascii data(users in non-english locale).
<p>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 FileSave As box
but displays the contents of the file in a same browser window whereas
Netscape saves the file as a 0 byte file.
<br>Can someone please let me know what could be wrong with the below code?
<p>//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.
<br><tt>try {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.Writer utf8Writer = new
OutputStreamWriter(new FileOutputStream("temp.txt",false), "UTF-8");</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;APIname>(utf8Writer); //API
call</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; utf8Writer.flush();</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.InputStream is = new BufferedInputStream(new
FileInputStream("temp.txt"));</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BufferedReader in = new BufferedReader(new
InputStreamReader(is));</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Make sure that the contents get
saved in readable format</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String inputLine;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String newLine = " ";</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String newline = System.getProperty("line.separator");</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while ((inputLine = in.readLine())
!= null)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newLine=newLine.concat(inputLine);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newLine=newLine.concat(newline);</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp; }</tt>
<br><tt>&nbsp;&nbsp; StringBufferInputStream sis = new StringBufferInputStream(newLine);</tt>
<br><tt>//set the stream for download to be sis</tt>
<br><tt>//download the temp.txt through a download bean</tt>
<br><tt>&nbsp;&nbsp; is.close();</tt>
<br><tt>&nbsp;&nbsp; utf8Writer.close();</tt>
<br><tt>&nbsp;&nbsp; }</tt>
<br><tt>&nbsp;&nbsp;&nbsp; catch (Throwable t)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; handleError(t);</tt>
<br><tt>&nbsp;&nbsp;&nbsp; }</tt>
<br><tt>&nbsp; }</tt>
<br>&nbsp;</html>

--------------30B96FF7F2435C15992C860D--

0
4/21/2004 1:20:58 AM
comp.lang.java.programmer 52714 articles. 1 followers. Post Follow

15 Replies
1080 Views

Similar Articles

[PageSpeed] 36

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
0
cdsmith (3862)
4/21/2004 5:16:20 AM
--------------3675B73273548C542BEC768C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Chris:

Chris Smith wrote:

> 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.

I changed that but it still does not work.

>
>
> 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.

This is required because I noticed that the file that gets saved on the system contains data/text as one single string. So I had to read the contents
of the buffer line by line separatoring it by line separator.

>
>
> 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.

Since I was reading the buffer into the above mentioned string, I have to use a StringBufferInputStream class which accepts a String. Moreover I
have a downloadBean defined for that page that works only on streams of data and not readers, hence I cannot use StringReader in placeof
StringBufferInputStream. Can you suggest anything?

>
>
> 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.

I changed this.

>
>
> 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:

I still see the following for non-ascii data:
IE -- part of the data is displayed in the same browser window, no File Save As downloadbox is shown
Netscape 7.1 -- the File Save As box is seen and it saves the file, but this operation goes into a loop and hence the successive files that get
downloaded are of O KB.

try {

      java.io.Writer utf8Writer = new OutputStreamWriter(new FileOutputStream("temp.txt",false), "UTF-8");

      <APIname>(utf8Writer);
      utf8Writer.flush();

      java.io.InputStream is = new BufferedInputStream(new FileInputStream("temp.txt"));
      BufferedReader in = new BufferedReader(new InputStreamReader(is, "UTF-8"));


      String fileContents;
      String newLine = " ";
      String lineSeparator = System.getProperty("line.separator");

      while ((fileContents = in.readLine()) != null)
     {
       newLine=newLine.concat(fileContents);
       newLine=newLine.concat(lineSeparator);

     }
      is.close();
      in.close();

      StringBufferInputStream sis = new StringBufferInputStream(newLine);
      //StringReader sis = new StringReader(newLine);

      nextPage.setBooleanProperty("download",true);
      //sis.close();

      //is.close();
      utf8Writer.close();
      setNextPage(nextPage);
      DownloadBean dataBean = new DownloadBean();
      dataBean.setStream(sis);
      //dataBean.setReader(sis);
      dataBean.setFileName("download.txt");
      dataBean.setSize(newLine.length());
      dataBean.setSuccessMessage(rb.getString("EXPORT_SUCCESS"));
      dataBean.setStatus(dataBean._SUCCESS);
      //setRedirectPage(nextPage);
      setDataBean(dataBean);
      setStatus(EventDone);
     }
    catch (Throwable t)
    {
      setDataBean(null);
      handleError(t);
    }
  }

>
>
> > //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

--------------3675B73273548C542BEC768C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Chris:
<p>Chris Smith wrote:
<blockquote TYPE=CITE>Nishi,
<p>See below for an answer.
<p>As a side note, would it be possible to convince you to choose a
<br>reasonable line wrap size in the future?&nbsp; It's a real pain to
reformat
<br>all the quoting when responding to your message.
<p>Nishi Bhonsle wrote:
<br>> In an servlet application, I need to pass a UTF-8 encoded writer
<br>> to an Java API, which will process the contents of a file through
<br>> the writer. Thereafter, the file can be saved on the users machine
<br>> through a OS specific "File Save As" dialog box. The UTF-8 encoding
<br>> takes into account non-ascii data(users in non-english locale).
<br>>
<br>> I noticed that this works fine on IE as well as Netscape for English
<br>> locale but for non-english locale, IE does not pop up the FileSaveAs
<br>> box but displays the contents of the file in a same browser window
<br>> whereas Netscape saves the file as a 0 byte file.
<br>>
<br>> Can someone please let me know what could be wrong with the below
<br>> code?
<p>Sure.&nbsp; Here are a few comments.
<p>First, you are writing a file in UTF-8 encoding, then turning around
and
<br>reading that file with the system's default encoding.&nbsp; That has
<br>undefined results, and will only do something sensible if the system
<br>default encoding happens to be UTF-8.&nbsp; If you know that you've
written
<br>the file in UTF-8, you should create an InputStreamReader using the
UTF-
<br>8 encoding explicitly, and use that to read the file back again.</blockquote>
I changed that but it still does not work.
<blockquote TYPE=CITE>&nbsp;
<p>Second, the code you posted doesn't compile.&nbsp; There's some confusion
<br>there where newLine is sometimes treated as a String (and declared
as a
<br>String), but used elsewhere as if it were a StringBuffer.&nbsp; I'm
going to
<br>assume that this is related to copying the code into your newsreader.
<br>Copy/paste works great for that, and saves you from these kinds of
<br>unintentional mistakes.</blockquote>
This is required because I noticed that the file that gets saved on the
system contains data/text as one single string. So I had to read the contents
<br>of the buffer line by line separatoring it by line separator.
<blockquote TYPE=CITE>&nbsp;
<p>Third, you completely destroy any shot of writing working code when
you
<br>use the StringBufferInputStream class.&nbsp; There's a very good reason
that
<br>it's deprecated.</blockquote>
Since I was reading the buffer into the above mentioned string, I have
to use a StringBufferInputStream class which accepts a String. Moreover
I
<br>have a downloadBean defined for that page that works only on streams
of data and not readers, hence I cannot use StringReader in placeof
<br>StringBufferInputStream. Can you suggest anything?
<blockquote TYPE=CITE>&nbsp;
<p>Fourth, why on earth do you have one variable called 'newline' and
<br>another called 'newLine'.&nbsp; You'd have to try really hard to come
up with
<br>something so bug-prone as that.</blockquote>
I changed this.
<blockquote TYPE=CITE>&nbsp;
<p>If you can clarify what you mean to accomplish by everything past where
<br>you create the BufferedInputStream, perhaps I can help more.&nbsp;
Looks to
<br>me like the only purpose of any code past this:</blockquote>
I still see the following for non-ascii data:
<br>IE -- part of the data is displayed in the same browser window, no
File Save As downloadbox is shown
<br>Netscape 7.1 -- the File Save As box is seen and it saves the file,
but this operation goes into a loop and hence the successive files that
get
<br>downloaded are of O KB.
<p><tt>try {</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.Writer utf8Writer = new OutputStreamWriter(new
FileOutputStream("temp.txt",false), "UTF-8");</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;APIname>(utf8Writer);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; utf8Writer.flush();</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.InputStream is = new BufferedInputStream(new
FileInputStream("temp.txt"));</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BufferedReader in = new BufferedReader(new
InputStreamReader(is, "UTF-8"));</tt>
<br><tt>&nbsp;</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String fileContents;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String newLine = " ";</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String lineSeparator = System.getProperty("line.separator");</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while ((fileContents = in.readLine())
!= null)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newLine=newLine.concat(fileContents);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newLine=newLine.concat(lineSeparator);</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp; }</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is.close();</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in.close();</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; StringBufferInputStream sis = new
StringBufferInputStream(newLine);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //StringReader sis = new StringReader(newLine);</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nextPage.setBooleanProperty("download",true);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //sis.close();</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //is.close();</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; utf8Writer.close();</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setNextPage(nextPage);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DownloadBean dataBean = new DownloadBean();</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dataBean.setStream(sis);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //dataBean.setReader(sis);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dataBean.setFileName("download.txt");</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dataBean.setSize(newLine.length());</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dataBean.setSuccessMessage(rb.getString("EXPORT_SUCCESS"));</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dataBean.setStatus(dataBean._SUCCESS);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //setRedirectPage(nextPage);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setDataBean(dataBean);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setStatus(EventDone);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; }</tt>
<br><tt>&nbsp;&nbsp;&nbsp; catch (Throwable t)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setDataBean(null);</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; handleError(t);</tt>
<br><tt>&nbsp;&nbsp;&nbsp; }</tt>
<br><tt>&nbsp; }</tt>
<blockquote TYPE=CITE>&nbsp;
<p>> //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.
<br>> try {
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.Writer utf8Writer = new
OutputStreamWriter(new FileOutputStream("temp.txt",false), "UTF-8");
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;APIname>(utf8Writer); //API
call
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; utf8Writer.flush();
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; java.io.InputStream is = new
BufferedInputStream(new FileInputStream("temp.txt"));
<p>... is to break things.&nbsp; Just do the above, and as far as I can
tell you
<br>are done.
<p>--
<br>www.designacourse.com
<br>The Easiest Way to Train Anyone... Anywhere.
<p>Chris Smith - Lead Software Developer/Technical Trainer
<br>MindIQ Corporation</blockquote>
</html>

--------------3675B73273548C542BEC768C--

0
4/22/2004 12:11:29 AM
Nishi Bhonsle wrote:
>  
> Hi:
> 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 FileSave As 
> 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?

I have a feeling this may be to do with the mime file type that the server
says the file is - in the header of the reply to the GET request. 
I think the decision to offer a "File Save As" dialog
is made before the browser ever attempts to read the file contents, in which 
case the actual encoding you use is irrelevant to your current problem.

I could be completely wrong though.

Steve
0
shoot3 (317)
4/22/2004 7:56:52 PM
Again,

> Chris Smith wrote:
> > 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:
> I changed that but it still does not work.

Yep.  That was one of several problems in your code.  You'll need to fix 
the others.

[newline stuff]

Nishi Bhonsle wrote:
> This is required because I noticed that the file that gets saved on the
> system contains data/text as one single string. So I had to read the
> contents of the buffer line by line separatoring it by line separator.

Okay, that makes more sense, then.  You'll just need to fix this so 
you're doing it right.  Still, it appears that there's some confusion 
between String and StringBuffer in your code.

> > 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.
> 
> Since I was reading the buffer into the above mentioned string, I have
> to use a StringBufferInputStream class which accepts a String. Moreover
> I have a downloadBean defined for that page that works only on streams
> of data and not readers, hence I cannot use StringReader in placeof
> StringBufferInputStream. Can you suggest anything?

The fact remains that StringBufferInputStream is broken.  You can't use 
it if you want your code to have any shot at working with anything but 
ASCII or ISO8859-1 encodings.

As for how to read a String as an InputStream, you need to first choose 
an encoding.  You've been using UTF-8, and there's no reason to switch 
now.  Next, you need to convert the String to a byte sequence using that 
encoding (String.getBytes(String enc) works if you expect the result to 
fit in memory; otherwise, you can write the String to an 
OutputStreamWriter -- and specify the encoding in the constructor -- 
wrapping a FileOutputStream for a temporary file).  Finally, you can 
open an InputStream for that byte sequence (ByteArrayInputStream if it's 
in memory, or FileInputStream if you wrote to a temporary file on disk).

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/22/2004 8:42:21 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > In an servlet application, I need to pdass 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve
ddd
0
4/25/2004 12:41:20 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > In an servledt 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve

ddd
0
4/25/2004 12:41:35 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve

ddd
0
4/25/2004 12:41:51 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve

ddd
0
4/25/2004 12:42:02 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve

ddd
0
4/25/2004 12:42:12 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve

ddd
0
4/25/2004 12:42:23 PM
Steve Horsley <shoot@the.moon> wrote in message news:<c697ju$42s$1@news.freedom2surf.net>...
> Nishi Bhonsle wrote:
> >  
> > Hi:
> > 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 FileSave As 
> > 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?
> 
> I have a feeling this may be to do with the mime file type that the server
> says the file is - in the header of the reply to the GET request. 
> I think the decision to offer a "File Save As" dialog
> is made before the browser ever attempts to read the file contents, in which 
> case the actual encoding you use is irrelevant to your current problem.
> 
> I could be completely wrong though.
> 
> Steve
ddd
0
4/25/2004 12:42:46 PM
On 25 Apr 2004 05:41:20 -0700, Icemerth wrote:

> ddd

D.. d d d d do d d d don d d d d d don't
lll l l leeave the d d door op p p pen!

I i i it's s c c c co c cold!    ;-)

-- 
A a aa andrew  T t t thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
0
SeeMySites (5478)
4/25/2004 1:22:10 PM
On 25 Apr 2004 05:42:02 -0700, jamesblock69@hotmail.com (Icemerth)
wrote or quoted :

>ddd

You have done this repeatedly. Why? are you just trying to annoy
people for some reason?  Has it some deep inner meaning that escapes
me.  Is this the way you trigger a terrorist bomb in Washington?


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
0
see746 (499)
4/25/2004 11:24:12 PM
On 25 Apr 2004 05:41:20 -0700, jamesblock69@hotmail.com (Icemerth)
wrote or quoted :

>> Steve
>ddd

He did this in to other posts as well. I see no sign of anything in
English from him, so a plonk is in order.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming. 
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
0
see746 (499)
4/25/2004 11:25:28 PM
Roedy Green wrote:
> On 25 Apr 2004 05:42:02 -0700, jamesblock69@hotmail.com (Icemerth)
> wrote or quoted :
> 
> 
>>ddd
> 
> 
> You have done this repeatedly. Why? are you just trying to annoy
> people for some reason?  Has it some deep inner meaning that escapes
> me.  Is this the way you trigger a terrorist bomb in Washington?

I have now reported him twice to his ISP. Didn't we get something like
8 reply posts from this address yesterday?
It's one thing to misunderstand the posting mechanism, another thing
entirely when you repeat your mistake eight times! ... ;-)

0
bitbucket44 (1435)
4/26/2004 2:01:08 AM
Reply: