Tag Info

Hot answers tagged

21

The plus is used to encode spaces in URLs, not in HTML and not in SMTP (RFC2821). However, since mailto:address@server.com is a URI (it has a protocol, the protocol separator and the protocol address) then it should be treated as a URI and it should be percent encoded. Therefore, it is up to the client to resolve accurately the encoded representation and to ...


7

A strict reading of the relevant RFC says that the "+" should be encoded. Section 2, top of page 2 on http://tools.ietf.org/html/rfc2368 says: "Note that all URL reserved characters in "to" must be encoded: in particular, parentheses, commas, and the percent sign ("%"), which commonly occur in the "mailbox" syntax." The RFC for URIs ...


6

URLEncode is meant to encode characters that have special meanings in URLs (like colons, question marks, slashes etc.). You should only apply URLEncode to the values you wish to encode in your URL, not to the entire URL. E.g. Suppose I have the following URL: http://example.com/search.php?query=VALUE As it stands, no escaping is necessary. But suppose ...


6

You MAY encode +, but you don't have to. First, we need to agree that mailto is an example of a generic URI, specified by RFC 2396. (This is what XHTML and HTML 4 use). Now let us find out the list of reserved characters in RFC 2396. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," URI splits into absolute and ...


6

Per new RFC http://tools.ietf.org/html/rfc6068#section-5 ... '+' MAY BE encoded as %2B So I guess the answer is don't, but maybe?


3

Per RFC 6068 as mentioned in answers, you MAY encode the plus sign as %2B. The reason there's confusion is that converting a space into a plus isn't actually part of standard URL encoding, it's part of form parameter encoding (i.e. application/x-www-form-urlencoded) It's like the difference between PHP's rawurlencode() and urlencode(). So what RFC 6068 is ...


3

I found an example of a website which uses this principle. (And I found it through Google.) When I searched for U+0060 the following link http://codepoints.net/U+0060 appeared on the first page (second result for me). I assume there aren't any huge disadvantage at least.


3

I suspect this is lies/misinterpretation from your "SEO expert" (such roles do not exist IMO). Essentially %3A and : are exactly the same thing, one is just encoded and means exactly the same thing, anything that reads an URL will know that. Otherwise you could argue that any non-alphanumeric character could cause duplicate content as they all have an URL ...


3

The RFC1738 3.5. MAILTO The mailto URL scheme is used to designate the Internet mailing address of an individual or service. No additional information other than an Internet mailing address is present or implied. A mailto URL takes the form: mailto:<rfc822-addr-spec> where is (the encoding of an) addr-spec, as ...


3

I think that encoding it or not, won't make a real difference. The problem are the mail clients. For examle, Yahoo Mail only uses hyphen for sub adressing whereas gMail uses the plus. That's my 2 cents... EDIT: The response below has a solid point.


2

Firefox 3.x and many others do. Can you post the full agent string that you're having problems with? As it sounds like it could be a custom script that is generating the request and pretending to be a certain agent. But is incorrectly creating the ident string. Or your check against the agent string is incorrect. Edit: The strings you posted are being ...


2

First things first, as @LazyOne said, the third-party URLs are not being properly generated, so the expectation is server to fail - as it is failing right now as you described. Note that valid HTML and valid URLs are a different thing. You should escape entities for HTML content, but this is not true when writing links, image addresses, and calls for ...


2

See RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax about the gory details of Url encoding. You should always urlencode your references, keep things standard conform and this way don't break your clients requests. Google Bot will be happy if it can fetch all your linked assets and this is what you want. Of course the bot is able to url-decode ...


2

The maximum indicator would be c%23 but please note I used the word indicator, Google uses many factors to rank a page and in no way is this only the sole factor. You can rank pages without keywords in the URL, take these as an example: msdn.microsoft.com/en-gb/vstudio/hh341490.aspx www.csharp-station.com/tutorial.aspx ...


2

While browsers can automatically make the conversion from spaces to encoded versions, you should ensure that your server software outputs correctly encoded URLs. Not all browsers / bots can do the encoding properly. If you do not have a CMS, you should encode the URLs in your HTML content. Best way is to restrict to not using URLs with special characters. ...


2

Browsers will automatically encode URL's with spaces, assuming you have linked to the file properly. Create a file on your server called test one.html link to it or simply load it directly in your browser using spaces in the URL bar. http://www.example.com/test one.html It will become test%20one.html It's not and ideal way of naming or linking to files ...


1

I think that the problem is that you have non-encoded forms of the links somewhere in your site. Googlebot has found those links and is trying to access those. So, try to doublecheck that all links in your page are actually URL encoded. The post you were referring to talks about double-encoding URLs in Giigle sitemaps, which is a separate issue.


1

Section 2.2 of RFC 3986 addresses reserved "sub delimiters" such as !: It says that when you produce URLs with these characters you should url encode them: URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data ...


1

Or you could just use preg_replace with urldecode in the URL construction to retain special characters in the URL such as what are currently in your sitemap. preg_replace("/%u([0-9a-f]{3,4})/i","&#x\\1;",urldecode($[attach_necessary_object_here])); This way the URL's would be:- example.com/here/there


1

I understand your dilemma, you sated it well, but what I do not know is where you are in the process. I will work on the assumption that nearly half of your pages are getting a 404 error. I also do not know what systems and applications you have, your skill level, etc. For the pages that are not getting a 404 error, you can quickly change whatever scheme ...


1

It looks like you are doing the encoding correctly. I agree that some email client is doing something funky. Here are some approaches you could try: Replace spaces in the key A plus in the url will get url decoded into a space. When your webserver gets the "key" parameter, have it replace spaces with pluses. That could fix the keys up so they could be ...


1

Long URLs are a problem because: Some servers have limits to how long a URL they can handle. 1024 and 4096 character limits are common. Long URLs often get truncated when pasted into forums. This causes bots such as Googlebot that look for URLs in page text to start crawling 404s. Long URLs cannot fully be shown in the Google SERPs, they get truncated ...


1

When using international characters in your URLs there are a few issues to be aware of: Percent URL encoding requires a character set. To display the URL correctly in the web browser, you should use "UTF-8" character set when percent URL encoding your slug. See: What is the proper way to URL encode Unicode characters? If there are lots of encoded ...


1

Modern browsers are automatically decode URLs before displaying on the location bar, but internally still using the real address which will include two different encodings for the path to the resource and the domain. When you copy the location from the browser it copy the original address with a purpose to make sure that it would act as a web address when ...


1

It's unclear exactly what you're asking about; it seems you're confusing concepts of encryption, content encoding, and URL encoding. I'll assume this is not related to encryption. Regarding content encoding, any modern browser (even IE 6) handles Unicode. As long as your PHP files are encoded as UTF-8 or UTF-16, you should be able to use any Hebrew ...



Only top voted, non community-wiki answers of a minimum length are eligible