I am trying to send SMS with following text. I have used UTF8 as the charset.
KIITOS AREAN MATKAPALVELUIDEN KÄYTÖSTÄ. KEHITÄTHÄN PALVELUAMME KANSSAMME AO. LINKIN KAUTTA:<BR>HTTPS://DIGIUMENTERPRISE.COM/ANSWER?LINK=610-9239P92K&Q50785765=HELAT2266&Q50785766=01039064&Q50785767=8IRZSC
but these characters are not being handled correctly as when they arrive at FastSMS they appear as upside down question marks:
KIITOS AREAN MATKAPALVELUIDEN Kï¿„YTï¿–STï¿„. KEHITï¿„THï¿„N PALVELUAMME KANSSAMME AO. LINKIN
The 3rd party SMS gateway we use at work is limited to ISO-8859-1, but perhaps FastSMS is a bit more limited. You can then try to send UTF-8 but they will ignore it.
Then again, their API mentions UTF-8 XML documents all the time. Are you sure you are sending proper UTF-8? Can you show us the code that sends these UTF-8 documents to FastSMS? I recently solved a similar bug at work that sent UTF-8 using the system default encoding (Windows-1252).
Thanks for the suggestion.
Please see the following code.
Joined: Mar 22, 2005
So the accented characters are right in the source code - what encoding are you using for the source code? Are you specifying that correctly during compilation?
Joined: Apr 07, 2011
I am using 8-bit encoding scheme(UTF-8) while appending it to the URL and i have developed this in eclipse IDE. so i didn't compile it manually.
Joined: Mar 22, 2005
I don't see anything in the code to suggest that you're using UTF-8; what do you mean by that? If you didn't specify which encoding the source code is in then it's quite likely that the compiler gets it wrong. You need to find out the source file encoding, and make sure it's specified during compilation. I'm sure the IDE documentation covers that.
Here you already get conversion problems. The StringBufferInputStream uses the system default encoding. The class is deprecated because of this, and it even mentions this.
Besides, I don't get what you're trying to do here. You take a String, convert it to bytes which you then again convert to a String?
This should be enough if you take the original String. The URLEncoder will take any "weird" characters and transform them into something URLs can understand.
Another potential encoding problem here. Use an InputStreamReader with an explicit encoding instead:
Note that bytesRead, no longer necessary for the first part, gets replaced by charsRead, and buffer turns into a char.
One more thing. If FastSMS allows it, switch to POST. GET can have limitations on the total URL length. POST does not have this problem.
subject: require suggestion - FastSMS encoding problem