Regarding JREPL - It depends on the options used.aGerman wrote: ↑14 Apr 2018 07:07Right now I discovered that the output of CONVERTCP and JREPL (as well as using various text editors) are still different when I converted Lubomir's file.
CONVERTCP does not change line endings automatically. E.g. things like double line feeds (LF LF) can be found in Lubomir's file. CONVERTCP leaves it as LF LF while other software may automatically convert it to CR LF CR LF.
By default, all End-Of-Lines (EOLs) will be written as CR LF
With the /U option, all EOLs will be written as LF
Both of the above are processed one line at a time, so JREPL can process arbitrarily large files.
With the /M option, all original EOLs will be preserved (unless explicitly modified by the find/replace of course)
The /M option loads the entire file into memory, so it is limited to what can fit. I believe the practical limit is somewhere around 1 GB.
The performance of compiled CONVERTCP will always blow the pants off the interpreted JREPL But JREPL can be extremely useful if you want to change content at the same time as changing the encoding, or if you want to take control of inexact translations when the destination encoding is missing a source character.