Re: Opening old text files with non-deprecated stringWithContentsOfFile calls?

Hi Michael,

On Thu, 14 Oct 2010 10:12:32 -0700 (PDT), Michael Dupuis wrote:
> Just to update, so, it looks like in general, if you don't know what the
> encoding of the file will be, you can TRY to use the usedEncoding call,
> and that might figure out the encoding for you, but it appears to only
> try a limited set of possible encodings (maybe only the UTF and Unicode
> encodings).
>
> What I finally decided to do was make my own stringWithContentsOfFile
> that basically tries to open a file with each encoding, one at a time,
> upon failure, in the order that is most likely to be correct, until one
> is found. Brute force. Maybe that's not the right way to do it, but it
> seems to work, maybe that's what the deprecated call was doing, I'm not
> sure.

I'm pretty sure the -stringWithContentsOfFile: just tried to open the  
file in the system's default string encoding, ie. usually MacRoman (might  
be different on Eastern-language systems).

> Unfortunately, forcing the user to pick an encoding for a text file that
> they have downloaded from the web just isn't going to be practical in
> most cases, most people will have no idea what an encoding even is.
> Soooo, at least going through the opens should succeed once the tired
> encoding results in a string rather than an error.

Is there any way for you to get at the download's HTTP headers? You might  
get some guidance from the Content-Type: encoding=... if present, and  
assuming the webserver is configured decently.  At least it might give you  
a starting point.

Regards,
--
__/__/__/__/  Tom Hageman  <trh-qWit8jRvyhVmR6Xm/[email protected]> (home)  [NeXTmail/Mime OK]
  __/ __/_/
 __/__/__/
__/  _/_/                   "Noz!" "Niez!" "mm mm Vraznie!" -OOglies