CSV again.

[Alex Tweedly]

It's likely (but of course not 100% guaranteed) that those characters 
have themselves been manipulated in a consistent way by either LC or any 
other subsystem - i.e. auto-translated or not.

Anyone who chooses to use those as genuinely different characters within 
quoted cells *deserves* to have their data be unreadable :-)

-- Alex.

On 16/10/2015 16:28, Bob Sneidar wrote:
> But what if the cr or lf or crlf is inside quoted text, meaning it is not a delimiter? Oh, I'm afraid the deflector shield will be quite operational when your friends arrive.
>
> Bob S
>
>
>> On Oct 16, 2015, at 08:04 , Alex Tweedly <alex at tweedly.net> wrote:
>>
>> Hi Mike,
>>
>> thanks for that additional info.
>>
>> I *think* (it's been 3 years) I left them as <GS> (i.e. numtochar(29)) because I had some data including normal TAB characters within the cells (!!( and thought <GS> was a safer bet - though of course nothing is completely safe. It's then up to the caller to decide whether to do "replace numtochar(29) with TAB in ...", or do TAB escaping, or whatever they want.
>>
>> As for the other bigger problem ....   Oh dear = CR vs LF vs CRLF ....
>>
>> Are you on Mac or Windows or Linux ?
>> How is the LF delimited data getting into your app ?
>> Maybe we should just add a "replace chartonum(13) with CR in pData" ?
>>
>> (I confess to being confused by this - I know that LC does auto-translation of line delimiters at various places, but I'm not sure when it is, or isn't, completely safe. Maybe the easiest thing is to jst do all the translations ....
>>
>>   replace CRLF with CR in pData
>>   replace numtochar(10) with CR in pData
>>   replace numtochar(13) with CR in pData
>>
>> -- Alex.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode