StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Note: firefox (in my test) does not unescape in text areas as you describe. Specifically, this code:</p> <pre><code><textarea cols="80" rows="10" id="1"></textarea> <script> elem = document.getElementById("1"); elem.value = '\ <Configuration>\n\ <Validator Expression="[^&lt;]" />\n\ </Configuration>\ ' alert(elem.value); </script> </code></pre> <p>Is alerted and displayed to the user <em>unchanged</em>, as:</p> <pre><code><Configuration> <Validator Expression="[^&lt;]" /> </Configuration> </code></pre> <p>So maybe one (un-viable?) solution is for your users to use firefox.</p> <hr> <p>It seems two parts to your question have been revealed:</p> <p>1 <strong>XML that you display is getting unescaped.</strong></p> <p>For example, "<code>&lt;</code>" is unescaped as "<". But since "<" is also unescaped as "<", information is lost and you can't get it back.</p> <p>One solution is for you to escape all the "<code>&</code>" characters, so that "<code>&lt;</code>" becomes "<code>&amp;lt;</code>". This will then be unescaped by the textarea as "<code>&lt;</code>". When you read it back, it will be as it was in the first place. (I'm assuming that the textarea actually changes the string, but firefox isn't behaving as you report, so I can't check this)</p> <p>Another solution (mentioned already I think) is to build/buy/borrow a custom text area (not bad if simple, but there's all the editing keys, ctrl-C, ctrl-shift-left and so on).</p> <p>2 <strong>You would like users to not have to bother escaping.</strong></p> <p>You're in escape-hell:</p> <p>A regex replace will mostly work... but how can you reliably detect the end quote ("), when the user might (legitimately, within the terms you've given) enter :</p> <pre><code><Configuration> <Validator Expression="[^"<]" /> </Configuration> </code></pre> <p>Looking at it from the point of view of the regex syntax, it also can't tell whether the final " is part of the regex, or the end of it. Regex syntax usually solves this problem with an explicit terminator eg:</p> <pre><code>/[^"<]/ </code></pre> <p>If users used this syntax (with the terminator), and you wrote a parser for it, then you could determine when the regex has ended, and therefore that the next " character is not part of the regex, but part of the XML, and therefore which parts need to be escaped. I'm not saying you should this! I'm saying it's theoretically possible. It's pretty far from quick and dirty.</p> <p>BTW: The same problem arises for text within an element. The following is legitimate, within the terms you've given, but has the same parsing problems:</p> <pre><code><Configuration> <Expression></Expression></Expression> </Configuration> </code></pre> <p>The basic rule in a syntax that allows "any text" is that the delimiter <em>must</em> be escaped, (e.g. " or <), so that the end can be recognized. Most syntax also escapes a bunch of other stuff, for convenience/inconvenience. (<em>EDIT</em> it will need to have an escape for the escape character itself: for XML, it is "<code>&</code>", which when literal is escaped as "<code>&amp;</code>" For regex, it is the C/unix-style "<code>\</code>", which when literal is escaped as "<code>\\</code>").</p> <p>Nest syntaxes, and you're in escape-hell.</p> <p>One simple solution for you is to tell your users: this is a <strong>quick</strong> and <strong>dirty</strong> configuration editor, so you're not getting any fancy "no need to escape" mamby-pamby:</p> <ul> <li>List the characters and escapes next to the text area, eg: "<" as "<code>&lt</code>".</li> <li>For XML that won't validate, show them the list again.</li> </ul> <hr> <p>Looking back, I see <a href="https://stackoverflow.com/questions/244285/how-the-heck-can-you-edit-valid-xml-in-a-webpage/246652#246652">bobince</a> gave the same basic answer before me.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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