**>To: Davy Chan <[EMAIL PROTECTED]> **>Cc: Yip Kwok Fai <[EMAIL PROTECTED]>, [EMAIL PROTECTED] **>Subject: Re: Chinese SMS **>From: Guillaume Cottenceau <[EMAIL PROTECTED]> **>Date: 01 Dec 2004 10:45:49 +0100 **>In-Reply-To: <[EMAIL PROTECTED]> **> **>Davy Chan <chandave 'at' cs.ust.hk> writes: **> **>> **>From: "Yip Kwok Fai" <[EMAIL PROTECTED]> **>> **>To: <[EMAIL PROTECTED]> **>> **>Subject: Chinese SMS **>> **>Date: Wed, 1 Dec 2004 13:18:13 +0800 **>> **> **>> **>How can I send Chinese SMS through web interface ? Is there any encoding **>> **>required ? **>> **>Thank you very much. **>> **>> Chinese characters requires double-byte support. You will need to **>> submit the SMS with an encoding of "3" either through an HTTP_POST **>> header (X-Kannel-Coding: 3) or as a parameter in an HTTP_GET **>> (GET /cgi-bin/sendsms?coding=3&text=...) **> **>Are you sure this is "3"? **> **> **>In the userguide, I can see for sendsms cgi variables: **> **> codingnumber **> Optional. **> **> Sets the coding scheme bits in DCS field. Accepts values **> 0 to 2, for 7bit, 8bit or UCS2. If unset, defaults to 7 **> bits unless a udh is defined, which sets coding to 8bits. **> **>So here, this should be "2". **> **> **>But I can also see in "Table 6-9. Parameters (Escape Codes)" **> **> %c **> message coding: **> **> 0 (default, 7 bits), 1 (7 bits), 2 (8 bits) or 3 (Unicode) **> **>And in "Table 6-11. X-Kannel Post Headers" **> **> %c **> (coding) **> X-Kannel-Coding **> 1=7 Bits, 2=8 Bits, 3=UCS2 **> **>Which is rather confusing.. **> **> **>Going down to sourcecode, sms.h contains: **> **>#define DC_7BIT 0 **>#define DC_8BIT 1 **>#define DC_UCS2 2 **> **>Also, for an MT with no compression and no message class, dcs is **>set in sms.c with the following code: **> **> dcs |= (msg->sms.coding << 2); /* sets bit 3,2 */ **> **>which means that clearly the value for UCS2 must be 2 in order to **>have a value of 8 in the DCS for such a message (00001000b). **> **>Similarly, decoding a dcs for an MO in sms.c for such a message **>has the following code: **> **> (*msg)->sms.coding = (dcs & 0x0C) >> 2; /* grab bit 3,2 */ **> **>which would also advocate for a value of 2 for UCS2. **> **> **>I think there is probably a bug in the documentation. Have you **>tried to send a UCS2 message yourself with a coding of "3"? I **>have personally tried a 8bit message with a coding of "1", which **>succeeded. **> **>I am resisting the willing of crossposting to the devel list, in **>the hope that most core developers also read this one. **>
This is an artifact of the "GREAT MIGRATION FROM 0 MEANING UNDEFINED" awhile back. Kannel up to v1.3.2 did not have a clear definintion of what to put into parameters (like Coding, MWI, RPI, MClass, etc). Some used zero to represent undefined values but zero could be a value for some parameters (like MWI, RPI). Also, there wasn't a clear standard on whether to start the parameters with a count from 0..1..2 or 1..2..3. As a result, the value of -1 is now declared as meaning "UNDEFINED" and all parameters start from zero. My example was for v1.3.1 (sorry for not including that in my reply...was typing to fast...). If you are using versions prior to v1.3.2, then the coding for UCS-2 (double-byte) characters is "3"; 8-bit binary (like STK provisioning) is is "2"; 7-bit GSM7 character set is "1" or "0". If you are using versions after v1.3.1 (v1.3.2, v1.4.0 stable, and CVS head) then UCS-2 is "2"; 8-bit binary is "1"; GSM7 character set is "0"; and undefined coding is "-1". Hope that clears things for everyone. See ya... d.c.
