Danpost, you can try changing your character encoding to UTF-8; you'd need to edit your greenfoot.defs file (in the Greenfoot folder) with a text editor and add "-Dfile.encoding=UTF-8" to the "bluej.vm.args" setting, eg: bluej.vm.args=-Xincgc -Dawt.useSystemAAFontSettings=on -Dfile.encoding=UTF-8 I'm not 100% sure this will work and it is not ideal.

After making the change in the greenfoot.defs, it appears all characters except 13 (which returns 10) work. Unfortunately, I need all of them to work (all it takes is one to ruin the works). Well, I guess I can work around that one limitation. Other than that, those beyond 127 (as well as beyond 255) seem to work ok.

Yes, the end-of-line character is a bug in the CSV library we're using, so that one won't be fixed until the next release. In the meantime, add 11 before storing a number in the string, and subtract it on loading :-) Storing numbers in characters will be a bit haphazard anyway as you head towards the upper ranges, as you run into issues like invalid Unicode codepoints. I haven't tested how high you can go before you run into that problems, but I think it should be fine for the low thousands.

You mean add 14, don't you (since 13 is the problem number)? BTW, that is what I meant by working around that limitation (adjusting to avoid it). Also, should be good until at least 65'535 (beyond which is hit or miss on unicode characters).

Java 'char' is really UTF-16 encoded, meaning that values between 0xD800..0xDBFF (55296 - 56319 in decimal) must be paired with a following 0xDC00 - 0xDFFF value (and vice versa) or otherwise be invalid. See the UTF-16 page on wikipedia for more details.