request.pl script has probably some flaws
Hi, there probably is a certain irregularity in the return.pl script. Could anyone check why charset (in spite of being correctly displayed in a browser source window as, in my case utf-8) defaults to iso-8859-1. Character encoding on a browser pulldown menu switches to iso-8859-1, although in the source window it is what it has been set to through include file probably. It doesn't happen to other windows (templates). thanks a lot. Benedict
I made a mistake in the body of the message: return.pl should be request.pl
On 2004-02-28 15:32:36 +0000 Benedykt P. Barszcz <kb2qzv@poczta.wp.pl> wrote:
Could anyone check why charset (in spite of being correctly displayed in a browser source window as, in my case utf-8) defaults to iso-8859-1.
What character set does "Page info" say? What does lynx -head URLofthatwindow say? I suspect the HTTP header is saying iso-8859-1, but ICBW.
In article <841e06824437f73bb7c8782ac26e0e2a@bouncing.localnet>, MJ Ray <mjr@dsl.pipex.com> wrote:
On 2004-02-28 15:32:36 +0000 Benedykt P. Barszcz <kb2qzv@poczta.wp.pl> wrote:
Could anyone check why charset (in spite of being correctly displayed in a browser source window as, in my case utf-8) defaults to iso-8859-1.
What character set does "Page info" say? What does lynx -head URLofthatwindow say? I suspect the HTTP header is saying iso-8859-1, but ICBW.
request.pl was not sending out the correct charset. (It did not call any "charset guessing" functions in C4::Interface::CGI::Output.pm) I think I fixed it now. Please double-check. -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org> http://ada.dhs.org/~acli/
participants (3)
-
Ambrose LI <acli＠ada.dhs.org> via forwarder -
Benedykt P. Barszcz -
MJ Ray