quote:
Later in the article a demo of this multiline is displayed. In the first and last line, notice the single "...
The problem is that KiXtart (with ReadLine() at least) will interpret both 0x0A and 0x0D 0x0A as line terminators.

This means that when you come to reconstruct the data, you don't known which characters to join the field parts back together with.

You would need to use the FSO calls or similar, to get the binary data.

While in practice you may not care what the embedded line termination characters were, you cannot contstruct a valid general CSV parser without handling them.

You could kludge it by counting the number of characters read and comparing to the file length. Where the record line terminators and embedded line terminators are the same characters you can calculate the number of characters missing and determine which line termination characters were used.

Where the embedded line termination is different from the record line termination you may still be able to calculate which to use based on the number of lines read, however there will be occasions when it is impossible to determine (number of record line terminators = number of embedded line terminators).