I have a simple search form
<form id="search" name="search" method="GET" action="search.php" enctype="application/x-www-form-urlencoded">
But this form doesn't encode all chars in a URL, ' isn't encoded to %27, shouldn't this be done automatically?
This is rather funny.. On the HTML specification it states that all Non-alphanumeric characters are represented by %HH (according to RFC 1738, Section 2.2). But if you actually go to the RFC1738, Section 2.2 has the following:
Thus, only alphanumerics, the special
characters "$-_.+!*'(),", and
reserved characters used for their
reserved purposes may be used
unencoded within a URL.
But Chrome seems to follow the specification to the letter, where as IE and Firefox choose to not encode those characters..
Related
I have this pattern for an input text field: /[\p{L}\'.\- ]{3,30}/ My intention is to accept the most broadly names of people on several alphabets of the world (Latin, Cyrillic, Chinese, etc.) It was tested in Regex101 and it works great. On other testers it doesn't work but my main issue comes as follows:
<form action="mailto:myemail#emailserver.com" id="formula" method="post" enctype="multipart/form-data"
name="formname" class="form-group pt-3" autocomplete="on" ng-submit="register()" novalidate>
<input type="text" name="nombre" ng-pattern="/[\p{L}\'.\- ]{3,30}/">
Here's my code for you to check: https://regex101.com/r/gOvO2M/8
It skips special characters, skips symbols, skips numbers, but when I see the live HTML in the browser, it doesn’t work properly.
In the error message, for validation purposes, I put:
<p class="formu-error" ng-show="formname.nombre.$touched && formname.nombre.$invalid">Please, write a valid name.</p>
The problem is when testing, I write only letters (no spaces, no hyphen because all that is optional) and still giving me the message of the error. Why?
Maybe because I am using \p{L} and that will work only in the server, when I code the server validation in PHP?
You can use
<input type="text" name="nombre" ng-pattern="/^(?=.{3,30}$)\p{L}+(?:['.\s-]\p{L}+)*$/u" ng-trim="false" />
Note the u flag, it enables the Unicode category (property) classes support in JavaScript with the ECMAScript 2018+ support.
Also, ng-trim="false" will prevent trimming whitespace before passing the input to the regex engine.
The regex means:
^ - start of string
(?=.{3,30}$) - the string must consist of 3 to 30 chars other than line break chars
\p{L}+ - one or more Unicode letters
(?:['.\s-]\p{L}+)* - zero or more repetitions of
['.\s-] - a ', ., whitespace or -
\p{L}+ - one or more Unicode letters
$ - end of string.
See the regex demo.
.*(\d{3}\-\d{3}\-\d{2}\-\d{2}|\d{3}\-\d{2}\-\d{2}\-\d{3}|\d{10}).* this pattern was working fine. But suddenly it stop working in chrome and opera lately. What's going on here ? What a problem is here and how it's wrong? Opera is informing about invalid escape, same in chrome. It works fine when im checking it in js.
<form>
<input type="text" pattern=".*(\d{3}\-\d{3}\-\d{2}\-\d{2}|\d{3}\-\d{2}\-\d{2}\-\d{3}|\d{10}).*">
<button>
Send
</button>
</form>
The point is that Chrome and Firefox already support ES6 regex specifications and support the Unicode mode by default.
Unicode patterns have stricter rules as to what characters can be escaped inside the pattern. See this reference:
IdentityEscape: In BMP patterns, many characters can be prefixed with a backslash and are interpreted as themselves (for example: if \u is not followed by four hexadecimal digits, it is interpreted as u). In Unicode patterns that only works for the following characters (which frees up \u for Unicode code point escapes): ^ $ \ . * + ? ( ) [ ] { } |
The same set of chars is referred to as SyntaxCharacter in the ES6 specs page.
So, you can only escape the - inside the character class where it is considered a special character and to make it a literal you can escape it. Everywhere else it must not be escaped.
<form>
<input type="text" pattern=".*(\d{3}-\d{3}-\d{2}-\d{2}|\d{3}-\d{2}-\d{2}-\d{3}|\d{10}).*">
<input type=Submit>
</form>
Try to use below concept to implement to validate the date format
<form onsubmit="alert('Submitted.');return false;"><input required="" pattern="(0[1-9]|1[0-9]|2[0-9]|3[01]).(0[1-9]|1[012]).[0-9]{4}" value="" name="dates_pattern0" id="dates_pattern0" list="dates_pattern0_datalist" placeholder="Try it out." type="text"><input value="»" type="submit"></form>
you can find more validations by this link - http://html5pattern.com/Dates
This is related to the same problem as this question:
Firefox error: Unable to check input because the pattern is not a valid regexp: invalid identity escape in regular expression
When using escaped characters in the <input> pattern attribute, Firefox throws these errors to the console:
Unable to check <input
pattern='^[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEFa-zA-Z\s\'-]{1,50}$'>
because the pattern is not a valid regexp: invalid identity escape in
regular expression
So when using the pattern attribute on an <input> field, the unicode characters no longer need to be escaped. In that case the user simply needs to stop escaping their characters and change \#\% to #%, problem solved.
I've got this somewhat more complicated regex pattern, what do I change it to to work in Firefox?
<input type="text" pattern="^[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEFa-zA-Z\s\'-]{1,50}$">
Essentially it's allowing for any string between 1..50 characters in length as long as all the characters are within these ranges:
\u00A0-\uD7FF
\uF900-\uFDCF
\uFDF0-\uFFEF
a-z
A-Z
as well as whitespace, apostrophes and hyphens. A quick search sees the \u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEFa part of it fairly widely used in all sorts of regexes. I just don't see exactly what to use instead of the escaped unicode character references here.
You need to remove the escaping backslash before the single quote.
Note that in a regular HTML5 pattern field, one does not have to use ^ and $ anchors at the pattern start/end as the HTML5 pattern attribute encloses the passed pattern with ^(?: and )$. However, as per your feedback, the Abide validation circumvents this and passes unanchored pattern to the regex engine. Thus, you should keep the anchors.
<input type="text" pattern="^[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEFa-zA-Z\s'-]{1,50}$">
A quick demo:
<form>
<input type="text" pattern="[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEFa-zA-Z\s'-]{1,50}">
<input type="submit">
</form>
Well, I know that "correct" escaping will help to prevent SQL injection.
But I saw people escaping values in HTML
<input type="text" value =/"some/" /> <!-- some escaped, why? -->
Question is:
Why to escape in HTML?
<input type="text" value =/"some/" /> <!-- some escaped, why? -->
That is a syntax error. Don't do that.
Use character references to represent special characters (&, <, etc).
Why to escape in HTML?
(Assuming you use the correct syntax to do so): because some characters have special meaning in HTML. For example, you don't want a " (in the data) ending your attribute value prematurely since that can:
Lose data
Lose data but have it display in the page
Allow third parties to inject their JavaScript into your pages and steal data / redirect people to phishing sites / etc
I need to post multi-line data via a hidden field. The data will be viewed in a textarea after post. How can I post a newline/carriage return in the html form?
I've tried \r\n but that just posts the actual "\r\n" data
<input type="hidden" name="multiline_data" value="line one\r\nline two" />
Is there a way to do this?
Instead of using
<input type="hidden">
Try using
<textarea style="visibility:hidden;position:absolute;">
While new lines (Carriage Return & Line Feed) are technically allowed in <input>'s hidden state, they should be escaped for compatibility with older browsers. You can do this by replacing all Carriage Returns (\u000D or \r) and all Line Feeds (\u000A or \n) with proprietary strings that are recognized by your application to be a Carriage Return or New Line (and also escaped, if present in the original string).
Simply character entities don't work here, due to non-conforming browsers possibly knowing
and
are new lines and stripping them from the value.
Example
For example, in PHP, if you were to echo the passed value to a textarea, you would include the newlines (and unescaped string).
<textarea>Some text with a \ included
and a new line with \r\n as submitted value</textarea>
However, in PHP, if you were to echo the value to the value attribute of an <input> tag, you would escape the new lines with your proprietary strings (e.g. \r and \n), and escape any instances of your proprietary strings in the submitted value.
<input type="hidden" value="Some text with a \\ included\r\nand a new line\\r\\n as submitted value">
Then, before using the value elsewhere (inserting into a database, emailing, etc), be sure to unescape the submitted value, if necessary.
Reassurance
As further reassurance, I asked the WHATWG, and Ian Hickson, editor of the HTML spec currently, replied:
bfrohs Question about <input type=hidden> -- Are Line Feeds and Carriage Returns allowed in the value? They are specifically disallowed in Text state and Search state, but no mention is made for Hidden state. And, if not, is there an acceptable HTML solution for storing form data from a textarea?
Hixie yes, they are allowed // iirc // for legacy reasons you may wish to escape them though as some browsers normalise them away // i forget if we fixed that or not // in the spec
Source
Depends on the character set really but
should be linefeed and
should be carriage return. You should be able to use those in the value attribute.
You don't say what this is for or what technology you're using, but you need to be aware that you can't trust the hidden field to remain with value="line one
line two", because a hostile user can tamper with it before it gets sent back in the POST. Since you're putting the value in a <textarea> later, you will definitely be subject to, for example, cross site scripting attacks unless you verify and/or sanitize your "multiline_data" field contents before you write it back out.
When writing a value into a hidden field and reading it back, it's usually better to just keep it on the server, as an attribute of the session, or pageflow, or whatever your environment provides to do this kind of thing.