Regarding 4.6 always placing a 0x0a at the end of every segment, that’s not the behavior I’ve seen. We’ve been able to use any segment delimiter we want and have not experienced “forced” LF delimiters. The default segment delimiter is LF. I’ve never successfully used delimiters specified in a template (only used custom templates a couple of times) so don’t know if there might be a bug or if it just doesn’t use delimiters from a template properly when creating output. Maybe delims in a template are for reading use only?
Passing delimiters to convertToString and to the EDI enveloping services has always done the right thing for the EDI projects I’ve worked on. I did a flat-file project to generate a flat-file but didn’t need to use a template–the EDI module can create a flat-file without a template in some cases. In this case, the delimiters were passed to convertToString and they were placed properly in the file.
UNIX normally uses 0x0a (LF) for EOL
Windows normally uses 0x0d 0x0a (CR/LF) for EOL
Mac normally uses 0x0d (CR) for EOL
As Chris points out, if files are FTP’d around and you want to keep CRs and LFs untouched, you’ll want to use binary mode.
Notepad (pre-XP) only understands CR/LF EOL. Stand-alone CR or LF appear as non-printable chars (usually an empty white box) as do other control characters. Wordpad understands multiple types of EOL markers, as does the aforementioned TextPad.
We just ran into nasty UltraEdit behavior–it massages end-of-line (EOL) markers to normalize to CR/LF pair. So a single CR or LF is changed to CR/LF. LF/CR is changed to CR/LF. CR/CR/LF is changed to CR/LF. Has anyone else seen this UltraEdit behavior? Is there a way to turn it off?