llList2CSV and llCSV2List Bugs? Any workaround?

Hello scripters,

while scripting, i encountered a possible bug/flaw in llList2CSV and llCSV2List Functions.
They work fine, until you have a string with a comma inside the list. Basicly what happens is: If you turn List to CSV, you get a string seperated each object in the list with comma. Problem (and whats a bug in my eyes) is, thatt Strings aren't escaped (read: surrounded by " ".

Lets explain it on an example:

Lets say we have a list with [1, 2.22, 4, "My List", "Cat, Dog"]. Thats 5 elements. If i convert this to a string with llList2CSV, i get follow string "1, 2.22, 4, My List, Cat, Dog".
Now we can already see the problem here, we can't say anymore if "Cat, Dog" was once one object or two. If we convwert the same string to list again, we get the follow list [1, 2.22, 4, "My List", "Cat", "Dog"]. Notice the change? Right. The new list has 6 elements instead of 5.

The code below can be used to test it.

list liste = [1, 4, 1.1111, "One String", "String, with Comma"];
integer liste1size = llGetListLength(liste);

string strList1 = llList2CSV(liste);
llOwnerSay("Size of list: "+(string)liste1size+"\n"+strList1);

list liste2 = llCSV2List(strList1);
integer liste2size = llGetListLength(liste2);

string strList2 = llList2CSV(liste2);
llOwnerSay("Size of list2: "+(string)liste2size+"\n"+strList2);

prodcues follow output:
[6:00] Object: Size of list: 5
1, 4, 1.111100, One String, String, with Comma
[6:00] Object: Size of list2: 6
1, 4, 1.111100, One String, String, with Comma



Is there a workaround to prevent this, or an annoucned bugfix for this behaviour? It makes it pretty hard, to sync data with other objects, since only way to objects can communicate is via messages, which are strings indeed.

Anyone else had this problem and how did they worked around this?

there is another function you can use.

look up... i think it's 'dump string to list'? well, look up lists on the wiki, then the functions dealing with lists. there is a function where you can set your own separator instead of a comma.

Well, that's not a bug but a feature. It won't (and shouldn't) be fixed. It's what the function DOES, and to change it to do something else would be a mistake.

It would be nice if LSL had provided a function to "marshall/unmarshall" lists -- that is, in the barely comprehensible terms of ISO docs, translate lists to and from a transfer syntax. Make them "sendable" or "textable" or however you wish to say it. But they didn't.

Here's a function that probably does what you want:

The to/from CSV functions are meant to be used when you want to use a comma as a separator. In your case you have commas inside the strings, so you need a different separator. Look up llDumpList2String and llParseString2List, that will do exactly what you need. Just be sure to pick a separator that will never occur in your data. Something like "#$%$#" or whatever.

You should just escape any commas at the time you put them in the list. One solution would be to replace the comma with another character there is little or no chance of being used otherwise. Many times in my scripts I use + as a delimiter instead of a comma. That prevents the situation you have described.

Use llParseString2List/llParseStringKeepNulls and llDumpList2String, and use another character besides a comma as a separator.

Personally, I have never used the CSV/List conversion functions, as they are far too limited for what I need them to do.

ding ding ding we have a winner

csv in any language is a pita, the only use ive had for it is converting excel to SL its just sooo much easier to use phrase string and any character you wish for the separator, that way those pesky things like vectors and rotations dont get buggered up

That's actually not really true. Problem is, that llList2CSV doesn't follow any kind of of CSV format. There is a standard format for CSVs.

For example, the data of one field contains a comma, it must be delimited with " ". So that the csv looks like:

1, 4, 1.111100, One String, "String, with Comma"

But llList2CSV fails to do this which is breaking the standard definition of CSV format => loss of compatibility.


Short summary of CSV can be found here:
http://en.wikipedia.org/wiki/Comma-separated_values


RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files:
http://www.rfc-editor.org/rfc/rfc4180.txt

Some more information on it:
http://edoceo.com/utilis/csv-file-format


If llList2CSV and llCSV2List would follow this rules, there wouldn't be any problems converting the lists back and forth.


I'm thinking of reporting this as a bug. Anyone know, if there is already such a request available on JIRA?


Lear Cale: Thanks, going to check this out.

Good point, and I stand corrected.

you are expecting way too much from LSL. While there is a standard called CSV, it can also just be short for comma seperated values, which is exactly what you get. The fact you put a comma in the middle of your value is your fault, not the function's fault. LSL doesn't do anything well, so why should it do this well?