1.) Is the problem in the Windows OCSNG agent, or: 2.) Is the problem in the UNIX OCSNG server, or: 3.) Both?
So, let us begin the delightful process of debugging multibyte foreign language bugs in unsupported open-source software! Um, yee haw?
A cursory google finds a useful thread wherein some Russians were having a similar issue, and then some ppl chimed in with Japanese as well. A proj admin, hunal, said on 2007-7-17 that "full utf8 support is in the roadmap" but months later ppl were still having the probs. INTERESTING: thread contains potential server-side patch.
IMPORTANT: it looks like OCSNG creates its database in MySQL which is not in UTF-8!!!! Tremendously foul. (Update: Now I have looked at the SQL, and it simply doesn't specify any encoding... which with MySQL means it is pretty arbitrary what encoding gets used. I would have assumed that OCSNG, agent software that collects local system info from a huge number of legacy Windows machines and then uploads the data to a remote server, would be one of the most paranoid applications with regard to text encoding issues... but I would be very wrong.) That means, we probably have to recreate the database along with any fix we do. (I mean, since we only have test data in it so far, that would probably be easiest...)
Hmm, it would be good to check into the background of this issue and see who suffers from it, and what if anything is being done about it:
ï 2007-05: jjroot reports the issue, and some things they did, including recompile MySQL (really? blecch!), in a post that reads like a deranged patent application ("2. Method of fixing event that agent of Windows vomits with UTF-8" LOL). They are also interested in getting the OCS web GUI to display correct Japanese, but I don't care about that, as I'm using the really-pretty-fucking-awesome GLPI for my admin frontend, and I just want OCS to populate the database with correct non-fucked-up data (i.e., UTF8 text). I don't care where we fix it -- fine with me if we get the "vomit" data from the Windows agent, if we can convert it to UTF-8 before writing it to the db. I hope? Anyway the answer in this thread was "yah we know we will try to fix it ASAP but probably won't since it is hard". (But come on, how hard could it really be??)
• 2007-05: Problems with Chinese clients, too (of course).
• 2007-10: A user reports this issue in the forum. Another user chimes in, me too.
• 2008-01: User asks what is up with UTF-8 support, but no answer.
• 2008-01: More Chinese problems. No solutions, though.
• 2008-03-27: a user has this problem, and hunal replies again that UTF8 support is in the roadmap.
ï 2008-11: This issue is reported, and the user is referred to the Russian thread above. Waiting for new version.
OK, so what have we learned? Well, that the problem is widespread, has been known about for a long time, and not fixed. When I peek at the road map, it is not encouraging at all. There is nothing about fixing this in the agent, only "[GUI] Unicode usage" hoped for for 1.2 (currently it is at 1.02RC3).
The GUI for OCS is pretty abysmal, anyway, and the smart people I know use GLPI to admin their IT fleets, and OCS just for the agent features.
So now, we are faced with that typical open-source conundrum:
Do we a.) try to hack this crap and kludge a solution together, or b.) throw it in the trash and write our own solution from scratch?
As usual, option B is the much more enticing, but A is probably the right solution when being paid for the work. But... but... good god, man, this thing is written in fucking perl! Nooooooooooo......
More as the situation develops...
(Yes, that's right. I wrote this whole tantalizing piece that you found on Google, and after reading the summary you were all like, "Oh,right on dude, this guy's gonna have the fix for this heinous problem we're having, cool," and then now you got here, to the bottom of the post, and you're all like, "What man, after all that reading, you are just giving up for the day and going home? Hey, fuck you, man!! What an asshole!")