Page History

...

Alphabet corresponds to bits 0-3 of the data coding field.  For some types of message, where a message class is used (by setting bit 5 of the data coding field), the lower two bits of the data coding field are not interpreted as alphabet and only bits 2 and 3 impact the alphabet.

Furthermore, current versions version of the JSMPP library only seems to support bits 2 and 3, assuming that bits 0 and 1 are used for message class.  This is why the Alphabet class in JSMPP doesn't support the value 3 (binary 0011) which indicates ISO-8859-1.

...

Older versions of Camel had bugs in support for international character sets.  This feature only worked when a single encoding was used for all messages and was troublesome when users wanted to change it on a per-message basis.  Users who require this to work should ensure their version of Camel includes the fix for for 

In addition to trying to send the data coding value to the SMSC, the Camel component also tries to analyze the message body, convert it to a Java String (Unicode) and convert that to a byte array in the corresponding alphabet.  If some characters in the String can't be represented in the chosen alphabet, they may be replaced by the question mark ( ? ) symbol.  Users of the API may want to consider checking if their message body can be converted to ISO-8859-1 before passing it to the component and if not, setting the alphabet header to request UCS-2 encoding.  If the alphabet and data coding options are not specified at all then the component may try to detect the required encoding and set the data coding for you.

...