Update to website not printing special Characters

I thought you might be interested in how far I have got with solving my problem with MySql(via phpMyAdmin) to website character_set problems.

I thought I had solved the problem when my characters on my website started showing the special characters.

This was a partial success though.

When I went back to phpMyAdmin and entered new text the problem was the same, but reversed. What now happens is that the original text I typed is now converted to gibberish(Latin1 to UTF8)

and new text entered, in phpMyAdmin, is output to website as "?" again See:-

http://donsgarden.co.uk/pests/228?telephone=2

What I did, as I could not change the server Craracter_set and Collation (Shared Server). I got my host to change everything back to Latin1. I was going to change my w/site meta line to ISO 8859-1. From connecting to my database via ssh I got:-

If the only remaining problem is phpmyadmin then a better solution may be to provide some simple admin pages on your website for entering the data, and forget about phpmyadmin.

Colin

Don Mapp wrote:

I thought you might be interested in how far I have got with solving my problem with MySql(via phpMyAdmin) to website character_set problems.

Why did you start a new thread and make it harder to refer to the original problem?

For reference, the old thread is at Printing special characters on screen in Ruby - Rails - Ruby-Forum .

I thought I had solved the problem when my characters on my website started showing the special characters.

This was a partial success though.

When I went back to phpMyAdmin and entered new text the problem was the same, but reversed. What now happens is that the original text I typed is now converted to gibberish(Latin1 to UTF8)

UTF8 is what you want to be using.

and new text entered, in phpMyAdmin, is output to website as "?" again See:-

http://donsgarden.co.uk/pests/228?telephone=2

What I did, as I could not change the server Craracter_set and Collation (Shared Server). I got my host to change everything back to Latin1.

Wait, wait, wait, wait. Why are you using a shared host (not generally a great idea for Rails)? Worse, why are you using a host that doesn't let you change your own DB charset settings? Even shared hosting should let you do that. If not, find another hosting provider.

I was going to change my w/site meta line to ISO 8859-1.

From connecting to my database via ssh I got:-

> show variables like 'c%'; +--------------------------+----------------------------+ > Variable_name | Value | +--------------------------+----------------------------+ > character_set_client | latin1 | > character_set_connection | latin1 | > character_set_database | latin1 > > character_set_filesystem | binary > > character_set_results | latin1 | > character_set_server | latin1 | > character_set_system | utf8 | > character_sets_dir | /usr/share/mysql/charsets/ | > collation_connection | latin1_swedish_ci > > collation_database | latin1_swedish_ci > > collation_server | latin1_swedish_ci | > completion_type | 0 | > concurrent_insert | 1 | > connect_timeout | 10 | +--------------------------+----------------------------+ 14 rows in set (0.00 sec)

Great I thought, but when I use phpMyAdmin to issue the same command I got:-

show variables like 'c%';

Variable_name Value character_set_client utf8 character_set_connection utf8 character_set_database latin1 character_set_filesystem binary character_set_results utf8 character_set_server latin1 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/ collation_connection utf8_general_ci collation_database latin1_swedish_ci collation_server latin1_swedish_ci completion_type 0 concurrent_insert 1 connect_timeout 10

Yuck! That's really inconsistent. Change it all to UTF-8.

Perhaps when I sort this out I will reach my ultimate goal of entering text in phpMyAdmin and having it displayed on my website correctly.

I agree with Colin -- don't worry too much about phpMyAdmin. Worry about the actual DB. If you want to build an admin tool quickly, try ActiveScaffold.

And follow the advice in the older thread. It will stand you in better stead than what you've actually done.

Many thanks for all the help it has got me this far and now I have hope I will solve the problem in the end.

You will -- if you actually *take* the advice given to you. :slight_smile:

Don

Best,

Thanks guys for all the support and advice. Yep I would have preferred to use UFT8 and if I did do another ROR project I would do it differently, But having started learning ROR a few years ago I have gradually built up the website piecemeal. And At the mo I am still a relative newbie and sometimes it is better the devil you know. One day when I have time I will re-write the whole project and look for a different host. Ruby 1.9.2 and Ruby on Rails 3 beckon soon. I still think 1.9.2 needs a little settling down. Anyway now I am this far I want to solve this the hard way. That way I will learn so much more about these various technologies. Don

Thanks Colin That's what my son is hitting me over the head with. He dosn't want to help as he said I should have used ROR to enter the data, which should have avoided all these problems. Mind you If I had done that I would not have learned so much about Encoding. When I re-write in ROR 3 and Ruby 1.9.x I plan to do that. Don

Please quote when replying. The discussion is hard to follow if you don't.

Don Mapp wrote:

Thanks guys for all the support and advice. Yep I would have preferred to use UFT8

Then do! Convert what data you have that's encoded differently (iconv is your friend), and switch completely to UTF-8 (not UFT8).

[...]

Anyway now I am this far I want to solve this the hard way.

What do you consider to be the hard way? Often the hard way is actually the wrong way. If it's not easy, you're usually doing something wrong.

That way I will learn so much more about these various technologies. Don

Best,