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