title: Invalid characters before my XML in Ruby
body: <p>When I look in an XML file, it looks fine, and starts with <code>&lt;?xml version="1.0" encoding="utf-16le" standalone="yes"?&gt;</code></p>
  
  <p>But when I read it in Ruby and print it to stout, there are two ?s in front of that: <code>??&lt;?xml version="1.0" encoding="utf-16le" standalone="yes"?&gt;</code></p>
  
  <p>Where do these come from, and how do I remove them? Parsing it like this with REXML fails immediately. Removing the first to characters and then parsing it, gives me this error:</p>
  
  <p><code>REXML::ParseException: #&lt;REXML::ParseException: malformed XML: missing tag start
  Line: 
  Position: 
  Last 80 unconsumed characters:
  &lt;?xml version="1.0" encoding="utf-16le" s&gt;</code></p>
  
  <p>What is the right way to handle this?</p>
  
  <p><strong>Edit:</strong> Below is my code. The <code>ftp.get</code> downloads the xml from an ftp server. (I wonder if that might be relevant.)</p>
  
  <pre><code>xml = ftp.get
  puts xml
  until xml[0,1] == "&lt;"  # to remove the 2 invalid characters
    puts xml[0,2]
    xml.slice! 0
  end
  puts xml
  document = REXML::Document.new(xml)
  </code></pre>
  
  <p>The last puts prints the correct xml. But because of the two invalid characters, I've got the feeling something else went wrong. It shouldn't be necessary to remove anything. I'm at a loss what the problem might be, though.</p>
  
  <p><strong>Edit 2:</strong> I'm using Net::FTP to download the XML, but with this new method that lets me read the contents into a string instead of a file:</p>
  
  <pre><code>class Net::FTP
  
    def gettextcontent(remotefile, &amp;block) # :yield: line
      f = StringIO.new()
      begin
        retrlines("RETR " + remotefile) do |line|
          f.puts(line)
          yield(line) if block
        end
      ensure
        f.close
        return f
      end
    end
  end
  </code></pre>
  
  <p><strong>Edit 3:</strong> It seems to be caused by StringIO (in Ruby 1.8.7) not supporting unicode. I'm not sure if there's a workaround for that.</p>