Re: charset issues

J.Larmouth wrote:

> I agree.  The approach of saying "anything goes provided you label it" is
> better than we have now,  but is NOT good enough for the long term. 
> Pragmatically,  I would like to see the responsibility on server managers to
> ensure that the stuff they store is strictly UTF-8 or 8859-x,  recognising
> that such a requirement is NOT going to be easily satisfied (people often
> FTP into server directories from a wide variety of work stations).  Of

Hopefully, people will use browsers with PUT method for this. Browsers (or CGI
on server side) could translate from local code page to one of preferred
charsets. It could be also labeled as such. Browser can insert META tag,
while CGI can put appropriate extension or whatever.

> I agree.  This is an important point.  8859-1 should die a death.  But
> 8859-7,  for text which is simple Greek text,  is half the size of UTF-8.
> Does this matter?  The Web bandwidth (storage and transfer) is dominated by
> non-text documents,  so does a doubling of size of Greek text (for storage
> and transfer) matter??   Only the Greeks can tell us. (And the Arabs,  and
> the Israelis,  etc).  It would be nice if they said "It doesn't matter. 
> Let's all agree on UTF-8 for storage and transfer."  Comments?

Hmmm... How do I edit UTF-8 in vi? Or any other text editor? I could type
'make' after I'm done with editing, but I'll probably forget it.

> And WHY,  in all these discussions,  do we continually concentrate on
> delivery of pages and ignore forms input?

Because somebody will mention GET. HTTP 1.1 can't do anything about it.
Heated discussion guaranteed. :)
Perhaps Warning header would be a bit easier to tweak?

-- 
Life is a sexually transmitted disease.

dave@fly.cc.fer.hr
dave@zemris.fer.hr

Received on Friday, 6 December 1996 06:47:10 UTC