PDA

View Full Version : Dynamic IFrame and Charset



emi
05-07-2008, 01:15 PM
Hi every body!!
I'm creating an application that uses JavaScript, AJAX and IFrames. A complete example is when you mouseover for a while on an element to see its popup: it sends a HTTPRequest and writes it response to a dynamically generated IFrame. It's something like:



var if = document.createElement('iframe');
if.src='about:blank';
// here I use another func that tells which is the document, depending on
// browser type and version, using object detection
var doc = getDocument(if);
doc.write(content);
doc.close();


My problem is that charset is not set correctly: it has UTF-8 and I want it to be iso-8859-1. I've tried with META inside the HEAD of the HTTPResponse, adding this META dynamically to HEAD, adding charset='iso-8859-1' to the script tag, modifying document.characterSet (but it's readonly) and adding Accept-Charset to HTTPRequest header. None of these actions gave me the desired result.:mad:

Some info that may help to help me ;) is that, in other process than informational popup (ie, editing the element), there is the same problem, but when you submit the form to see the confirmation page, it has the correct charset. The form is targeted to the same IFrame and there is no Javascript linked to the submit event.

æAny idea on this issue? As you can see, I've been looking for a solution in different ways, also with an intensive googling. But I couldn't find anything. Neither related problems on forums nor blogs. It seems as I'm the first having this problem... I can't believe it!! :eek:

Ah! The solution may not include to change the AJAX+IFrame process to a IFrame-only based system. :(

Thanks a lot in advance!

emi

jscheuer1
05-07-2008, 01:33 PM
change the AJAX+IFrame process to a IFrame-only based system.

That would be the simplest, as your experience already shows. If you have control over the server or just access to a method (like .htaccess) that can set a few things for a site or a directory, you could direct the server to serve the files as whatever character set you please.

Without that, you could try using character entities to represent the non-standard characters.

emi
05-07-2008, 01:35 PM
I have access to apache. What do you say I can test?

thanks for speed, John!

emi
05-07-2008, 01:42 PM
Thanks a looooot!!!!
I added DefaultCharset iso-8859-1 and restarted apache2.

It worked!!

jscheuer1
05-07-2008, 01:46 PM
I don't understand your question. I didn't really say to 'test' anything. Except perhaps when I said:


Without that, you could try using character entities to represent the non-standard characters.

Is that what you are asking about? For example, if the copyright symbol is giving you problems, use:


©

instead. All characters that are outside a character set's repertoire can usually be represented by named or numbered entities. If the import is via text, these will usually be preserved as entities and then interpreted according to the 'top' page's encoding. However, since you are using an iframe, that might not work, as the iframe is technically its own window. So, you might consider importing directly to the document and abandoning the iframe except for when it comes time to submit the form.

emi
05-07-2008, 01:51 PM
I know, but I'm not able to change tons of code (more than 400 000 lines plus data in DB) to print characters as their HTML code.

HTTP server side changes were very well.

What I don't understand is why just this IFrame went into a bad charset. All other IFrames were ok.

Thanks, john!

emi
05-07-2008, 02:02 PM
Ummhhhh....
I've been testing it a little bit more and I found another issue... bug:
It shows ok special characters, but it still have UTF8 as chrset on its document attribute. And you get strange behaviour when you submit the form having wrote some special characters inside form elements. So, text is shown with iso-8559-1 charset, but INPUT form elements get info with UTF8. :confused:

Strange....

jscheuer1
05-07-2008, 02:20 PM
Well, if you are sending a request to the server using javascript, it will serve the page as it has been requested, which is limited to an extent by the capabilities of the browser. Mozilla (FF and others), and some other browsers can specify mime type and encoding in the request, IE cannot. So you get the server's default encoding for the data type being requested.

There are various ways this can be set on a server. It goes by the file extension of the page being requested. Whole pages served to the browser in the normal way can often override this setting with their meta content tag. Servers can override this feature, but most do not.

Making an HTTP request to an iframe gives you even less control (on the client side) over the outcome, as page headers (DOCTYPE and the entire head section in HTML) are generally ignored by the server in this type of request, and when included are ignored by the browser, as the page already has a head section.

If you did have the proper meta content tag in the head of your requested document, it might trigger the browser's selection of character set once the document was loaded into the iframe, but I wouldn't count on it, and it sounds like you already tried that without success.

Now, when you ask:


What I don't understand is why just this IFrame went into a bad charset. All other IFrames were ok.

Do you mean that other iframes filled via AJAX are not giving you this trouble?

emi
05-07-2008, 02:24 PM
Do you mean that other iframes filled via AJAX are not giving you this trouble?
Not really. They are filled up with Javascript, but not AJAX.

jscheuer1
05-07-2008, 02:37 PM
If you've encoded the pages properly using the meta tag then and that still doesn't work, try setting the default encoding on the server for that file type.

emi
05-07-2008, 02:43 PM
try setting the default encoding on the server for that file type.
It's already done.

jscheuer1
05-07-2008, 02:45 PM
It's already done.

Done as in fixed?

emi
05-07-2008, 02:50 PM
If you've encoded the pages properly using the meta tag then and that still doesn't work, try setting the default encoding on the server for that file type.

I've already done both and it's still not working....:confused:

jscheuer1
05-07-2008, 06:00 PM
Once the encoding is properly set on the server side, there is not much more that you can do. To make sure that you have set it properly, make up a test page with no meta tags on it. Give it the extension you have set on the server for iso-8559-1 charset and put some characters on it that will mess up in UTF-8. Upload it and view it directly in the browser. If you've set it properly on the server, the characters will look like the do in iso-8559-1.

If that's working, make sure that your request is for txt/html with no attempt to change the mime type or encoding. Beyond that, there is nothing more you can do, it simply will not work - although I'd want a link to both the test page and to the page with an iframe that demonstrates the problem, so I could check it all out, just to be sure.

emi
05-07-2008, 07:15 PM
Once the encoding is properly set on the server side, there is not much more that you can do. To make sure that you have set it properly, make up a test page with no meta tags on it. Give it the extension you have set on the server for iso-8559-1 charset and put some characters on it that will mess up in UTF-8. Upload it and view it directly in the browser. If you've set it properly on the server, the characters will look like the do in iso-8559-1.

If that's working, make sure that your request is for txt/html with no attempt to change the mime type or encoding. Beyond that, there is nothing more you can do, it simply will not work - although I'd want a link to both the test page and to the page with an iframe that demonstrates the problem, so I could check it all out, just to be sure.

Hi again, John!
Well, it seems I can't do much more. Apropos to the link, well, it's an Internal Area with sensible data. I've made an special user for you, guest, with same pswd as user. This user will only be active today. The application test page is at:

https://algorismia.cio.cat
https://algorismia.cio.cat/TestCharset.html

Note: Despite language. It's in catalan or spanish. English will come when client demand it. :rolleyes:

Note2: I've tried with Opera, and it works fine. May be it'a a FF bug. I can't try w IE-- No M$ on my server, plz!

jscheuer1
05-08-2008, 08:24 AM
I logged on, and not knowing precisely what to look for, was unable to find any obvious iframe, or any obvious character dropout in FF. Perhaps it has been fixed, but you've been viewing a cached copy of your pages in FF. The charset encoding from the server is correct, but even with iso-8559-1 being served, the euro symbol only worked when represented as an entity. This was the same in both Opera and FF. I didn't think to test in IE, if it hasn't expired yet I will. Generally IE is more forgiving of mime type in iframe, so one would hope it would be generous with charset as well. In an unrelated matter, your security cert is expired.

I did see this every time after logging in:

No estąs autoritzat a fer servir cap nivell

Not sure if that meant my temporary account had already expired. I clicked on the large tilted A and was able to view some various tabbed content.