I’m using the MpRecipeXML function block to store a structure in a file. This structure also contains members of type String. I noticed that if a string includes umlauts (e.g., ä, ö, ü) or other special characters, they are not encoded correctly. They are written unchanged into the file, which causes the file to be invalid XML and not openable in browsers.
My question: Is this a bug in the MpRecipeXML function block, or is there a way to influence this behavior to generate valid XML files?
I’m not an expert in that direction and I don’t have experience using wstrings together with mpRecipeXML, but about ASCII strings I don’t think it’s a bug, wether in MpRecipeXML nor in the browser. The reason is more or less the approach each usecase follows.
As I know, the XML scheme definition uses a “HTML like” coding for any special character: &#UnicodeNumber (for example, “Müller” has to be be written as “Müller” in XML, to keep the XML scheme valid for a browser or other XML scheme based systems).
Since mpRecipeXML is intended for reading / writing / editing data on file base only, the’re no translations done for special character in strings, because for the PLC data it’s not neccessary but would cost extra processing time doing it.
Since the locations where the problematic characters occur are known in my current use case, and they are always the same, I’ve solved this with a function that specifically addresses it.
I need the contents of a structure in XML format so that it can be processed externally, and that’s why I didn’t like that every web browser would complain when double-clicking the files.
The file is no longer read using the MpRecipeXML anyway.
I can try the WSTRING and check what ends up in the file…
We use MpRecipeXML for a long time for different languages, like greek and so on.
But we have based all on WSTRING and it works well, without any trouble.
So i think redefine your code and use also WSTRING.
