title: Convert NSData bytes to NSString?
body: <p>I'm trying to use the <a href="http://www.stupendous.net/projects/bencoding-obj-c-class/" rel="noreferrer">BEncoding ObjC class</a> to decode a <code>.torrent</code> file.</p>
  
  <pre><code>NSData *rawdata = [NSData dataWithContentsOfFile:@"/path/to/the.torrent"];
  NSData *torrent = [BEncoding objectFromEncodedData:rawdata];
  </code></pre>
  
  <p>When I <code>NSLog</code> <code>torrent</code> I get the following:</p>
  
  <pre><code>{
      announce = &lt;68747470 3a2f2f74 6f727265 6e742e75 62756e74 752e636f 6d3a3639 36392f61 6e6e6f75 6e6365&gt;;
      comment = &lt;5562756e 74752043 44207265 6c656173 65732e75 62756e74 752e636f 6d&gt;;
      "creation date" = 1225365524;
      info =     {
          length = 732766208;
          name = &lt;7562756e 74752d38 2e31302d 6465736b 746f702d 69333836 2e69736f&gt;;
          "piece length" = 524288;
  ....
  </code></pre>
  
  <p>How do I convert the <code>name</code> into a NSString? I have tried..</p>
  
  <pre><code>NSData *info = [torrent valueForKey:@"info"];
  NSData *name = [info valueForKey:@"name"];
  unsigned char aBuffer[[name length]];
  [name getBytes:aBuffer length:[name length]];
  NSLog(@"File name: %s", aBuffer);
  </code></pre>
  
  <p>..which retrives the data, but seems to have additional unicode rubbish after it:</p>
  
  <pre><code>File name: ubuntu-8.10-desktop-i386.iso)
  </code></pre>
  
  <p>I have also tried (<a href="http://www.cocoadev.com/index.pl?NSDataToNSString" rel="noreferrer">from here</a>)..</p>
  
  <pre><code>NSString *secondtry = [NSString stringWithCharacters:[name bytes] length:[name length] / sizeof(unichar)];
  </code></pre>
  
  <p>..but this seems to return a bunch of random characters:</p>
  
  <pre><code>扵湵畴㠭ㄮⴰ敤歳潴⵰㍩㘸椮潳
  </code></pre>
  
  <p>The fact the first way (as mentioned in the Apple documentation) returns most of the data correctly, with some additional bytes makes me think it might be an error in the BEncoding library.. but my lack of knowledge about ObjC is more likely to be at fault..</p>