I'm developing an app with Unity3d.
As you know, we can write code in C# because Unity3d provides the environment using Mono. I don't know it's due to Mono or Unity3d itself but there's a problem with setting ANSI encoding for some languages, such as Chinese, Japanese and Korean. When I run my app on Android, all Code pages I need occur error messages like this.
NotSupportedException: CodePage 50227 not supported
If you read the explanations here, it says
"An asterisk in the last column indicates that the code page is natively supported by the .NET Framework, regardless of the underlying platform."
The CodePage 50227 is indicated by an asterisk!
I said I'm having a trouble with Android, but it also occurs the exceptions on Windows too. In fact, much better than on Android, because on Windows I can use some ANSI encodings which didn't work but still very limited compared to when writing code with Visual Studio.
If mono or Unity3d doesn't support ANSI encodings fully, is there anything I can do?
I really need to read some text files written in ANSI encodings and save them in UTF encoding. Of course, I can create a jar plugin for this job, but I don't want to due to performance reasons. (I'm already using too many jar files in Unity3d) If possible, I want to write in C# or in C++.
The CodePage 50227 is indicated by an asterisk
Sorry, but that's irrelevant. Mono (whether running on Windows or Android) is not "the .NET Framework". It is an attempt at a compatible implementation, but Microsoft's documentation for .NET isn't intended to be a reliable reference for non-Microsoft implementations of the API.
If mono or Unity3d doesn't support ANSI encodings fully, is there anything I can do?
These encodings should be fully supported by the underlying OS. Unfortunately, if Mono does not itself support them (which should be surprising to me, but I guess it's not really), then you will have to use the platform-specific parts of the API (e.g. p/invoke on Windows).
I doubt adding one more jar plugin for Android would cause a significant performance change.
Personally, I'd go that route. But alternatively, if you know in advance which specific encodings you need, and there aren't too many of them, I suppose you could write your own Encoding classes in C# as part of your project to support each one. Not something I'd relish, especially for multi-byte encodings like CP 50227, but you should be able to write a regular C# program to build the data tables you'd need, based on the .NET implementation of the encodings. So the actual manual labor involved can be reasonably minimal.