This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Other JSE/JEE APIs and the fly likes require suggestion - FastSMS encoding problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Other JSE/JEE APIs
Bookmark "require suggestion - FastSMS encoding problem" Watch "require suggestion - FastSMS encoding problem" New topic
Author

require suggestion - FastSMS encoding problem

Bharani kumar
Greenhorn

Joined: Apr 07, 2011
Posts: 3
Hi

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


please suggest

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41180
    
  45
Who knows what the capabilities are of the gateways an SMS has to travel through? I'd restrict it to ASCII.


Ping & DNS - my free Android networking tools app
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19656
    
  18

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).

Oh, and please UseAMeaningfulSubjectLine next time. I've modified it for you this time.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Bharani kumar
Greenhorn

Joined: Apr 07, 2011
Posts: 3
Hi

Thanks for the suggestion.
Please see the following code.


Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41180
    
  45
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?
Bharani kumar
Greenhorn

Joined: Apr 07, 2011
Posts: 3
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.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41180
    
  45
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.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19656
    
  18

Please UseCodeTags next time. I've added them for you this time.

Also a note: don't use StringBuffer, use StringBuilder. It doesn't have unnecessary synchronization.


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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: require suggestion - FastSMS encoding problem
 
Similar Threads
Weblogic newbie question.
wrong file name in the submission.jar
PhraseOMatic syntax problem in Head First Java
Metal Fans
Favourite motivational songs?