Ну вот опять же, Вы привели всего лишь маааааленькую часть кода, и нам теперь сиди гадай, я вообще удивлен , что
@corristo решил откликнуться :D
Если все остальное ок, как Вы говорите, то возможно проблема в buf? В нем точно выделяется нужный размер?
а еще вот сюда стоит заглянуть
stackoverflow.com/questions/9701776/nsutf8stringen... мало ли, может там и правда не UTF (там есть пример кода, позволяющий посмотреть кодировку, и поддерживается ли она вообще)
You say that it “is definitely UTF-8”, but without a Content-Type header, you don't really know that. (And even if you did have a header saying that, it could still be wrong.)
My guess is that your data is usually ASCII, which always parses correctly as UTF-8, but you sometimes are trying to parse data that's actually encoded in ISO 8859-1 or Windows codepage 1252. Such data will generally be mostly ASCII, but with some bytes outside the 0–127 range ASCII defines. UTF-8 would expect such bytes to form a sequence of code units within a specified sequence of ranges, but in other encodings, any byte, regardless of value, is a complete character on its own. Trying to interpret non-ASCII non-UTF-8 data as UTF-8 will almost always get you either wrong results (wrong characters) or no results at all (cannot decode; decoder returns nil), because the data was never encoded in UTF-8 in the first place.
You should try UTF-8 first, and if it fails, use ISO 8859-1. If you're letting the user retrieve any web page, you should let them change the encoding you use to decode the data, in case they discover that it was actually 8859-9 or codepage-1252 or some other 8-bit encoding.
If you're downloading the data from a specific server, and especially if you have influence on what runs on that server, you should make it serve up an accurate Content-Type header and/or fix whatever bug is causing it to serve up text that isn't in UTF-8.
Из того же SO. Так что скорей всего у Вас не UTF