There is a problem in the IKVM virtual machine wherein it does not support the shift_jis codepage. Michael Kay had posted about the problem at the link below:
Another person had a similar problem here:
I am wondering whether this issue has been resolved yet as it makes it difficult to use SAXON in Asian development environments. Any information greatly appreciated.
Jeroen on the IKVM group says:
"Sorry to be pedantic(*), but this is not a problem with the "virtual machine". The class library that ships with IKVM simply doesn't include the encodings
I have no intention of fixing this for 0.36, because it is relatively easy to run charsets.jar through ikvmc and add it to the system class loader (by having
you main .exe reference the assembly).
The recent 0.37 development snapshots do include all the character encodings that are included with OpenJDK6 and the 0.38 release will also include them."
I am currently trying to build Saxon 8.9.4 (a bit of a challenge since I am missing a file called saxondotnet.snk). I guess at that point I can either put charsets.jar into the Java compilation step or the charsets.dll I build with ikvmc into the .NET compilation step, and pray.
The reason we're using 8.9.4 is that we use .NET 1.1 and I think Saxon 9 moves on to .NET 2.0.
I'm not sure whether any work will end up being necessary in Saxon itself, since presumably when IKVM 0.38 comes out people can just upgrade to that. In the meantime life is exciting...
I'll look at whether it's possible to fix this in a maintenance release using the approach Jeroen suggested. But this will only be for 9.1.
Although 9.1 is tested primarily using .NET 2.0, I didn't do anything consciously to stop it working under .NET 1.1 and it may be worth trying it out.
The .snk file is used to sign the assembly, so that users know where it comes from. Clearly if you build the product yourself (or rather, a variant of the product) then you will want to sign it with your own key and not with Saxonica's.
However, from Jeroen's description, I'm not sure you actually need to rebuild the Saxon DLL. It should be enough to convert charsets.jar to a DLL by running it through IKVMC, and then ensure that your top-level .exe includes references to both the Saxon DLL and the charsets.dll (this won't work for the command line interfaces of course; but that means that the only thing you need to rebuild is the .exe files, which are pretty trivial.)
Should be fixed in Saxon 22.214.171.124 - at least if you run Transform or Query from the command line. A charsets.dll derived from charsets.jar is now included in the distribution, and is preloaded when you run Transform or Query to ensure that the class library should find these extended character sets. If you run Saxon from your own application you will need to preload this module yourself from the exe component. This needs two things: there must be a reference from your .exe to the charsets.dll assembly, and the reference must actually be used, which you can achieve by including a line such as
in your code.
I gather Jeroen Frijters is planning to include charsets.jar in future IKVM Classpath builds so hopefully this rather kludgy mechanism will become unnecessary.
I'll take a look at this next week when I return from vacation. Meanwhile you might be better off asking on the ikvm list (via ikvm.net)
Thank you Michael, I have asked there as well and will report back if they give me any information.