217807 - non-latin characters submited as their unicode number representation

Status: RESOLVED EXPIRED

(Core :: DOM: Core & HTML, defect)

Description

[Antonis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728

Characters typed in Greek (and I believe in any language that doesn't use the
latin charset)
in any text input element of a form, when submited are converted to their
unicode representation
i.e ι
This creates a problem when the data posted is not to be used for displaying in
a web page.
For example if I write a greek message using my web based e-mail account, the
recepient (if not using
a web based account will see non understandable numbers and symbols. The same
happens if the data posted is
to be stored in a database for use by a non-browser application.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jo Hermans]

Reporter, can you give us an example where this goes wrong ? Is it a 'GET', or a
'POST' form ? And what charset is usd by that page ?

The form should normally use an 'accept-charset' parameter for the form, to
indicate in what charset the data should be. Ottherwise, we'll have to follow
the HTML4-standard, section 17.13.1:
#   Note. The "get" method restricts form data set values to ASCII
#   characters. Only the "post" method (with
#   enctype="multipart/form-data") is specified to cover the entire
#   [ISO10646] character set.

But copying and pasting data in a form can become compilcated too, depending on
the charset of the page where the form is located.

You can see a similar discussion in bug 212380, which mentions that there might
be a problem on Solaris.

Comment 2

[Jungshik Shin]

In addition to an example (URL), it'd be nice to know your setting of View -
Character Coding and your locale 

Comment 3

[Jungshik Shin]

The reporter sent the following via email. 
> try sending mail from hotmail.com or linuxmail.org or mail.yahoo.com.

 Sendiing emails in Yahoo.com and Hotmaail.com work fine as long as you set your
View|Character Coding
to the one that matches the 'language' setting of your Hotmail and Yahoo mail
**account**. Hotmail and Yahoo mail
are completely broken (in terms of I18N support) because both of them mix up
'prefered language' and 'character coding'. They're
orthogonal to (and independent of) each other, but both __studpid__ web mail
services (and most web mails are broken in a similar manner) 
[1] assume that  selecting Russian as your prefered UI language means that you
only receive your emails in Russian encoded in
KOI8-R Similarly, they assume that if I choose Korean, I will always send and
receive emails in EUC-KR(or Windows-949) so that
I cannot even send emails in Korean in UTF-8. 

> my locale shouldn't matter. I have a greek locale but I may like to send a
letter in say Russian. Should I
> change   my locale every time I post a form in a different charset ?

  You don't have to restart Mozilla under a different locale, but  you have to
create a new (Yahoo, Hotmail, etc) account to 
send emails in Russian for the reason given above. You need separate accounts
for Russian, Greek, French/German/English/Swedish,
 Korean, Japanese, SC, TC, and so forth.  

[1] See my bug report to IMP at http://bugs.horde.org/show_bug.cgi?id=1052
I made a patch to IMP a year ago and I used it successfully in my personal web
mail service(I set
up for a group of my friends), but IMP developers were not so much interested in
it. Unfortunately,
the patch is on my computer that is currently crossinng the Pacific. 

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.