[ 
https://issues.apache.org/jira/browse/CAMEL-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322040#comment-14322040
 ] 

Daniel Pocock commented on CAMEL-8002:
--------------------------------------

As noted earlier, this is still work-in-progress. I just had a quick look over 
the code and it appears valid but may need further testing.  Some of my other 
un-merged changes depend on updating the jSMPP 2.2.x (CAMEL-8219) but that is 
not a blocker for this issue.

A resolution of this issue will make it easier for people to use SMPP without 
having to think about encoding issues.  At present, people have to think about 
encoding issues before giving their message to camel-smpp.

> determineAlphabet only considers GSM 3.38 or UCS2
> -------------------------------------------------
>
>                 Key: CAMEL-8002
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8002
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-smpp
>    Affects Versions: 2.12.2
>         Environment: n/a
>            Reporter: Daniel Pocock
>
> SmppSmCommand.determineAlphabet(Message) tries to work out which SMPP 
> alphabet code is suitable for encoding the message text.
> It checks if GSM 3.38 can represent all the characters in the message and if 
> not it just uses UCS2 (UTF-16).
> This is less than optimal.  Many messages using European languages can not be 
> encoded in GSM 3.38 but they can be coded in Latin1, which is also supported 
> by SMPP (data_coding / alphabet numeric code for Latin1 is 3)
> The jSMPP library (Alphabet.java) does not currently know about the alphabet 
> code 3.
> I proposed a patch for jSMPP and if it is accepted then camel-smpp should be 
> updated to use it.  I already started writing a patch against camel-smpp.  
> Here is the jSMPP patch:
> https://github.com/uudashr/jsmpp/pull/39



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to