nsIProcess, Windows and Unicode

ViewSourceWith (VSW for friends) existence was impossible without nsIProcess, VSW must run programs and pass them at least one file name.

When arguments passed to nsIProcess are ASCII strings all works like a charm but you enter the hell if strings contain Unicode characters like those contained in Cyrillic or Japanese alphabets.

nsIProcess, especially under Microsoft Windows, doesn’t work very well with UTF-8 strings (see bugs 229379, 408923, 411511).

On VSW forum an user asked to me to fix the problem but it isn’t strictly related to VSW because the problem affects the XPCOM implementation.

After many attempts I surrendered and I decided to write my Win32 (Win64??) XPCOM component.

My IWinProcess has the same nsIProcess’s method signatures (Init, Run) but accepts wstrings and calls the unicode CreateProcessW Win32 API instead of its sibling CreateProcessA.

The Javascript caller (eg VSW) must pass UTF-8 strings but this is the only constraint.
Now finally I can open local files containing Unicode characters without tweaking the Windows ‘Regional Options’.

Linux seems to work fine (at least on my Gutsy box) simply converting Unicode strings with nsIScriptableUnicodeConverter.ConvertFromUnicode, no other special workarounds.

I don’t know if MacOSX works like Linux, I’m unable to test under Apple machines.

I don’t like code containing platform checks (if Windows … else if Linux … ) but to simplify VSW development the ‘if’ statement sounds reasonable.

The IWinProcess source and DLL are present on dafizilla SVN repository.

The next VSW release (0.4) will contain the IWinProcess component

Using UTF-8 with Apache and Jboss

I’ve found a strange problem with my first real UTF-8 web application…

The urls sent in GET didn’t decoded properly and I was very astonished, my code was written correctly but the problem was present.

BTW the problem wasn’t on my code but in Jboss (in Tomcat embedded instance).

The connector must have the attribute URIEncoding otherwise the webapp never will work.

Due to the fact I use mod_jk (ie AJP13 protocol) this lifesaver attribute must be added in AJP13 connector, too

I love when problems disappear modifing only a configuration file

For sanity check I’ve added UTF-8 support also in Apache Server but I suspect this isn’t really necessary

In http.conf be sure to have the AddDefaultCharset directive set as shown below

AddDefaultCharset utf-8