Displaying £ signs 1

[audiopro]

I am having problems on a particular domain with displaying £ signs.
I believe it is a server issue but the ISP assures me that their servers are working fine.
I have 2 domains with this ISP and one displays £ signs OK but the other one doesn't.
On every other server I have ever used

#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
use warnings;
use strict;
use CGI;
use DBI;
print "Content-type: text/html\n\n";	# prepare for HTML output
print "£<br>";

prints a £ sign no problem.
On one particular server it prints a square box.
In every case, it is printing character 163 but why should there be a difference unless something on the server is different?

Keith

http://www.studiosoft.co.uk

 

[feherke]

Hi

Maybe that particular web server adds a charset that not matches your script's charset. For example in Apache the [tt]AddDefaultCharset[/tt] forces the inclusion of a specified charset name when the [tt]Content-type[/tt] HTTP response header specifies text/plain or text/html without charset. So try to specify it explicitly :

[b][COLOR=#000000]print[/color][/b] [i][COLOR=#009900]"Content-type: text/html[highlight]; charset=utf-8[/highlight]\n\n"[/color][/i][COLOR=#008080];[/color]	[COLOR=#808080]# prepare for HTML output[/color]

Or another possibility to try to turn off the addition of default charset :

[b]AddDefaultCharset[/b] Off

Feherke.
feherke.ga

 

[audiopro]

I have tried all of the above and a lot more besides, ie. specifying the charset in the htaccess.

My main gripe is that none of this witchcraft should be necessary as by default a £ should be displayed as a £. It has been this way on all the shared hosting and virtual servers I have had dealings with.
The Help desk at the ISP have resorted to Google to find a solution - it would be laughable if it hadn't taken them many weeks to get to this point and one fix they suggested was to add the following code to the declarations in the Perl file.

use open ( ":encoding(UTF-8)", ":std" );

In the working script, as opposed to the simple test example above, I read content from a text file and all £ signs are converted to diamonds with question marks in them. After adding the encoding declaration above, all £ signs were converted to their HEX equivalent.



Keith

http://www.studiosoft.co.uk

 

[audiopro]

After further tests I can confirm it is not a Perl issue.
The simple task of downloading a text file, containing £'s, results in different displays on the 2 servers.


Keith

http://www.studiosoft.co.uk

 

[feherke]

Hi

Can you post the HTTP response headers sent to the browser ?

Feherke.
feherke.ga

 

[audiopro]

Not sure if this is the correct info but I got them from an online tool.
Is there a better way to capture them?

HTTP/1.1 200 OK   
  Date: Fri, 11 Jul 2014 09:05:17 GMT   
  Server: Apache/2.2.15 (CentOS)   
  Last-Modified: Sat, 05 Jul 2014 08:28:07 GMT   
  ETag: "5d3704-49f-4fd6e057ab444"   
  Accept-Ranges: bytes   
  Content-Length: 1183   
  Connection: close   
  Content-Type: text/plain; charset=UTF-8

Keith

http://www.studiosoft.co.uk

 

[feherke]

Hi

Interesting. If the file is indeed UTF-8 [sup](*)[/sup], then it should be served correctly with this header.

[small](*) I usually open the file with Yudit and if it looks correctly, it is certainly unicode.[/small]

Not sure if this is the correct info but I got them from an online tool.

Is there a better way to capture them?

Should be Ok that way too. I prefer local tools. What I used so far :
[ul]
[li]Browser:[ul]
[li]FireFox:[ul]
[li]Live HTTP Headers[/li]
[li]FireBug[/li]
[li]Web Developer[/li]
[/ul][/li]
[li]Lynx[/li]
[li]Links[/li]
[li]W3M[/li]
[li]Explorer:[ul]
[li]ieHTTPHeaders[/li]
[li]IEWatch[/li]
[/ul][/li][/ul][/li]
[li]tool:[ul]
[li]netcat[/li]
[li]PuTTY[/li]
[li]telnet[/li]
[li]Wget[/li]
[li]cURL[/li]
[/ul][/li][/ul]


Feherke.
feherke.ga

 

[audiopro]

I can't mess with this any more so I have changed all incoming chr(163)'s into the £ entities.
I find it strange that this new server supplied by a UK ISP cannot display £ signs by default.
Is this problem with £ signs widespread and I have just been lucky so far or is this ISP simply worth avoiding?

Keith

http://www.studiosoft.co.uk

 

[audiopro]

Adding a default charset to the .htaccess file has meant that ordinary web pages display £ signs correctly.
Reading the contents of the same web pages via a script in the cgi-bin corrupts the file.
Is it possible that the charset of the cgi-bin is somehow set to an unchangeable value?


Keith

http://www.studiosoft.co.uk

 

[1DMF]

I don't suppose the data is coming from MS SQL Server is it?

Unicode data from MS SQL and DBI don't mix well and you have to encode them using codepage 1252

my $unicode = encode("cp1252", $my_dbi_data);

I spent a lot of time liaising with DBD::ODBC maintainer of the DBI project as I had a whole host of corrupt chars when outputting MS SQL to the browser direct from DBI before encoding it.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

The data is being read from a text file into a Perl script.
If I link directly to the text file from a browser, it displays the pound signs as boxes.
I tried saving the same file to a few other directories and sometimes it displays £ signs and other times it displays the boxes.
All this has become irrelevant as my client has made the decision to leave this ISP, not before time in my opinion.

Keith

http://www.studiosoft.co.uk

 

[1DMF]

now worries, I just saw the use of DBI in the code and wanted to cover all bases.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

Thanks - I had to laugh this morning as in one of the replies in the ISP's support ticket, on their own website, £ signs appear as odd symbols there too.

It seems that the problem is greater than they thought, in fact, I don't think they realised they had a problem.

Keith

http://www.studiosoft.co.uk

 

[tchatzi]

it looks like you should check your server's locale and regenerate it with locale-gen maybe to something like en_US.UTF-8 or the equivalent for GB but the UTF-8 one. Then you should restart your web and db servers. all these of course if you have ssh access on your server.
Perl internal does not realy care about the encoding of your data. So perl is never the problem.

``The wise man doesn't give the right answers,
he poses the right questions.''
TIMTOWTDI

 

[audiopro]

This was shared access with an ISP who claim to be one of the best in the country. I have been with them for a good number of years and in that time I have seen them deteriorate to a level which I find unacceptable. This issue is not an isolated incident and we have had a catalogue of disasters over the last 12 months which has forced us to move all of our sites to another ISP, a lot of work but necessary as I personally have been spending far too much time fixing things which should just work.



Keith

http://www.studiosoft.co.uk

 

[1DMF]

I know that feeling Keith, I have just had to move provider of our POP3 mailbox hosting service, as the company I have been with for many, many years has gone seriously downhill, to the point they don't even respond to support emails anymore. I've been trialling one member on the new host provider, and so far so good. Like you say it's a lot of work to move everyone over, but necessary as we couldn't carry on with a host company who's service has become unreliable and support unreachable.

I have also had to move all members using the POP3 service onto a new DNS provider as the domain registrar was getting put on an RBL spam list every other day!

I'm sure you are like me, and have far more important things to be spending your time on other than chasing unreliable service providers who aren't providing the service you pay for!



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

We could easily be talking about the same company although to be fair they haven't stopped offering support, they were taking up to 2 days to respond and then offering no useful assistance at all.
I feel sorry for any customers of theirs who are new to the game and do not know when the are being spun a yarn.


Keith

http://www.studiosoft.co.uk