I've read through a number of older posts and while there seem to be a desire to support non-standard characters in the SDK, it may not yet be ready to handle them.
Here's the situation which I had to deal with for the old AIM form/value gateway last year (contrived test case after an actual use case which ocurred) converted to an XML gateway request:
<billTo> <firstName>ð é ñ ç æ</firstName> <lastName>Center</lastName> <address>ð é ñ ç æ</address> <city>ð é ñ ç æ</city> <state>[removed]</state> <zip>[removed]</zip> <country>US</country> <phoneNumber>[removed]</phoneNumber> </billTo>
And here's what I get if I send it through the Java SDK:
<ErrorResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <messages> <resultCode>Error</resultCode> <message> <code>E00003</code> <text>Invalid character in the given encoding. Line 25, position 24. </text> </message> </messages> </ErrorResponse>
Is this a bug in how I am using the SDK? If I'm using it wrong, what should I do to encode these values correctly before calling customerAddressType.set*() methods?
If this is this a bug in the SDK, any general suggestions on how and where to fix it in my local copy of the SDK so I can submit a patch? My charset encoding skills are pretty poor, although I did at one point eventually figure out how to fix it for the old AIM interface.
Solved! Go to Solution.
01-22-2016 02:48 PM
Note that this appears to now be fixed in the SDK. I no longer see this problem when running with an SDK built on 2016-04-14 (hash fc6b763dde02ddc30d8b2f65747095ae08d722d8)
04-19-2016 09:31 AM
01-25-2016 01:19 PM
Note that this appears to now be fixed in the SDK. I no longer see this problem when running with an SDK built on 2016-04-14 (hash fc6b763dde02ddc30d8b2f65747095ae08d722d8)
04-19-2016 09:31 AM