[xerxes42]

Hi

I'm using the Kayako API to get data from a submitted ticket, then reformat it with php to generate a email to one of our suppliers.
The problem I've run into is the use of some special characters. The particular case is ". We use it in our order forms when our users order a new display (ex Samsung 22").
It is displayed correct in the SupportSuite interfaces and is stored correctly in the database but when i use the getSubmittedTicket it's shown as:
Samsung 22”

Any ideas why this is happening?

[Andrew Gillard]

I can't seem to replicate this issue. I created a ticket with a subject & body of

£££"""'''

(i.e. three pound signs, three double quotes and three single quotes/apostrophes) and it displayed properly in the Kayako customer pages, the staff pages, the database, and in the pages that access Kayako via the API.

That said, I also created a ticket with a subject & body of

x嶉嶃嶣ffff嵧莧莊荝莮f蘒彖弛㏒㏑㎏⿴⿷⿲○

(a random string of Unicode characters that I generally use to test multibyte character support) and was greeted by an SQL error in Kayako, and complete nonsense everywhere it was displayed (customer pages, staff pages, database and via the API) - though it was always the same complete nonsense:

x???ffff?????f???????????

So it looks like Kayako can't handle full-on scary Unicode, but can at least handle double quotes and pound signs. Are you sure that you don't have a character-set issue somewhere in your API client? For example, is your API client setting a character set (either in a HTTP header or in a <meta> tag) that differs from how the API is returning things (i.e. ISO-8859-1)?

The other possibility is that your double-quote character was copied from a Microsoft Word document where it had been converted from a plain old ASCII code 34 " to a fancy left/right quotation mark (i.e. “ or ” - character codes 147 and 148 in ISO-8859-1). If that's the case, replace it with a normal double quote and everything will be fine (or go back to the above paragraph and make sure that your API client is using ISO-8859-1).

[xerxes42]

Lesson learned:
Never code more then 15 hours strait. Mistakes like this will occur...

The test browser I was using was set to ISO-8859-1 instead of UTF-8... Shame on me.
Works like a charm when the browser is set to UTF-8

Even though UTF can be a pain sometimes it's a bliss when you have users and systems who use more then English.

Thanks a lot! This will please my manager even more.

Brgds
Olof Mattsson

[Guilherme]

Hi,

In lib/nusoap/nusoap.php change to FALSE var $decode_utf8 = false;