CSC is a program that changes the charset encoding of a file. Though many text editors allow you to easily change the encoding of a opened file, this program is intended to be used from the command line and in shell scripts. The source code, a working non-official gentoo ebuild, etc. can be found at the web page: http://babel.ls.fi.upm.es/~iperez/csc/csc.html
What does this have over the iconv and recode utilities? The website only mentions the ability to use the same filename for both input and output. That's inherantly risky, and a lot of unix utilities don't let you do it.
Ivan: please respond on the bug next time. Reading and writing to the same file correctly is tough in UNIX, esp in this case, because the size of the file will be changing. Going fopen(...,"rw+") may be simple, but consider when you are at an existing point in the file, and want read one byte, and need to write two bytes - everything else in the file needs to be shifted - and if you write those two bytes before reading, you can end up with invalid characters (think UTF with multibyte chars). That's why the correct solution is: "iconv foo <input >output ; mv output input ;" If you really need the functionality of using the same filename, rewrite your Java application in a scripting language (perl/python/bash), so that it simply calls iconv with a temporary output file, and then moves that output file to the input file.
(In reply to comment #2) I see. One possible solution is to map the whole file in memory, ask (malloc) for the same amount of bytes in the new charset encoding, and convert the file while still loaded in memory. However, this is absolutely discouraged if the file is too large. In fact, I think that my java application does that (sincerely, I don't even remember, I wrote it a month ago and almost forgot about it). Definitely, I think that a wontfix would be more appropiate for this bug. I have other bug reports asking for maintainers and this sort of charset converter is not important to me. Many thanks for your advice and suggestions, Robin.
Closing as requested by the upstream author.
