yes but what I'm saying that is we should leave it in the character set it is.gsm_to_latin1 is something which is not a good idea either as it is run also on binary and unicode content in the current code. In a situation where you chain multiple kannels for incoming you simply want to forward the incoming SMS "as is" without modifiying it whatsoever. indicating what encodig default means is ok but we should not in any way modifiy the data at this point. We should maybe do it in smsbox where we forward it to a webpage and indicate there which character set the webpage accepts and then convert it once. We want to avoid situations where we do
gsm character set -> latin1 -> gsm character set
as some characters would not pass this way.
That's sounds about right. if you also encode from external
characater set to GSM or UCS2 in smsbox on the way in (MT), then I'm all for
moving all the charset conversions to smsbox.
one point though - how will you handle drivers (like SMPP) that allow you
to send specific native character encodings instead of UCS-2 when using non-GSM
compatible alphabets ? send only in unicode ?
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
+972-67-340014
::..
May's Law:
The quality of correlation is inversly proportional to the density
of control. (The fewer the data points, the smoother the curves.)
May's Law:
The quality of correlation is inversly proportional to the density
of control. (The fewer the data points, the smoother the curves.)
______________________________________________________ Scanned and protected by Inflex and McAfee AntiVirus
