[Static]

Where exactly are you getting the question marks?

Try editing the comment from within phpMyAdmin (if you have it).

I only tried changing the comment collation.

---

Is the file encoded in UTF-8 without BOM? I take it that you have N++ from the installation page. It's easy to check the encoding in it. The encoding in mine was UTF-8 from the start so I didn't need to change that.

[Steven]

If I add Chinese characters into the comment directly in phpMyAdmin then it displays fine.

It just doesn't process and store it properly.

The question marks just appear randomly within the text. There are also some fractions in there such as 1/4 and 1/2.

I tried adding this at the top of my page but made no difference:

PHP Code:

<?php 

header('Content-Type: text/html; charset=UTF-8');

mb_internal_encoding('UTF-8'); 

[Static]

So it works, unless it's from posts. I'll take a look at it when I make the comments work again (I broke it somehow, but it's unrelated to this. I was modifying some things.).

[Steven]

So it works, unless it's from posts.

That's right.

Same problem in IE as well as Firefox.

[Steven]

Got it working!

In the sanitize function, changed:

PHP Code:

<?php 

$entry = htmlentities($entry, ENT_NOQUOTES); 

[Static]

I knew it was in the sanitize function! I was trying to fix my code to see if my solution would work, but I just got into a bigger mess. Congratulations!

[Steven]

Thanks, and thanks for your help, I just have a couple of questions:

1. If I change Commentics to only be utf-8, will it have any adverse affects on users who want to use iso? Do you think it should be an optional choice during installation?

2. During upgrade to v1.1, should I attempt to convert database tables to utf-8. If the tables aren't converted would there be any big problems?

[Static]

1. AFAIK the only adverse affect it would have is that their font falls to a fallback font if it doesn't support a certain character. Also, if a user only wants to support one language, then they will need to use ISO. UTF-8 is great because it's very compatible.

2. Only some tables need to be converted. The comment table is the most important one to be converted, and the only one that needs to be converted if the user only wants the comments to be unicode. Most other tables are good to be converted if you plan on supporting translations. If you don't convert, I think that the only problem will be question marks for unsupported characters.

Try Googling something about this just to be sure.

Google Link: http://www.google.com/search?hl=en&sourc...oEBU_QLE-r

[Steven]

Looks like I have a few decisions to make

Hopefully this won't delay the v1.1 release.

I'm really glad anyway that utf-8 seems to be sorted.

[Static]

This list might help you decide which rows in the DB will need changing:

• banned -> reason (translation)
  
• comments->name (multilingual support)
  
• comments->town/country (translation)
  
• comments->comment (multilingual support and special characters ♞)
  
• comments->approval_reasoning (multilingual support)
  
• comments->custom_page_id (multilingual, when v1.1 released)
  
• pages->reference (multilingual)
  
• pages->custom_id (multilingual, when v1.1 released)
  
• questions->question (multilingual)
  
• questions->answer (multilingual)
  
• admin->username (multilingual)
  
• admin->defaults (multilingual)
  
• subscribers->name (multilingual)
  
• subscribers->custom_page_id (multilingual, when v1.1 released)
  

Hope that helps a little.