Of course and it url-encodes all msgdata stuff. But as I wrote below where I explained what I got on smscconn_send() function on smsccon.c file and on sms_split() function on sms.c file, for example when I had greek letter DELTA, the value of it was 0x10. So, when data passes from charset_utf8_to_gsm() function, byte with value 0x10 turns to NRP.

source code part of charset.c line 338:

        if(val1 <= 255) {
            val1 = latin1_to_gsm[val1];
            /* needs to be escaped ? */
            if(val1 < 0) {
                octstr_append_char(newostr, 27);
                val1 *= -1;
            }
        } else {

because latin1_to_gsm[] table assigns position 0x10 with NRP.

But, if I apply those changes I included on the attached sms.c file, msgdata is being converted to unicode format (charset_gsm_to_utf8() function - so my DELTA character converts to 0xce 0x94 2 byte values) and passes successfully from sms_msgdata_len() and extract_msgdata_part_by_coding() functions.

As I said to my very first post, am I doing something wrong?
But no one instructed me to do something better.
And as I said, this happens only when the sms exceeds 160 characters, so program follows different path (line 574 on smscconn.c

    if (parts == NULL)
        ret = conn->send_msg(conn, msg);
    else {
        long i, parts_len = gwlist_len(parts);  ...... etc
).

Alex, have you tried to send sms with more than 160 characters containing at least one greek letter? If you have and it works fine for you, then what do I make wrong? Please, let me know which parameters do I have to pay attention.

Best Regards
Mike Nakos


On 05/05/11 21:03, Alejandro Guerrieri wrote:
Sqlbox url-encodes the content, and url-decodes when reading, so you shouldn't have any encoding issues with it.

Regards,

Alex

On Thu, May 5, 2011 at 7:41 PM, Mike Nakos <[email protected] <mailto:[email protected]>> wrote:

    Hi Niko,
    I surely agree with you and that's the last I wanted to do. It is
    not my style to make branches on the trunk.
    But I had no time to spend to investigate what's bothering sqlbox
    and doesn't give bb utf-8 data to handle.
    I want to check it on the future, but now I can't.
    My only need is to insert sms on DB, transmit them with bb and get
    any dlr back to DB.

    Sincerely yours
    Mike Nakos


    On 05/05/11 20:28, Nikos Balkanas wrote:
    Hi Mike,

    I believe i first alerted you to the fact that it is an encoding
    problem. But from what you describe, you are doing the wrong
    thing. It is not a bb issue, and changing it could create
    problems with smsbox and kannel spec. The standard communication
    between boxes for kannel is UTF-8 (for non-unicode charsets). If
    sqlbox doesn't do it, it is in violation and sqlbox should be
    patched.

    BR,
    Nikos

    On Thu, May 5, 2011 at 8:13 PM, Mike Nakos <[email protected]
    <mailto:[email protected]>> wrote:

        Sorry for the mess on mailing list, but the previous mail
        (mail with the attachment) was referring the 1st email I sent
        on Apr 30 2011.


        On 05/05/11 20:07, Mike Nakos wrote:

            Well, after many hours of digging, I found that sms is
            transmitted
            perfectly if it has length up to 160 characters.
            Note that, in kannel.conf on
            group = smsc
            section I use
            alt-charset = "UTF-8"
            and on db INSERT also (charset field).

            But, as I figured out (smsccon.c - int
            smscconn_send(SMSCConn *conn,
            Msg *msg)), when SMS has more than 160 characters then it
            changes path
            and is transmitted data that comes from the below code:
            parts = sms_split(msg, NULL, NULL, NULL, NULL, 1,
                        counter_increase(split_msg_counter)&  0xff, 0xff,
            conn->max_sms_octets);
            which loses data with greek characters. That's because
            the data that
            comes from sqlbox (for example for greek letter DELTA
            [Δ]) isn't utf-8
            (which means U+0394 - ce 94) but ASCII value 0x10.
            I won't examine why is this comes this way, but to I
            patched it for
            myself (sms.c) so I have a workaround for it.
            In a few words, when program flow comes into
            extract_msgdata_part_by_coding() function and
            sms_msgdata_len()
            function, thinks data is utf-8 but it is GSM encoded
            (Note that, all
            characters that I insert INTO send_sms table are
            url-encoded ex.
            %10%12 etc).
            All the trick is done with functions charset_gsm_to_utf8()&
            charset_utf8_to_gsm() at the points that have the remark text
            // mnakos PATCH 2011-05-04 (concat problem fix)
            I have the sms.c file attached. I hope it will by stayed
            attached and
            save someone's desperate time like I was.








Reply via email to