I think it is difficult to make web server to work correctly in case
we have variety of charset text files on the server.
Although we can manually select charset in browser menu, the selection
is useless in case the page is written in Javascript that fills some
portion of a page reading a text file.
(note that the text file will be interpreted as ascii without
"charset" in http header.)
I believe the only solution every thing work correctly is to write all
text files in utf-8 and put "charset=utf-8" in http header as Erik is
trying.
P.S.
file(1) speaks only mine type but not charset.
it is difficult or impossible to determine charset from a few japanese
letters.
Kenji Arisawa
On 2009/10/19, at 19:00, Akshat Kumar wrote:
new/sendfd.c:243 c old/sendfd.c:243
<
---
/*
new/sendfd.c:246 c old/sendfd.c:246
<
---
*/
(context: text/plain -> text/plain; charset=utf-8)
Now my text files can be read in the proper encoding
by default, and are not interpreted by browsers (as
well as certain applications) to be whack ASCII.
Is the output of file(1) appropriate for this purpose?
Shouldn't your sample file also be sent as UTF-8?
Thank you for the input, Mr. Arisawa. I agree with
Erik in this case, as you wouldn't be doing much with
files of other encodings on Plan 9 (well, prior to a
tcs(1)), you really only need to worry about getting
across UTF-8.
The point about file handling being up to browsers is
appropriate. However, I'd like to push as much standard
behaviour from the server as I can. If there's an explicit
account of the encoding and type of a file, then there
ought to be no ambiguity.
Thanks,
ak
