Russian/Japanese Encoding Issues

[♥zelf]

I've seen a couple of threads on this encoding business, but I do not understanding how to fix this.

 

On admin/orders.php when viewing an order from a non USA customer the customer, shipping, and billing addresses look like the following (example is a Russian address (without spaces after "#")):

 

( 1059; 1080; 1085; 1089; 1082; 1072; 11

Perm ( 1055; 1077; 1088; 108, 614051

Permskaya ( 1055; 1077; 1088;, Russian Federation

How do I get Russian characters to display in Russian, Japanese characters to display in Japanese, so I can correctly address shipping labels?

[♥zelf]

More Info:

 

My server is running Apache 1.3 and has uncommented:

 

AddLanguage ru .ru

AddLanguage ja .ja

 

It also has uncommented:

 

AddCharset WINDOWS-1251

AddCharset Big5

AddCharset CP866

AddCharset ISO-8859-5

AddCharset KOI8-R

AddCharset UCS-2

AddCharset UCS-4

AddCharset UTF-8

[Guest]

its probably because the iso is 8859 you could try setting encoding of the page to utf-8.

[♥zelf]

try setting encoding of the page to utf-8.

How do I do that? Probably a totally stupid question, but where do I do that. I tried it through Firefox "View Encoding", but it still looks like gibberish. I noticed in this forum that if I did not put the space after the "#" that it would translate the characters. So is it in PHP that I do this? Where?

[Guest]

well first do a test to see if it works. Once on that page with the incorrect chars, do view source, save the page. Then edit it at the top should show 8859. change it to utf-8 and run the page to see if the chars appear correctly. If so, you change the english.php on the admin side to utf-8. But I don't know about the side effects of such mod.

[♥zelf]

change it to utf-8

Didn't work.

 

If you look at the source of this forum it is using "charset=iso-8859-1".

 

Now why does this forum translate " 1080;" correctly into "и"?

[Guest]

well do something else. Goto your phpmyadmin browse the customer and address_book tables and see how the columns are stored. You should see the russian characters there.

[♥zelf]

Solved the problem in admin/includes/functions/general.php. Hopefully this helps someone else because I couldn't find one thread that addressed the problem that made sense.

1. Changed the following lines in the tep_address_format function
    
   FROM
   

   $street = tep_output_string_protected($address['street_address']);
   $suburb = tep_output_string_protected($address['suburb']);
   $city = tep_output_string_protected($address['city']);
   $state = tep_output_string_protected($address['state']);

   TO
   

   $street = $address['street_address'];
   $suburb = $address['suburb'];
   $city = $address['city'];
   $state = $address['state'];

   
    
   

2. In mysql address_book table changed varchar on street_address to 250 since the database is storing the Ascii? code for these characters.
   

I have not seen any adverse effects from doing this yet. Both US and Non US characters display correctly now.

[♥zelf]

The following also works, which may be the more correct way to do it. Although I can't see where my first solution has broken anything in Admin. I wish I could say definitively why this has fixed the problem. It really bugs me that I can't, but that is due to a lack of understanding when it comes to encoding and browser rendering of ascii characters. I'll have to study up on it. Clearly it has something to do with the the htmlspecialchars php function in the tep_output_string, which is called when calling tep_output_string_protected. My code below simply tells tep_output_string function to not return special characters converted.

 

$street = tep_output_string($address['street_address'], false, false);
$suburb = tep_output_string($address['suburb'], false, false);
$city = tep_output_string($address['city'], false, false);
$state = tep_output_string($address['state'], false, false);