If a character which would be present in the log call is badly encoded, it can stop FoundationKit from decoding the entire 200-line block of log lines as UTF, and subsequently cause issues with other, properly encoded UTF characters elsewhere.

Typically this is caused by someone committing from another platform using Latin-1 encoding or similar. Eventually the problem passes into history and extended characters start working again for recent log entries, but it can mess up the display for a while.

The problem is that the FoundationKit methods for converting NSData to NSString simply abort the entire conversion when a badly encoded character is encountered. Right now we just fall back on other encodings so we can at least display something, but really what we'd like to do is identify where the decoding failed, decode up to that point, decode the problem character some other way, then decode the rest as UTF. Or, force the interpretation as UTF anyway and leave that one character garbled. I haven't found a way to do either on FoundationKit yet, but since this can cause issues that don't appear on some other tools that use other more tolerant decoders (like Java), it deserves another look. Perhaps there is another third party NSData -> NSString decoder we can use instead.