Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As you mentioned, you'd have to know the encoding of the file to read the <code>encoding</code> attribute.</p> <p>However, there is a heuristic that can easily get you close enough to the "real" encoding to allow you to read the encoding attribute. This works, because the <code>&lt;?xml</code> part by definition can only contain characters in the ASCII range (however they are encoded).</p> <p>The XML standard even <a href="http://www.w3.org/TR/REC-xml/#sec-guessing" rel="noreferrer">describes the exact process used to find out the encoding</a>.</p> <p>And the encoding label isn't redundant either. For example, if you use the algorithm in the XML spec to find out that some ASCII-based (or ASCII-compatible) encoding is used you <em>still</em> need to read the encoding to find out which one is actually use (valid candidates would be ASCII, UTF-8, any of the <a href="http://en.wikipedia.org/wiki/ISO/IEC_8859" rel="noreferrer">ISO-8859-* encodings</a>, any of the <a href="http://en.wikipedia.org/wiki/Windows_code_page" rel="noreferrer">Windows-*</a> encodings, <a href="http://en.wikipedia.org/wiki/KOI8-R" rel="noreferrer">KOI8-R</a> and many, many others). For the <code>&lt;?xml</code> part itself it won't make a difference which one it is, but for the rest of the document, it can make a huge difference.</p> <p>Regarding mis-labeled XML files: yes, it's easy to produce those, <strong>however</strong>: the XML spec clearly specifies that those files are mal-formed and as such are not correct XML. Incorrect encodings must be reported as an error (as long as they can be detected!). So it's the problem of whoever is producing the XML.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload