I'm working on an InSim and used to store data via a PHP webservice through C#. I would post data to the .php file and retrieve data as well. This obviously is not really efficient, so I've moved to a remote MySQL (my host does not have a database to use) database to store data.

When I retrieve players with special characters in their names something weird is happening.

In the database it's saved as: ^5★^7BattleStar. When I paste the above text in a /msg or whatever it shows the correct name. However, when I retrieve the data from the database and show it in LFS it goes wrong. Check the attachment to see what I mean:



The name is saved from the previous method where I posted to a PHP file, which then inserted it in the database. When I retrieved it with the database - > php -> insim method it showed fine. However, when I now try via the database -> insim method, it shows it differently.

I execute my query and then put it in a MySQLDataReader:


and show the record with this in a while loop:

The Database is in UTF8 charset, and also when connecting to the MySQL database (via the connector from MySQL), I have set the CharSet=utf8. I've tried pretty much all Encoding settings, but I just can't figure out how to solve this.

It seems like the output is the same as the actual database record if you look in plain text, instead of it being the star (in this case) that LFS has. This goes for all special characters. Normal characters work fine.

Does anyone have an idea?

I assume the character you are going for is 'BLACK STAR' (U+2605)? As far as I know the only codepage supported by LFS that contains this character is CP950 and C949 for Traditional and Simplified Chinese respectively.

LFS does not support any form of Unicode encoding so saving the text in the database as UTF-8 encoded string is IMO not a good idea. You should be using a raw byte array instead - that way you can avoid a lot of problems that stem from converting text from one encoding to another. When you send text to LFS via InSim, everything is assumed to be in CP1252 AFAIK. The special character "^" (0x5E in CP1252) then tells LFS to use a different encoding for the part of the string from the "^" character onward. There is no "switch to another encoding" command in your string which is why the characters are displayed as if they were in CP1252 instead of whatever encoding you actually want to use.