Re: UTF-8 without external modules on Perl 5.0
- From: Yohan N. Leder <ynleder@xxxxxxxxxx>
- Date: Mon, 22 May 2006 01:57:34 +0200
In article <Pine.LNX.4.64.0605212047350.2976@xxxxxxxxxxxxxxxxxxxx>,
flavell@xxxxxxxxxxxxxxxxx says...
[ in a context where an old version of Perl has been imposed ... ]
Imposed, yes : it's the right word :(
Yes, this could indeed resolve the stated problem. (Windows-1252
could handle Czech also, no? - but not Polish etc). It's what the
search engines' query pages (altavista, google etc.) were doing some
years ago, before general browser support for utf-8 was adequate.
Users could select an 8-bit web page encoding appropriate to their
language, and then submit their query - the browser would submit their
input using that same encoding.
Hum, no, it's sound like a good solution if final public were a
technical one... But the fact is that final users will be a commercial
ones and sure they will simply ignore the list or choose the first to
fill-in quickly. The only sign they will not ommit will be the euro one,
percents and sum !
This is probably the wrong place to go into any detail on that, but if
I might mention
http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html
I'be bookmarked it and started to read it : not and easy subject. I'll
read it in depth just after having solved my current problematic target
: Perl 5.00503 which is a little bit forgotten everywhere (normal).
There's absolutely nothing you can do to prevent users from typing or
copy/pasting oddball characters into the form, and browsers react in
various ways when they attempt to submit characters which cannot be
expressed in the chosen encoding. So it's necessary to design server
side scripts to be able to cope in some way when that happens - if
only to recognise the defective input and politely refuse it.
Hey, don't you told about the alt.html thread on which I started to
express my problem... Well, we're agree : user will do what he wants !
And I have to refuse any malformed multipart/form-data data (since these
same form will handle file upload). I'm thinking about that :)
Depending on the circumstances, it may be that file upload would be a
preferable implementation, as you hinted?
Oh, I didn't talk about file uploadabout field data, but because user
will have possibility to upload a file (about their commercial results)
in paralel. So, the multipart/form-data will contain the text fields
data and the uploaded binary file.
With sufficiently modern software, on the other hand, I'd strongly
recommend getting things to work with utf-8. Practically any browser
of any consequence today can deal with that (as you may deduce from
the fact that the search engine queries no longer bother the user with
the encoding options, but simply use utf-8 without further comment).
I would like to, but how : please, just take a look at the reply (and my
questions) I done towards Peter.
Also, thanks to you too, Alan : for your kindly replies here and in
alt.html
best.
- Follow-Ups:
- Re: UTF-8 without external modules on Perl 5.0
- From: Mumia W.
- Re: UTF-8 without external modules on Perl 5.0
- References:
- UTF-8 without external modules on Perl 5.0
- From: Yohan N . Leder
- Re: UTF-8 without external modules on Perl 5.0
- From: Peter J. Holzer
- Re: UTF-8 without external modules on Perl 5.0
- From: Alan J. Flavell
- UTF-8 without external modules on Perl 5.0
- Prev by Date: Re: XS Progamming with Perl 6
- Next by Date: Re: XS Progamming with Perl 6
- Previous by thread: Re: UTF-8 without external modules on Perl 5.0
- Next by thread: Re: UTF-8 without external modules on Perl 5.0
- Index(es):
Relevant Pages
|
Loading