This is probably not limited to just double quotes but what seemed to be a simple thing gave me quite a few head-scratching minutes yesterday.
The task was straightforward. Customer has a double quote as part of a data string inside of a XML element. For example:
The mapping logic required us to output the location of the double quote within the data string. OK, no problem. We would use the String Find functoid for this.
Unfortunately, when we used the double quote character as 2nd parameter to the functoid, we got an error when testing map:
‘userCSharp:StringFind(string(attributeData/text()) , """)’ is an invalid XPath expression. This is an unclosed string.
OK, so maybe I needed to use an escape sequence with the double quote character. For the next 15 minutes, I tried different combinations, including " and \”. None of them worked.
Of course, we could go with the old stand-by, a Script Functoid, with the following inline C#:
public int findQuote(string str)
return (str.IndexOf("\"") + 1);
That worked fine but not as easy to maintain and re-use. In the end, the combination that worked involved using an ASCII to Character Conversion functoid and the String Lookup functoid. For the ASCII to Character functoid, I used the ASCII value of 34 for the double quote character. I then connected the output to the String Lookup functoid as 2nd parameter and got the correct position. Just a simple trick and I think we can find use with other “special” characters as well.