I was reading the documentation for HtmlAttributeEncode, which as I understand it is intended for use when rendering HTML that appears within double quotes as an attribute, e.g.
<INPUT Value="This value must be escaped so that it doesn't contain any quotes">
As far as I can tell, the only character I would need to escape would be the double quote. The browser ought to be able to figure out everything else in that string belongs within the attribute.
Why, then, does the documentation say this?
The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities. It is considerably faster than the HtmlEncode method.
And in fact it does escape those, as can be seen by this poor guy.
is there any reason to escape the < and & characters in this circumstance? is it required by the HTML5 specification?
With my human eye I can easily see where the delimitation begins and ends in this character sequence:
<INPUT value="You & I can both easily see that 5 < 6!">
As long as the double quote sequence is properly closed (and double quotes are escaped) I don't understand why the other characters have to be HTML-encoded.
From the specs:
3.2.3.1 Attributes
Except where otherwise specified, attributes on HTML elements may have any string value, including the empty string. Except where explicitly stated, there is no restriction on what text can be specified in such attributes.
According to specs of html4, the content of the value attribute should be in the type of cdata.
From the HTML Document Representation:
5.3.2 Character entity references
Four character entity references deserve special mention since they are frequently used to escape special characters:
"<" represents the < sign.
">" represents the > sign.
"&" represents the & sign.
""" represents the " mark.
Authors wishing to put the "<" character in text should use "<" (ASCII decimal 60) to avoid possible confusion with the beginning of a tag (start tag open delimiter). Similarly, authors should use ">" (ASCII decimal 62) in text instead of ">" to avoid problems with older user agents that incorrectly perceive this as the end of a tag (tag close delimiter) when it appears in quoted attribute values.
Authors should use "&" (ASCII decimal 38) instead of "&" to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use "&" in attribute values since character references are allowed within CDATA attribute values.
Related
I've noticed that C# adds additional slashes (\) to paths. Consider the path C:\Test. When I inspect the string with this path in the text visualiser, the actual string is C:\\Test.
Why is this? It confuses me, as sometimes I may want to split the path up (using string.Split()), but have to wonder which string to use (one or two slashes).
The \\ is used because the \ is an escape character and is need to represent the a single \.
So it is saying treat the first \ as an escape character and then the second \ is taken as the actual value. If not the next character after the first \ would be parsed as an escaped character.
Here is a list of available escape characters:
\' - single quote, needed for character literals
\" - double quote, needed for string literals
\\ - backslash
\0 – Null
\a - Alert
\b - Backspace
\f - Form feed
\n - New line
\r - Carriage return
\t - Horizontal tab
\v - Vertical quote
\u - Unicode escape sequence for character
\U - Unicode escape sequence for surrogate pairs.
\x - Unicode escape sequence similar to "\u" except with variable length.
EDIT: To answer your question regarding Split, it should be no issue. Use Split as you would normally. The \\ will be treated as only the one character of \.
.Net is not adding anything to your string here. What your seeing is an effect of how the debugger chooses to display strings. C# strings can be represented in 2 forms
Verbatim Strings: Prefixed with an # sign and removes the need o escape \\ characters
Normal Strings: Standard C style strings where \\ characters need to escape themselves
The debugger will display a string literal as a normal string vs. a verbatim string. It's just an issue of display though, it doesn't affect it's underlying value.
Debugger visualizers display strings in the form in which they would appear in C# code. Since \ is used to escape characters in non-verbatum C# strings, \\ is the correct escaped form.
Okay, so the answers above are not wholly correct. As such I am adding my findings for the next person who reads this post.
You cannot split a string using any of the chars in the table above if you are reading said string(s) from an external source.
i.e,
string[] splitStrings = File.ReadAllText([path]).Split((char)7);
will not split by those chars. However internally created strings work fine.
i.e.,
string[] splitStrings = "hello\agoodbye".Split((char)7);
This may not hold true for other methods of reading text from a file. I am unsure as I have not tested with other methods. With that in mind, it is probably best not to use those chars for delimiting strings!
I am doing some string replacement within a Word Docx file using OpenXML Power Tools and it is working as expected. However things break when I have invalid characters in the substitution such as ampersand, so for instance "Harry & Sally" will break and produce an invalid document. According to this post illegal characters need to be converted to xHHHH.
I am having trouble finding the contents to the OOXML clause mentioned in the post and hence escaping characters appropriately.
I am hoping someone either has some code or insights into exactly what characters need to be escaped. I was also hopeful OpenXML Power Tools could do this for me in some way, but I cannot seem to find anything in there either.
The specification is just talking about the standard set of characters that have to be escaped in XML. The XML specification mentioned in the linked post is the one from the W3C, found here.
There are five characters that need to be escaped anywhere they appear in XML data (names, values, etc) unless they are part of a CDATA section. According to Section 2.4:
The ampersand character (&) and the left angle bracket (<) must not appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they must be escaped using either numeric character references or the strings " & " and " < " respectively. The right angle bracket (>) may be represented using the string " > ", and must, for compatibility, be escaped using either " > " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.
To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as " ' ", and the double-quote character (") as " " ".
In other words, escape the following characters:
' -> '
" -> "
> -> >
< -> <
& -> &
Typically, you wouldn't encode these as xHHHH, you'd use the XML entities listed above, but either is allowed. You also don't need to encode quotes or the right-angle bracket in every case, only when they would otherwise represent XML syntax, but it's usually safer to do it all the time.
The XML specification also includes the list of every Unicode character that can appear in an XML document, in section 2.2:
Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
That list includes basically every Unicode character in the Basic plane (every one you're likely to run into), except for the control characters. Only the tab, CR, and LF characters are allowed -- any other character below ASCII 32 (space) needs to be escaped.
The big gap in the list (0xD800-0xDFF) is for surrogate encoding values, which shouldn't appear by themselves anyway, as they're not valid characters. The last two, 0xFFFE and 0xFFFF, are also not valid characters.
I created an extension method with help from Michael Edenfield's answer. Pretty self explanatory... just make sure you replace the ampersands first! Otherwise you will end up replacing your other escaped symbols by mistake.
public static string EscapeXmlCharacters(this string input)
{
switch (input)
{
case null: return null;
case "": return "";
default:
{
input = input.Replace("&", "&")
.Replace("'", "'")
.Replace("\"", """)
.Replace(">", ">")
.Replace("<", "<");
return input;
}
}
}
.NET Fiddle: https://dotnetfiddle.net/PCqffy
Ive searched all over the web for a simple solution to my problem, but I find it weird that no one has some up with a way to "get a correct connection string if the password contains non-alphanumeric characters".
My problem:
I have a user which has a password containing one or more of these characters:
` ~ ! # # $ % ^ & * ( ) _ + - = { } | \ : " ; ' < > ? , . /
since the connectionstring format is "KEY=VALUE;KEY2=VALUE2" it turns out to be a problem if the password contains a semi-colon of course.
So I did a little research and found these "connectionstring-rules"
All blank characters, except those placed within a value or within quotation marks, are ignored
Blank characters will though affect connection pooling mechanism, pooled connections must have the exact same connection string
If a semicolon (;) is part of a value it must be delimited by quotation marks (")
Use a single-quote (') if the value begins with a double-quote (")
Conversely, use the double quote (") if the value begins with a single quote (')
No escape sequences are supported
The value type is not relevant
Names are case iNsEnSiTiVe
If a KEYWORD=VALUE pair occurs more than once in the connection string, the value associated with the last occurrence is used
However, if the provider keyword occurs multiple times in the string, the first occurrence is used.
If a keyword contains an equal sign (=), it must be preceded by an additional equal sign to indicate that it is part of the keyword.
If a value has preceding or trailing spaces it must be enclosed in single- or double quotes, ie Keyword=" value ", else the spaces are removed.
I then read a bunch of thread where people are trying to implement the above mentioned things into their "Format connectionstring method", but it seemed like even more scenarios came to light when they began.
My question is then:
Is there someone out there who has made a "FormatConnectionstring" method to use in a connectionstring - or am I doing something completely wrong here and my problem really exists elsewhere?
Use SqlConnectionStringBuilder; either:
set properties, read ConnectionString (to create)
set ConnectionString, read properties (to parse)
I've inherited some C# code with the following regular expression
Regex(#"^[a-zA-Z''-'\s]{1,40}$")
I understand this string except for the role of the single quotes. I've searched all over but can't seem to find an explanation. Any ideas?
From what I can tell, the expression is redundant.
It matches a-z or A-Z, or the ' character, or anything between ' and ' (which of course is only the ' character again, or any whitespace.
I've tested this using RegexPal and it doesn't appear to match anything but these characters. Perhaps the sequence was generated by code, or it used to match a wider range of characters in an earlier version?
UPDATE: From your comments (matching a name), I'm gonna go ahead and guess the author thought (s)he was escaping a hyphen by putting it in quotes, and wasn't the most stellar software tester. What they probably meant was:
Regex(#"^[a-zA-Z'\-\s]{1,40}$") //Escaped the hyphen
Which could also be written as:
Regex(#"^[a-zA-Z'\s-]{1,40}$") //Put the hyphen at the end where it's not ambiguous
The only way having the apostrophe / single quote three times makes sense is if the second and third instances are actually fancy curly single quotes such as ‘, ’, and ‛. If so a better (clearer) way to represent it would be to use the unicode escapes:
Regex(#"^[a-zA-Z'\u2018-\u201B\s]{1,40}$")
Incidentally some languages, such as PowerShell, explicitly allow these curly single quotes and treat them the same as the ASCII ' (0x27) character. From the PowerShell 2.0 Language Specification:
single-quote-character:
' (U+0027)
Left single quotation mark (U+2018)
Right single quotation mark (U+2019)
Single low-9 quotation mark (U+201A)
Single high-reversed-9 quotation mark (U+201B)
As it is the three single quote characters are redundant. They represent the single quote character (#1) and the range of characters which both begins and ends at the single quote (#2 and #3 separated by a hyphen).
It looks like it is an error, the writer seems to have meant to include the hyphen character in the class by "escaping" it in single quotes. Without escaping it the hyphen represents a character range, like in a-z and A-Z.
I'm guessing the original author meant [a-zA-Z'\-\s]
The extra apostrophes are redundant, so it doesn't make much sense. One possibility is that the author tried to escape the dash to include it in the pattern, but the correct way to do that would be to use a backslash:
Regex(#"^[a-zA-Z'\-\s]{1,40}$")
(Using apostrophes around a literal is for example used in custom format strings, where the author might have picked it up.)
I want to clean strings that are retrieved from a database.
I ran into this issue where a property value (a name from a database) had an embedded TAB character, and Chrome gave me an invalid TOKEN error while trying to load the JSON object.
So now, I went to http://www.json.org/ and on the side it has a specification. But I'm having trouble understanding how to write a cleanser using this spec:
string
""
" chars "
chars
char
char chars
char
any-Unicode-character-
except-"-or--or-
control-character
\"
\\
/
\b
\f
\n
\r
\t
\u four-hex-digits
Given a string, how can I "clean" it such that I conform to this spec?
Specifically, I am confused: does the spec allow TAB (0x0900) characters? If so, why did Chrome given an invalid TOKEN error?
Tab characters (actual 0x09, not escapes) cannot appear inside of quotes in JSON (though they are valid whitespace outside of quotes). You'll need to escape them with \t or \u0009 (the former being preferable).
json.org says an unescaped character of a string must be:
Any UNICODE character except " or \ or
control character
Tab counts as a control character.
This maybe what you are looking for it shows how to use the JavaScriptSerializer class in C#.
How to create JSON String in C#