Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Prototype, Safari and Japanese problems?

Reply
Thread Tools

Prototype, Safari and Japanese problems?

 
 
Doug Lerner
Guest
Posts: n/a
 
      01-18-2006
I'm working on a client/server app that seems to work fine in OS Firefox and
Windows IE and Firefox.

However, in OS X Safari, although the UI/communications themselves work
fine, if the characters getting sent back and forth are in Japanese they
come back from the server "moji bake" (corrupted).

Anybody have any ideas why this might work differently in Safari than in
Firefox or IE?

Thanks!

doug


 
Reply With Quote
 
 
 
 
Martin Honnen
Guest
Posts: n/a
 
      01-18-2006


Doug Lerner wrote:


> However, in OS X Safari, although the UI/communications themselves work
> fine, if the characters getting sent back and forth are in Japanese they
> come back from the server "moji bake" (corrupted).


Consider to use UTF-8 encoded Unicode characters and make sure the
server sends a HTTP header declaring e.g.
Content-Type: application/xml; charset=UTF-8
or if you send plain text then e.g.
Content-Type: text/plain; charset=UTF-8
I assume you use XMLHttpRequest to send and receive data, with the above
both responseXML or responseText should hopefully work correctly
(although I am not familiar with details of the Safari implementation).



--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
 
 
 
Doug Lerner
Guest
Posts: n/a
 
      01-19-2006



On 1/18/06 10:05 PM, in article
43ce3d0c$0$21036$(E-Mail Removed)-online.net, "Martin Honnen"
<(E-Mail Removed)> wrote:

> Doug Lerner wrote:
>
>
>> However, in OS X Safari, although the UI/communications themselves work
>> fine, if the characters getting sent back and forth are in Japanese they
>> come back from the server "moji bake" (corrupted).

>
> Consider to use UTF-8 encoded Unicode characters and make sure the
> server sends a HTTP header declaring e.g.
> Content-Type: application/xml; charset=UTF-8
> or if you send plain text then e.g.
> Content-Type: text/plain; charset=UTF-8
> I assume you use XMLHttpRequest to send and receive data, with the above
> both responseXML or responseText should hopefully work correctly
> (although I am not familiar with details of the Safari implementation).


Thanks for your response.

In my case, the return data is not being used to replace an entire HTML
page, it is being used to set the innerHTML for a <div> tag. So sending the
HTTP header wouldn't be appropriate in this case, would it?

The charset for the entire page itself is correct already.

Any thoughts about this?

Thanks!

doug

 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      01-19-2006

Doug Lerner wrote:
> On 1/18/06 10:05 PM, in article
> 43ce3d0c$0$21036$(E-Mail Removed)-online.net, "Martin Honnen"
> <(E-Mail Removed)> wrote:
>
> > Doug Lerner wrote:
> >
> >
> >> However, in OS X Safari, although the UI/communications themselves work
> >> fine, if the characters getting sent back and forth are in Japanese they
> >> come back from the server "moji bake" (corrupted).

> >
> > Consider to use UTF-8 encoded Unicode characters and make sure the
> > server sends a HTTP header declaring e.g.
> > Content-Type: application/xml; charset=UTF-8
> > or if you send plain text then e.g.
> > Content-Type: text/plain; charset=UTF-8
> > I assume you use XMLHttpRequest to send and receive data, with the above
> > both responseXML or responseText should hopefully work correctly
> > (although I am not familiar with details of the Safari implementation).

>
> Thanks for your response.
>
> In my case, the return data is not being used to replace an entire HTML
> page, it is being used to set the innerHTML for a <div> tag. So sending the
> HTTP header wouldn't be appropriate in this case, would it?
>
> The charset for the entire page itself is correct already.
>
> Any thoughts about this?


AFAIK browser page is a "single encoding" unit therefore you cannot
display one paragraph in iso-8859-1 and another in say Shift_JIS. This
is why Unicode became originally needed. Did you try to have the entire
page served in UTF-8 including any further server interchange?

 
Reply With Quote
 
Martin Honnen
Guest
Posts: n/a
 
      01-19-2006


Doug Lerner wrote:


> In my case, the return data is not being used to replace an entire HTML
> page, it is being used to set the innerHTML for a <div> tag. So sending the
> HTTP header wouldn't be appropriate in this case, would it?
>
> The charset for the entire page itself is correct already.


If you use XMLHttpRequest and the responseText property then the client
receiving the response needs to know the charset/encoding of the
response to build responseText correctly. At least in theory, MSXML used
by IE does not care about HTTP headers when building responseText and
assumes UTF-8 so that is why I suggested to use UTF-8 and to make that
known with the HTTP header as that way MSXML and Mozilla and Opera and
hopefully Safari should then give you responseText with any characters
Unicode can encode, be that Japanese or whatever else.


--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Doug Lerner
Guest
Posts: n/a
 
      01-19-2006



On 1/19/06 6:15 PM, in article
(E-Mail Removed). com, "VK"
<(E-Mail Removed)> wrote:

>> Thanks for your response.
>>
>> In my case, the return data is not being used to replace an entire HTML
>> page, it is being used to set the innerHTML for a <div> tag. So sending the
>> HTTP header wouldn't be appropriate in this case, would it?
>>
>> The charset for the entire page itself is correct already.
>>
>> Any thoughts about this?

>
> AFAIK browser page is a "single encoding" unit therefore you cannot
> display one paragraph in iso-8859-1 and another in say Shift_JIS. This
> is why Unicode became originally needed. Did you try to have the entire
> page served in UTF-8 including any further server interchange?


Yes, I tried that. Something just seems "different" about the way it is
working in Safari. With Firefox or IE, it seems to work fine, even with the
Shift_JIS charset.

But with Safari the Japanese seems to get corrupted. I think it *is* sending
it to the server in UTF-8. That is, if I log the received data on the server
side and examine it it appears to be UTF-8 data. But when I send it back to
the browser, even if the browser's charset is UTF-8 it shows up looking
corrupted.

doug

 
Reply With Quote
 
Doug Lerner
Guest
Posts: n/a
 
      01-19-2006



On 1/19/06 9:10 PM, in article
43cf81b6$0$20781$(E-Mail Removed)-online.net, "Martin Honnen"
<(E-Mail Removed)> wrote:

>
>
> Doug Lerner wrote:
>
>
>> In my case, the return data is not being used to replace an entire HTML
>> page, it is being used to set the innerHTML for a <div> tag. So sending the
>> HTTP header wouldn't be appropriate in this case, would it?
>>
>> The charset for the entire page itself is correct already.

>
> If you use XMLHttpRequest and the responseText property then the client
> receiving the response needs to know the charset/encoding of the
> response to build responseText correctly. At least in theory, MSXML used
> by IE does not care about HTTP headers when building responseText and
> assumes UTF-8 so that is why I suggested to use UTF-8 and to make that
> known with the HTTP header as that way MSXML and Mozilla and Opera and
> hopefully Safari should then give you responseText with any characters
> Unicode can encode, be that Japanese or whatever else.
>


Thanks for your note. As mentioned in my note, the charset for the entire
page being served was correct. And I tried UTF-8 instead, but that didn't
seem to help.

It displays fine with all browsers except for Safari. I'm sort of stumped.

doug

 
Reply With Quote
 
Martin Honnen
Guest
Posts: n/a
 
      01-19-2006


Doug Lerner wrote:


> Thanks for your note. As mentioned in my note, the charset for the entire
> page being served was correct.


I am not sure I understand what an entire page is or why that matters or
what you are doing exactly, no wonder as you have not posted any code so
far.
If you serve one HTML document with script and that script makes further
requests to the server using XMLHttpRequest then the server needs to
make sure it sends proper HTTP response headers (with Content-Type and
charset parameter) in its response to any request the script makes if
the browser's XMLHttpRequest implementation should have a chance to
build responseText properly. It does not matter if you do not consider
or indeed such a response is not a complete HTML document but if a HTTP
response is processed then to build a responseText string you need to
know the charset to properly decode the bytes in the response body into
the responseText string.

--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-19-2006
VK wrote:

> AFAIK browser page is a "single encoding" unit


True.

> therefore you cannot display one paragraph in iso-8859-1 and another in
> say Shift_JIS.


False. Character references and character entity references are there ever
since to workaround this issue. For example, it is perfectly reasonable,
possible and Valid to use the hexadecimal byte sequence 26 23 38 32 31 31
3B 0A, this represents the decimal character reference `–', for
displaying the Unicode character named "EN DASH" (U+2013) in a HTML
resource encoded with ISO-8859-1 and served as such. In fact, the same
byte sequence could _not_ result in that character reference if the
resource was encoded with a UTF and served as such.

> This is why Unicode became originally needed.


Not quite. The reason for creating the Unicode standard and subsequently
the Unicode character set was that _one_ standard and _one_ character set
for all characters was needed, so that one encoding would suffice for all
characters and all textual resources, not only SGML-conforming ones such
as HTML documents, and that the latter then could contain the characters
as they are, without any character reference or character entity reference
which would save bandwidth and disk space.

> Did you try to have the entire page served in UTF-8 including any further
> server interchange?


The encoding of an SGML-conforming markup resource, that is, how the
character data of a resource is encoded, does not have any impact on
the characters that can be displayed with it, that is, what character
sets can be used to display that data.

Despite its name, the "charset" label of the HTTP Content-Type header
specifies the _encoding_ of the served resource, not necessarily the
character set(s) that is/are to be used to display it; the confusing
name of the label is because of the history of MIME to which HTTP had
to adhere.


HTH

PointedEars
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-19-2006
Doug Lerner wrote:

> I'm working on a client/server app that seems to work fine in OS Firefox
> and Windows IE and Firefox.
>
> However, in OS X Safari, although the UI/communications themselves work
> fine, if the characters getting sent back and forth are in Japanese they
> come back from the server "moji bake" (corrupted).
>
> Anybody have any ideas why this might work differently in Safari than in
> Firefox or IE?


Do not follow the suggestions to serve a resource as UTF-8-encoded
if it is not UTF-8-encoded; that would be harmful.

Check the Content-Type header of any related response for the "charset"
label; make sure it is present and specifies the encoding the served
resource is actually encoded with. Check the response body of any
related (X)HTML resource for

<meta http-equiv="Content-Type" content="text/html; charset=..." ...>

and if found, correct it so that it conforms with the label in the
Content-Type header it is served with.

Do not serve XHTML with Content-Type: text/html.

If you send data, make sure that it is send x-www-url-encoded; if
you do not encode it yourself, make sure that Safari is able to
percent-encode those Japanese characters properly according to
x-www-url-encoded when submitted.

If that does not help and, as the Subject and your first paragraph
suggests (however, you should have mentioned "Prototype" once in
the message body -- not all people [can] read the Subject), you
use prototype.js to submit the data via XMLHTTP, post the URI of a
test case so that one can determine what you might be doing wrong.

Ceterum censeo prototype.js esse deletam.


PointedEars
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with Japanese Fonts and Java (Mayjay) ro.naldfi.scher@gmail.com Java 2 06-07-2006 10:56 AM
Japanese Locale and SimpleDateFormat sameergn@gmail.com Java 2 06-27-2005 04:12 PM
Japanese and Chinese people take better pictures John Dough Digital Photography 0 07-19-2004 07:56 PM
Japanese films: "Cure" and "Suicide Club" Viktor Davros DVD Video 0 02-23-2004 07:12 PM
For Japanese violence and horror fans Mischa van Dinter DVD Video 1 02-03-2004 07:55 PM



Advertisments