This is now included in version 2.0.0 and newer.

I have version 2.2.1, and the problem exists when the original file is ANSI because the output files are UTF-8. The split files are not usable for me until converted back to ANSI, which defeats the original "batch" file flow I intended to use TextFileSplitter for. Would you please confirm this incorrect conversion does still exist? You must have all of the code necessary to ensure this does not happed with the output. I look forward to your solution.

Hi gcs,

These sort of issues are impossible to troubleshoot without a sample text file. I saw your email. Could you send a sample text file, and what strategy you were using to support AT systemwidgets DOT com?

Let me upfront with about this. .NET does not have built-in detection of file encodings. I have to do a lot of guessing in the code that looks for encoding. I've tried to cover the most common situations, so I know that I missed some cases. TextFileSplitter will use the same encoding in the output as it detected in the source file. That's why I need to see a sample file, so that I can take a look at it with a hex editor, and a few other tools that I have in my toolkit.

I don't have a lot of time these days, but I'll see if I can take a gander at this issue this weekend.

Alright, this shortcoming has been addressed in version 2.5.0. It is now up in the downloads section.