Is there any difference in behaviour of below URL.
I don't know why the & is inserted, does it make any difference ?
www.testurl.com/test?param1=test¤t=true
versus
www.testurl.com/test?param1=test¤t=true
& is HTML for "Start of a character reference".
& is the character reference for "An ampersand".
¤t; is not a standard character reference and so is an error (browsers may try to perform error recovery but you should not depend on this).
If you used a character reference for a real character (e.g. ™) then it (™) would appear in the URL instead of the string you wanted.
(Note that depending on the version of HTML you use, you may have to end a character reference with a ;, which is why &trade= will be treated as ™. HTML 4 allows it to be ommited if the next character is a non-word character (such as =) but some browsers (Hello Internet Explorer) have issues with this).
HTML doesn't recognize the & but it will recognize & because it is equal to & in HTML
I looked over this post someone had made: http://www.webmasterworld.com/forum21/8851.htm
My Source: http://htmlhelp.com/tools/validator/problems.html#amp
Another common error occurs when including a URL which contains an
ampersand ("&"):
This is invalid:
a href="foo.cgi?chapter=1§ion=2©=3&lang=en"
Explanation:
This example generates an error for "unknown entity section" because
the "&" is assumed to begin an entity reference. Browsers often
recover safely from this kind of error, but real problems do occur in
some cases. In this example, many browsers correctly convert ©=3
to ©=3, which may cause the link to fail. Since 〈 is the HTML
entity for the left-pointing angle bracket, some browsers also convert
&lang=en to 〈=en. And one old browser even finds the entity §,
converting §ion=2 to §ion=2.
So the goal here is to avoid problems when you are trying to validate your website. So you should be replacing your ampersands with & when writing a URL in your markup.
Note that replacing & with & is only done when writing the URL in
HTML, where "&" is a special character (along with "<" and ">"). When
writing the same URL in a plain text email message or in the location
bar of your browser, you would use "&" and not "&". With HTML, the
browser translates "&" to "&" so the Web server would only see "&"
and not "&" in the query string of the request.
Hope this helps : )
That's a great example. When ¤t is parsed into a text node it is converted to ¤t. When parsed into an attribute value, it is parsed as ¤t.
If you want ¤t in a text node, you should write ¤t in your markup.
The gory details are in the HTML5 parsing spec - Named Character Reference State
if you're doing a string of characters.
make:
let linkGoogle = 'https://www.google.com/maps/dir/?api=1';
let origin = '&origin=' + locations[0][1] + ',' + locations[0][2];
aNav.href = linkGoogle + origin;
Related
This question already has answers here:
Is a URL allowed to contain a space?
(10 answers)
Closed 8 years ago.
w3fools claims that URLs can contain spaces: http://w3fools.com/#html_urlencode
Is this true? How can a URL contain an un-encoded space?
I'm under the impression the request line of an HTTP Request uses a space as a delimiter, being formatted as {the method}{space}{the path}{space}{the protocol}:
GET /index.html http/1.1
Therefore how can a URL contain a space? If it can, where did the practice of replacing spaces with + come from?
A URL must not contain a literal space. It must either be encoded using the percent-encoding or a different encoding that uses URL-safe characters (like application/x-www-form-urlencoded that uses + instead of %20 for spaces).
But whether the statement is right or wrong depends on the interpretation: Syntactically, a URI must not contain a literal space and it must be encoded; semantically, a %20 is not a space (obviously) but it represents a space.
They are indeed fools. If you look at RFC 3986 Appendix A, you will see that "space" is simply not mentioned anywhere in the grammar for defining a URL. Since it's not mentioned anywhere in the grammar, the only way to encode a space is with percent-encoding (%20).
In fact, the RFC even states that spaces are delimiters and should be ignored:
In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may
have to be added to break a long URI across lines. The whitespace
should be ignored when the URI is extracted.
and
For robustness, software that accepts user-typed URI should attempt
to recognize and strip both delimiters and embedded whitespace.
Curiously, the use of + as an encoding for space isn't mentioned in the RFC, although it is reserved as a sub-delimeter. I suspect that its use is either just convention or covered by a different RFC (possibly HTTP).
Spaces are simply replaced by "%20" like :
http://www.example.com/my%20beautiful%20page
The information there is I think partially correct:
That's not true. An URL can use spaces. Nothing defines that a space is replaced with a + sign.
As you noted, an URL can NOT use spaces. The HTTP request would get screwed over. I'm not sure where the + is defined, though %20 is standard.
I have a web service which uses the WCF web api to create RESTful service. This serivce expects many different values in the url path seperated with a comma. This method works perfectly for simple data e.g. someones name or a numeric value. However I have a field on the client side (a java based BlackBerry app) which allows a user to freely type data which includes characters such as . or / which messes up my whole url.
Even when I replace the characters with their hex values e.g. a / to %2F the problem persists.
Does anyone know a means to either represent these characters in a URL which will be ignored when looking for the address or better yet a means to tell the URL the following characters are to be ignored perhaps in the way quotation marks would work?
You can use encode url function. URL Encoding is the process of converting string into valid URL format. Valid URL format means that the URL contains only what is termed alpha | digit | safe | extra | escape characters.
I am using NSXMLParsing to parse an XML , whose formatting is not in my control
From XML it seems it's using UTF-8 encoding, however i get illegal character encoding error when a character like '&' comes into picture.
Due to this i have to go the dirty way of breaking strings and parsing.
Any way out?
Suggestions ?
Thanks
Yogurt
It sounds like you have malformed XML. "&" is the start of an entity in XML, e.g. & or <. Having a raw "&" by itself that doesn't match an entity is illegal.
Apologies if this has been answered already. There are similar topics but none that I could find pertaining to Cocoa & NSStrings...
I'm constructing a clickable URL to embed in an HTML email to be sent via the MFMailComposeViewController on the iPhone. i create the url then use stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding to polish up white space, etc. then add some surrounding HTML to get:
view
All's well so it's appended to emailBody. However once [mailComposer setMessageBody:emailBody isHTML:YES] all the & become & which isn't ideal within my URL.
can i control this? is there a better encoding algorithm? my HTML is a bit rusty perhaps I'm using the wrong encoding? I'm sure on the server I could parse the & back into & but looking for the Cocoa way...
Thanks!
Actually, & should always be encoded as & in HTML attributes. Including links. Including form value delimiters. So it's done exactly what you want, even though you didn't know you wanted it.
Look at it this way: in your URL, you have &age=53... That's interpreted first as a character entity, and only after that doesn't work is it interpreted as an ampersand followed by more character data.
The W3C spec is quite clear on this:
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.
That should settle it: use & not &.
Are you calling MFMailComposeViewController's
setMessageBody:isHTML:
and what do you set isHTML to?
Depending on it's setting it might very well be that MFMailComposeViewController is trying to help you out be encoding the entire message body...
Either don't encode the body yourself or make the entire body HTML.
I'm using XML Serialization heavily in a web service (the contracts pass complex types as params). Recently I noticed that the .Net XML Serialization engine is escaping some of the well known 5 reserved characters that must be escaped when included within an element (<, >, &, ' and "). My first reaction was "good old .Net, always looking out for me".
But then I started experimenting and noticed it is only escaping the <, > and &, and for some reason not the apostrophy and double quotes. For example if I return this literal string in a field within a complex type from my service:
Bad:<>&'":Data
This is what is transferred over the wire (as seen from Fiddler):
Bad:<>&'":Data
Has anyone run into this or understand why this is? Is the serializer simply overlooking them or is there a reason for this? As I understand it the ' and " are not by spec valid within an xml element.
According to the XML spec, for regular content and markup:
& always needs to be escaped as & because it's the escape character
< always needs to be escaped as < since it determines the start of an element. It even has to be escaped within attributes as a safety and to make writing parser error detection simpler.
> does not need to be escaped as > but often is for symmetry with <
' needs to be escaped as ' only if in an attribute delimited by '
" needs to be escaped as " only if in an attribute delimited by "
Inside of processing instructions, comments and CDATA sections, the rules change some, but the details are in the 2.4 Character Data and Markup portion of the spec.
Your serializer is trying to do you a favor by keeping the file somewhat human-readable.
(Each of the above may also be escaped using their numeric equivalents.)
XMLSpy says you're wrong. The following is well-formed XML:
<root>
<data>'"</data>
</root>
Aside from "argument by reference to XMLSpy", a better argument is that the XML Serializer has been out in the wild for over seven years. In this time, I guarantee someone has tried to serialize "O'Brien" in a Name property. This bug would have been noticed by now.