Okay, seems that the problem is that IDS4 is having a problem processing ScriptArgs with these special characters. Have tried IDS3 now, and that is no problem. Anyone know of why this is, is it a bug?
I too have this problem, trying to bring our InDesign Server cs3 application to CS4. (and as I am from Denmark I have run into these æøå problems). What worked in CS3 is now broken. The analyse shows that calling a IDS4 webservice front runscript with a parameter does not translate e.g the character 'æ' correct. In our open documents rutine we can bring in a standard windows path to the document, but if it includes characters outside the 7 bit acsii range it gets messy.
I have dumped the webservice call xml and here it shows correct utf-8 representation of character 'æ'.
The "æ" is in hex: C3 83. So this seem fine., but "app.scriptArgs.getValue('fullPath')" returns: C:\kunder\w2p\test<6C72>34567890.indd
The ony way to make it work is to send: testÃ¦1234567890.indd in the call traslatet in the xml as: testÃ¦1234567890.indd (æ = hex: C3 83 C2 A6) which I belive is somehow double encoding, but it works.
I have successfully circumvented the problem ´by encodeing the parameter stings with base64 before sending, and then decode in the ID script before using them.