Plugin doesn't accept non-alphabet text

[cappazushi]

There is a plugin in use on my site that let's people input, via the profile section of the User CP, a status update. On their postbit, it will then display: "Currently Watching: _____" or "Currently Playing: _____"

However, this board is for Japanese learners, so we have a need for non-standard text. Unfortunately, the system rejects anything besides the alphabet, so Japanese/Chinese/Korean/Arabic/Russian is out.

Is there any special code that needs to go into a plugin before it can "read" foreign text.

Here's an example thread: http://jrpgclub.com/community/thread-34.html

Users whose postbit says "Currently Playing: ???" have not entered any text (that is the default display). Users that do input something will see their status appear on two lines:

"Currently Playing:
Tales of Innocence R"

Users with ??? on the second line have input Japanese text. The error I'm trying to fix is that it shows up as ? instead of the actual text.

Thank you in advance for your assistance.

[loveley]

Could you link to plugin? It's problem with encoding (encoding for accepting non-latin letters should be utf-8), quite possible you just need to change encoding for table column it uses.

[crazy4cs]

This user has been denied support.

What's the encoding of that particular plugin table (if it has)?

[cappazushi]

It's not a publicly available plugin. Shannon developed it for my site. Here are some threads that he posted to get some help with it (most of them contain the code).

http://community.mybb.com/thread-122290.html
http://community.mybb.com/thread-122035.html
http://community.mybb.com/thread-122087.html

[Omar G.]

I think he didn't defined a UTF-8 encoding type for the table. I think you can go directly go to phpMyAdmin (or the system you use) and edit the table properties, but no sure TBH. You can adventure yourself on it

[Dannymh]

As said above. You need to check two things

1 - The character encoding of the database, and more specifically the tables that this plugin uses
2 - The page encoding

It looks like your pages using UTF-8 (<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />)
So it *should be fine. I say *should, because UTF-8 does have some issues with Japanese, it's a never ending bugbear on our Java development.

At a guess you are likely using an iso character encoding for those tables, and depending on the one you are using, that does not like japanese character sets. Simply because japanese is a multi-byte language whereas English is not, so you will likely see issues like Japanese text showing up as things like question marks etc.

So how do you check what the character encoding is?

Login to phpMyAdmin and go to the table in question, and go to the table structure view, Scroll down the bottom and you will see

Format 	dynamic
Collation 	utf8_general_ci
Rows 	2
Row length ø 	100
Row size ø 	1,124 B
Next Autoindex 	3
Creation 	Jul 30, 2012 at 04:40 PM
Last update 	Aug 03, 2012 at 03:51 PM
Open new phpMyAdmin window 

The collation line is the one we are looking for (we could query for this)

Anyway there are also some issues with mysql, UTF-8 and Japanese character sets. So another question I have for you is.

- Is the data actually being stored correctly when you look at it via phpmyAdmin?
- If so, try changing the plugin to run

SET NAMES 'utf8'

before doing the results query so something like

$query = $db->query("set names 'utf8'");
$result = mysql_query($query);

$query = $db->query("select * from mybb_user_status";

You'll need to play with that as it's very quick rough code, but that basically forces the database to select and switch to UTF-8 but is a moot point if the data is not being stored correctly.

---

To change the encoding on the actual table you simply go to

phpmyadmin >> database >> Your Table >> operations

select the encoding you want (There are ones specific to Japanese, but you want a mixed mode one instead) and then hit save. Depending on the size of your table and data in there this should be pretty quick.

I would analyze, optimize and repair the table after this as well for safe measure, and if it has any heavy indexes, I would suggest a re-index, but I would say this table is fairly light weight so the re-index probably isn't needed

[cappazushi]

I changed the encoding in the table, and it's working perfectly now. Thank you!