I get this error in the validator:
Line 47, Column 187: character "&" is the first character of a delimiter but occurred as data
…num, silver diamonds. cartier tiffany & Co. $18 WALKING LIBERTY DOLLARS $15…
This message may appear in several cases:
You tried to include the "<" character in your page: you should escape it as "<"
You used an unescaped ampersand "&": this may be valid in some contexts, but it is recommended to use "&", which is always safe.
Another possibility is that you forgot to close quotes in a previous tag.
How to settle it?
You forgot to escape an ampersand.
Replace & with &.
Related
As I put in the title I need a validator (regular expresion, customvalidator, etc) that allows the user to input everything (lettrs, special characters, spaces) but not numbers.
Valid string would be "D'Elia" or "Del Riego" Not Valid String would be " " or "p1" or "1" So I have to allow all letters, all special characters including space, no numbers, and not spaces at the beginning (well, al least that the field doesn't allow that only one space and nothing more can be written)
How can I do that?
Thank you,
Sabrina
You need to use a positive lookahead at the start to check for atleast one letter.
^(?=.*?[A-Za-z])[^0-9]+$
For example, in Unix, a backslash (\) is a common escape character. So to escape a full stop (.) in a regular expression, one does this:
\.
But with % encoding URL parameters, we have an escape character, %, and a control code, so an ampersand (&) doesn't become:
%&
Instead, it becomes:
%26
Any reason why? Seems to just make things more complicated, on the face of it, when we could just have one escape character and a mechanism to escape itself where necessary:
%%
Then it'd be:
simpler to remember; we just need to know which characters to escape, not which to escape and what to escape them to
encoding-agnostic, as we wouldn't be sending an ASCII or Unicode representation explicitly, we'd just be sending them in the encoding the rest of the URL is going in
easy to write an encoder: s/[!\*'();:#&=+$,/?#\[\] "%-\.<>\\^_`{|}~]/%&/g (untested!)
better because we could switch to using \ as an escape character, and life would be simpler and it'd be summer all year long
I might be getting carried away now. Someone shoot me down? :)
EDIT: replaced two uses of "delimiter" with "escape character".
Percent encoding happens not only to escape delimiters, but also so that you can transport bytes that are not allowed inside URIs (such as control characters or non-ASCII characters).
I guess it's because the URL Specification and specifically the HTTP part of it, only allow certain characters so to escape those one must replace them with characters that are allowed.
Also some allowed characters have special meanings like & and ? etc
so replacing them with a control code seems the only way to solve it
If you find it hard to recognize them, bookmark this page
http://www.w3schools.com/tags/ref_urlencode.asp
A colon cannot be used in the ID of a .NET control. I quote from the following website: http://msdn.microsoft.com/en-us/library/system.web.ui.control.id.aspx
"Only combinations of alphanumeric characters and the underscore character ( _ ) are valid values for this property. Including spaces or other invalid characters will cause an ASP.NET page parser error."
Is there a reason why alphanumeric characters have to be used?
Easy to find on MSN...
Only combinations of alphanumeric characters and the underscore character ( _ ) are valid values for this property. Including spaces or other invalid characters will cause an ASP.NET page parser error.
As for why, I cannot give an answer, other than it makes sense to me as a developer that you never use anything other than alphanumerics and underscores for variable names. There's no obvious reason why that should not extend to control IDs as well.
I have a restful webservice which receives some structured data which is put straight into a database.
The data is send from an OS using wget. I am just wondering whether I actually need to URL encode the data and if so why? Please note that it is no problem to do it but it might be uneccessary in this scenario.
If your data has characters that aren't allowed in urls, you should url encode it.
The following characters are either reserved (like &) or just present the possibility of confusing code. If your data contains these characters, urlencode it. Remember if you are using any extended ascii characters, unicode characters or non-printable characters you should url-encode your data.
Dollar ("$")
Ampersand ("&")
Plus ("+")
Comma (",")
Forward slash/Virgule ("/")
Colon (":")
Semi-colon (";")
Equals ("=")
Question mark ("?")
'At' symbol ("#")
Space
Quotation marks
'Less Than' symbol ("<")
'Greater Than' symbol (">")
'Pound' character ("#")
Percent character ("%")
Left Curly Brace ("{")
Right Curly Brace ("}")
Vertical Bar/Pipe ("|")
Backslash ("\")
Caret ("^")
Tilde ("~")
Left Square Bracket ("[")
Right Square Bracket ("]")
Grave Accent ("`")
More info can be found here: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
I am using BizTalk 2009 and I have a flat file that is similar to the following
"0162892172","TIM ","LastName ","760 "," ","COMANCHE ","LN "
"0143248282","GEORGE ","LastName ","625 "," ","ENID ","AVE "
When I parse it and start mapping it I need to get rid of the quotation marks. I have marked the Wrap Character attribute for the schema as a quotation mark but it doesn't remove it when BizTalk is parsing the file.
Is there an easy way to specify the removal of a wrap character or am I going to have to run it through a script functiod every time? Also I would like to be able to remove the trailing spaces as well, if at all possible.
If you're still seeing the quotes after parsing, it likely means you set the wrap character property incorrectly. Are you sure you also set Wrap Character Type == Character?
As for the extra spaces, those will be hard to get rid of during parsing, because the quotes would specifically tell bts that they were intentional, so yeah, your best bet is to probably remove those during mapping or whatever.
this page seems to suggest that removing the trailing spaces can be done with:
> Pad Character Type = Hexadecimal
> Pad Character = 0x20