Re: [PATCH] alt-charset handling in HTTP SMSC module
Stipe Tolj <[email protected]> Tue, 14 Mar 2017 11:08:23 +0100
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Organization | Kannel Software Foundation (KSF) |
| Message-ID | <[email protected]> |
Am 09.03.2011 00:45, schrieb Stipe Tolj: > Hi all, > > here is small issue that I resolved some days ago for a client that uses the > HTTP SMSC towards an own HTTP API (via the generic type). > > In the abstractive layer call httpsmsc_send() we handle the conversion to an > alternative character encoding, based on the value of 'alt-charset' of the > corresponding 'group = smsc' context. So far so good. > > The point is: the function ASSUMES that all MTs have our internal encoding > (UTF-8) in the msg->sms.msgdata payload. Which is NOT the case if the smsbox > connection passed a coding=2, hence we have msg->sms.coding = 2 indicating that > the msgdata is UCS-2 and NOT UTF-8. That's why we need to handle both cases > here. The patch does this, and also ensures that the msg->sms.coding is also > reset to DC_UNDEF to ensure that any specific API functions don't indicate a > "wrong assumptive" encoding. > > Please review and vote for commitment, should be pretty obvious. reconsidered this patchset as we came across the problem one more time. We NEED a way (by setting the alt-charset) to ensure that we CAN define a unique encoding torwards the upstream, otherwise any HTTP API that has no way to indicate the encoding get's UTF-8 (for coding=0) and UCS-2 (for coding=2) as payload, which messes things up semantically. Stipe -- Best Regards, Stipe Tolj ------------------------------------------------------------------- DÃŒsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/ http://www.tolj.org/ stolj at kannel.org st at tolj.org -------------------------------------------------------------------