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
Jan 18 '06
21  2505 
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
On 1/19/06 10:59 PM, in article
43************* **********@news read2.arcor-online.net, "Martin Honnen"
<ma*******@yaho o.de> wrote:
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.
Let me ask you more about this, because I am obviously confused about this
point.
I am serving one page, that starts with <html> and has the correct charset
header in it.
The XMLHttpRequest is returning text which I am using to set the .innerHTML
of a div section with.
Where in this text would it make sense to store the charset of just the
snippet I am returning from the server.
Thanks!
doug
On 1/19/06 10:41 PM, in article 11************* ********@g14g20 00...legro ups.com, "VK"
<sc**********@y ahoo.com> wrote:
Doug Lerner wrote: On 1/19/06 6:15 PM, in article
11************* *********@g47g2 00...legr oups.com, "VK"
<sc**********@y ahoo.com> 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.
Corrupted in what way?
1) Latin ASCII chars ?
2) Unicode "missing gliph" chars ? (empty squares)
3) Japanese gliphs but not the needed one ?
Hard to describe in words, so here are some screenshots:
Correct (with Firefox): http://lerner.net/doug/jptext1.jpg
Corrupted (with Safari): http://lerner.net/doug/jptext2.jpg
Another note, if I look at the data logged at the server side, I can see it
correctly there even in Safari if I force the browser to UTF-8 encoding. So
it does seem that the data that gets sent through it somehow being converted
or something to UTF-8.
But forcing the client app I am working on to see the data coming back at
UTF-8 doesn't help.
Thanks,
doug
Doug Lerner wrote: I am serving one page, that starts with <html> and has the correct
charset header in it.
^^^^^
What you call a "correct charset header" here is (due to the description
you provide of it) _not_ was is called a header in Internet messages at
all, but merely a HTML meta[http-equiv] element. This element, especially
with the `http-equiv' attribute value `Content-Type' (case-insensitive),
MUST be _ignored_ by a compliant HTTP/1.1 client if the respective HTTP
header was already sent by the HTTP server. (RFC2616, 3.4.1.)
Furthermore, a "page", which should be in fact a Valid HTML document, MUST
NOT start with `<html>' (RFC2854 "The 'text/html' Media Type", section 5,
explains that 'Almost all HTML files have the string "<html" or "<HTML"
_near the beginning_ of the file'.) HTML is an SGML application, therefore
a DOCTYPE declaration is required for a Valid HTML document prior to the
root element (here: html). This is explained in RFC2854, and specified in
the HTML 3.2, HTML 4.01 and ISO HTML specifications (where the latter is a
standardized version of HTML 4.01 Strict; HTML versions prior to 3.2, such
as HTML 2.0, are obsoleted by RFC2854.)
<URL:http://validator.w3.or g/>
The XMLHttpRequest is returning text which I am using to set the
.innerHTML of a div section with.
It matters how the Japanese glyphs in the retrieved hypertext snippet are
referenced or encoded. If only character references or character entity
references are used therein, then there should not be a problem even if the
target document, that is, the document containing the `div' element, has a
different encoding. However, if the encoding of the target document and
the retrieved data differ and characters are not referred to as described,
the hypertext data, when included into the target document, is very likely
to be displayed garbled.
Where in this text would it make sense to store the charset of just the
snippet I am returning from the server.
Nowhere _in_ the text, that is, the message body. You should serve either
resource with the appropriate Content-Type _HTTP (message) header_ and
"charset" label as I suggested in my other followup. Due to the confusion
you display here about headers, it is probably a good idea if you learned
more about how HTTP works before; reading RFC2616 would be a good start.
Regards,
PointedEars
Doug Lerner wrote: I am serving one page, that starts with <html> and has the correct
charset header in it.
^^^^^
What you call a "correct charset header" here, is (due to the description
you provide of it) _not_ what is called a header in Internet messages at
all, but merely a HTML meta[http-equiv] element. This element, especially
with the `http-equiv' attribute value `Content-Type' (case-insensitive),
MUST be _ignored_ by a compliant HTTP/1.1 client if the respective HTTP
header was already sent by the HTTP server. (RFC2616, 3.4.1.)
Furthermore, a "page", which should be in fact a Valid HTML document, MUST
NOT start with `<html>' (RFC2854 "The 'text/html' Media Type", section 5,
explains that 'Almost all HTML files have the string "<html" or "<HTML"
_near the beginning_ of the file'.) HTML is an SGML application, therefore
a DOCTYPE declaration is required for a Valid HTML document prior to the
root element (here: html). This is explained in RFC2854, and specified in
the HTML 3.2, HTML 4.01 and ISO HTML specifications (where the latter is a
standardized version of HTML 4.01 Strict; HTML versions prior to 3.2, such
as HTML 2.0, are obsoleted by RFC2854.)
<URL:http://validator.w3.or g/>
The XMLHttpRequest is returning text which I am using to set the
.innerHTML of a div section with.
It matters how the Japanese glyphs in the retrieved hypertext snippet are
referenced or encoded. If only character references or character entity
references are used therein, then there should not be a problem even if the
target document, that is, the document containing the `div' element, has a
different encoding. However, if the encoding of the target document and
the retrieved data differ and characters are not referred to as described,
the hypertext data, when included into the target document, is very likely
to be displayed garbled.
Where in this text would it make sense to store the charset of just the
snippet I am returning from the server.
Nowhere _in_ the text, that is, the message body. You should serve either
resource with the appropriate Content-Type _HTTP (message) header_ and
"charset" label as I suggested in my other followup. Due to the confusion
you display here about headers, it is probably a good idea if you learned
more about how HTTP works before; reading RFC2616 would be a good start.
Regards,
PointedEars
On 1/20/06 10:16 AM, in article 28************* ***@PointedEars .de, "Thomas
'PointedEars' Lahn" <Po*********@we b.de> wrote: Where in this text would it make sense to store the charset of just the
snippet I am returning from the server.
Nowhere _in_ the text, that is, the message body. You should serve either
resource with the appropriate Content-Type _HTTP (message) header_ and
"charset" label as I suggested in my other followup. Due to the confusion
you display here about headers, it is probably a good idea if you learned
more about how HTTP works before; reading RFC2616 would be a good start.
I do know the difference between HTTP headers and the metatag charset
header. What I am not getting is what you are saying about how setting the
HTTP header for the server response will help in this case.
doug
Doug Lerner wrote: [...] "Thomas 'PointedEars' Lahn" [...] wrote: Where in this text would it make sense to store the charset of just the
snippet I am returning from the server.
Nowhere _in_ the text, that is, the message body. You should serve
either resource with the appropriate Content-Type _HTTP (message) header_
and "charset" label as I suggested in my other followup. Due to the
confusion you display here about headers, it is probably a good idea if
you learned more about how HTTP works before; reading RFC2616 would be a
good start.
I do know the difference between HTTP headers and the metatag charset
header.
Again, the latter is _not_ a header at all, and certainly not a "metatag
charset header".
What I am not getting is what you are saying about how setting the
HTTP header for the server response will help in this case.
Why, data should always be served as it is actually encoded. Until you
provide a test case (and not just screenshots), there is nothing more that
can be said about this.
PointedEars
On 1/20/06 12:04 PM, in article 25************* ***@PointedEars .de, "Thomas
'PointedEars' Lahn" <Po*********@we b.de> wrote: What I am not getting is what you are saying about how setting the
HTTP header for the server response will help in this case.
Why, data should always be served as it is actually encoded. Until you
provide a test case (and not just screenshots), there is nothing more that
can be said about this.
I can't provide a test case that you can actually use for testing unless you
had the same client/server setup I have, which is unlikely...
I understand what you are saying about data always being needing to be
served as it is encoded. And I also assume that there is an encoding/serving
mismatch here that is causing the problem. I am just not gleaning from what
you are writing how I might resolve the issue.
I do appreciate your taking the time and effort to respond, I am just not
following the suggestion.
In summary, once again, after I send the Japanese data to the server I can
log it there and if I examine the log via Safari I can see the data
correctly if I set the browser to force the character encoding to UTF-8.
So I am assuming that for some reason when sent via Safari the data is
turning into UTF-8. Or maybe that is happening when sent via all the
browsers, but the other browsers are just clever enough to compensate
regardless of the charset heading in the browser.
However, when the data comes back from the server I can't do the same trick
in Safari and force the page to reload with a UTF-8 character encoding to
see the characters correctly.
So... maybe something is happening to the characters on the way back to
Safari. Again, Firefox and IE are able to compensate for whatever is
happening.
But I don't know exactly what is happening, nor how to compensate for it in
Safari.
I do recognize that this is an encoding issue. I was just wondering if
somebody had some advice about how I might attack the problem.
Thanks!
doug
Doug Lerner wrote: [...] "Thomas 'PointedEars' Lahn" [...] wrote: What I am not getting is what you are saying about how setting the
HTTP header for the server response will help in this case.
Why, data should always be served as it is actually encoded. Until you
provide a test case (and not just screenshots), there is nothing more
that can be said about this.
I can't provide a test case that you can actually use for testing unless
you had the same client/server setup I have, which is unlikely...
You could at least provide for a test case, so that a KHTML user (like me)
could check if the encoding you use is the correct one and what might cause
the data to be transmitted garbled from your resource.
(I am sorry if this reads impatient, but I am quite tired and you provided
not much helpful information that could enable me to help you.)
In summary, once again, after I send the Japanese data
How were they input? How were they submitted?
to the server I can log it there
How is the log created server-side?
and if I examine the log via Safari
Is it a plain text file or does it contain code of a markup language? Do
you access the resource directly or do you access another resource that
retrieves the content from the log file indirectly?
I can see the data correctly if I set the browser to force the character
encoding to UTF-8.
The question is how you serve this resource.
So I am assuming that for some reason when sent via Safari the data is
turning into UTF-8.
Maybe. Maybe not. Unfortunately, my crystal ball is on vacation now.
Or maybe that is happening when sent via all the browsers, but the other
browsers are just clever enough to compensate regardless of the charset
heading in the browser.
Yes, it is possible that Safari does not follow HTTP/1.1 in that regard.
Which is why I suggested you checked the encoding of all resources and
made the meta[http-equiv="Content-Type"] `content' attribute value the
same as the Content-Type HTTP header (provided that it is correct) or
just omit the former.
However, when the data comes back from the server
What do you mean with "comes back from the server"?
I can't do the same trick in Safari and force the page to reload with a
UTF-8 character encoding to see the characters correctly.
Use <URL:http://livehttpheaders .mozdev.org/> to find out if you submitted
and served the correct headers, provided that you have no browser switch
server-side.
So... maybe something is happening to the characters on the way back to
Safari. Again, Firefox and IE are able to compensate for whatever is
happening.
Have you tried with Konqueror which is using KHTML and KJS, too?
Goodnight,
PointedEars
Doug Lerner wrote: But with Safari the Japanese seems to get corrupted.
Hard to describe in words, so here are some screenshots:
Correct (with Firefox): http://lerner.net/doug/jptext1.jpg
Corrupted (with Safari): http://lerner.net/doug/jptext2.jpg
Another note, if I look at the data logged at the server side, I can see it
correctly there even in Safari if I force the browser to UTF-8 encoding. So
it does seem that the data that gets sent through it somehow being converted
or something to UTF-8.
But forcing the client app I am working on to see the data coming back at
UTF-8 doesn't help.
This is the standard (if one can use such term in such situation) Latin
characadabra - where there are more Latin chars than original Japanese
ones. It means that browser refuses to interprete combo-chars (two or
more bytes) as one char and read them separately. I *can be deeply
wrong* but seems unrelated to JavaScript. Are you sure that your Safary
supports Japanese?
<http://redcocoon.org/cab/mysoft.html#sys anchor>
Can you view any Japanese sites? Try say <http://www.asahi.co.jp/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Daniel |
last post by:
I'm trying to make a site work for japanese characters. It works fine
except for the alerts in javascript.
The characters are stored in unicode, as this;
'コミック全巻配'
Those unicode characters are translated by the browser, but not in the
alert.
|
by: jemptymethod |
last post by:
http://htmatters.net/htm/1/2006/01/EIBTI-for-Javascript-explicit-is-better-than-implicit.cfm
|
by: petermichaux |
last post by:
Hi,
I've been reading the recent posts and older archives of
comp.lang.javascript and am surprised by the sentiments expressed about
the prototype.js library for a few reasons:
1) The library has been referred to as "junk" many times which is a
strong opinion against the relatively high popularity of the library. I
know popularity doesn't make something good.
|
by: petermichaux |
last post by:
Hi,
It seems like determining element position in a web page is a difficult
task. In the position reporting source code I've looked at there are
special fixes for at least some versions of Safari and Opera. I am
doing a lot of dragdrop experimentation and in some situations need a
position reporting function. The function doesn't need to report the
positions of exotic elements like images in button elements; however, I
would like a...
|
by: gg9h0st |
last post by:
function aa() {};
var bb = new aa();
var dd = new function cc() {};
aa.prototype.rr = 100;
cc.prototype.rr = 100;
---------------------------------------------------------------
| | |
by: DL |
last post by:
Hi,
Our school has an application in which :
- Teachers enter comments through a web interface built in asp (not
asp.net).
- Comments are stored in a SQL server 2000 (in a nText field)
- Comments are printed through a MS-Access 2002 front-end...
Most comments are in English, Spanish or French. Some comments are
English + Japanese.
|
by: gregerly |
last post by:
Ok, I've got an ajaxed calendar that lets users add their own events. This works great in Firefox and IE. In Safari however, i'm getting errors as the response text, instead of the success or failure message. My javascript is below:
submitButton.onclick=function(){
//set up all neccessary variables
var screenname=$F('screenname');
var month=$F('month');
var day=$F('day');
var year=$F('year');
var...
|
by: liketofindoutwhy |
last post by:
I am learning more and more Prototype and Script.aculo.us and got the
Bungee book... and wonder if I should get some books on jQuery (jQuery
in Action, and Learning jQuery) and start learning about it too?
Once I saw a website comparing Prototype to Java and jQuery to Ruby...
but now that I read more and more about Prototype, it is said that
Prototype actually came from Ruby on Rails development and the creator
of Prototype created it...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
