What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 130 Stack Exchange communities.

By "SEO part of the URL" I mean:

stackoverflow.com/questions/question_id/this-is-the-seo-part

The SEO part appears to be constructed where for each character in the question's title:

  • If it's a letter or a number, copy it in the SEO part
  • If it's not and the last character in the SEO part is not a dash, add a dash

This, however, has the big problem that questions with C++ in the title appear to a human reader to be about C.

Example: C++, an "impossible" behavior , whose title is "C++, an “impossible” behavior."

My proposal

Consider plusses as valid characters. You don't even have to replace them with %XX, C++, an "impossible" behavior is a perfectly valid URL.


Note
I know that some of you don't like it when people put the language in the question title, but whether you like it or not it's something that is done in practice. So I feel that what I proposed is necessary, and I also ask you to please not discuss here about whether putting the language in the title is good practice or not. Thanks.


Edit
There has been some discussion about whether + is a valid character in an URL, and whether it has a valid meaning. In a path it is valid and it doesn't have a special meaning.

From the RFC:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                "$" | ","

In 3.3. Path Component:

  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","

The path may consist of a sequence of path segments separated by a
single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved.

So, pchar (the valid characters in a path) is formed by unreserved characters in addition to the reserved characters explicitly allowed.

share|improve this question
    
Same is true of C#, though there well be other reasons why the "#" isn't included. –  ChrisF Jan 30 '10 at 22:17
1  
@ChrisF: yes, C# is impossible to "fix", unless you replace '#' with 'sharp', which isn't such a bad idea. Anyways, one thing at a time, if this gets accepted we can propose to fix # too. –  Andreas Bonini Jan 30 '10 at 22:23
2  
It appears you don't understand what a + actually means in the URL. –  random Jan 31 '10 at 1:49
    
@random: does it matter what it means? Please explain what practical disadvantages there would be if you misuse it. –  Andreas Bonini Jan 31 '10 at 1:58
    
@random: you still alive? =p (PS: do note that according to RFC 2396 that link is perfectly valid) –  Andreas Bonini Jan 31 '10 at 13:38
3  
Keep reading where it says "used as delimiters". Stop reading halfway. –  random Jan 31 '10 at 13:57
    
@random: there is a difference between invalid and misused. As I stated above "Please explain what practical disadvantages there would be if you misuse it". You still haven't answered. For whether it's valid or not, it is valid. I'll make you an example so it's really super simple: <table>s for layout are valid but misused. The HTML validates, but you are misusing them. The same would be true in this case: the URL is valid, but you are misusing the plusses. Again, please explain why this is so wrong. Using my old example, SO does use tables for layout. –  Andreas Bonini Jan 31 '10 at 14:11
2  
@random: + absolutely is a valid character for a path part — see the production for pchar in the same RFC. Just because some characters are generally “reserved” as potentially having special meaning in URLs, that doesn't mean they're unusable in all parts of a URL. You have to check the grammar for the specific part you're interested in to find out. –  bobince Jan 31 '10 at 21:34

2 Answers 2

You can't have plus in the URL, so it would need to be encoded, like so:

http://stackoverflow.com/questions/1793678/c%2B%2B-an-impossible-behavior

pound also has to be encoded:

http://stackoverflow.com/questions/1793678/i-love-programming-in-c%23

In conclusion: meh.

share|improve this answer
1  
?? No.. As I already said in my post, + is a valid character and doesn't have to be escaped. The very HTML of my post contains <a href="http://stackoverflow.com/questions/1793678/c++-an-impossible-behavior">. EDIT: oh, saw John Smithers' post. I don't think it really matters though. –  Andreas Bonini Jan 31 '10 at 0:13
2  
@Koper a space character is translated into + by some browsers (I know that IE does this for sure.) –  Hogan Jan 31 '10 at 1:43
1  
@Hogan: and where is the problem with that? First of all they are not spaces but they are already +'s, so they are not transformed by any browser. Second, that part of the URL is useless, even if an imaginary browser transforms the +'s in something else it would work anyway. –  Andreas Bonini Jan 31 '10 at 1:54
    
@Koper: Is the point of this to help SEO? If so then a search engine would just turn the + into a space -- it would have no effect on the search. Thus, what is the point? –  Hogan Jan 31 '10 at 7:26
    
@Hogan: no, the point is to not confuse the people reading it. For example when I paste the question's url in IRC channels, etc. People then think it's a question about C and not C++. –  Andreas Bonini Jan 31 '10 at 7:35
3  
@koper I don't think you understand the issue fully –  Jeff Atwood Jan 31 '10 at 16:22
4  
A space character in a path is not converted into a plus. That type of encoding is only for form submissions in query parameters. + is an absolutely valid character to include, unescaped, meaning itself, in a URL path. –  bobince Jan 31 '10 at 21:31
1  
@Jeff, can you explain it further then? After further examination of part 3.3 of the RFC pointed by @bobince and @sth, I read it clearly says that a plus is a valid character, without special meaning in the path part of the URL. It only has a special meaning after a ?, such as in /test?abc=a+b –  Andreas Bonini Feb 1 '10 at 13:43
    
@koper we prefer to keep our URLs free of any characters that aren't a-z or dash -- so they are always detected as URLs everywhere in the world. Including an unencoded plus will break something, somewhere. Not worth it. –  Jeff Atwood Feb 1 '10 at 20:38
1  
I see. How against would you be replacing '+' with the word 'plus' and '#' with the word 'sharp'? Just throwing the idea out there. So it would become c-plus-plus-an-impossible-behavior, i-like-programming-in-c-sharp. It won't help nor hurt SEO, but they are more user friendly. –  Andreas Bonini Feb 2 '10 at 3:33
    
@Koper, I like that idea (of course taken to the extreme might drive @jeff bonkers, as everyone demands context sensitive translation of punctuation for their language or sub-system). –  Hogan Feb 3 '10 at 1:57
    
@Hogan: I'm not aware of any context where '+' is not pronounced plus.. –  Andreas Bonini Feb 3 '10 at 2:29
    
@Koper: Cute. As I'm sure you know I was talking about the having to translate != as not equal, <> as not equal, .not. as not equal, /= as not equal, ~= as not equal etc etc there are a lot of languages on SO and they all their punctuation characters have specific translations, there may be some language that treat one of those character sequences above as some other meaning thus you would need context sensitive translation. –  Hogan Feb 3 '10 at 3:06
1  
@Hogan: well, I didn't want to take this that far. != should remain "invisible". My main concern is not confusing C with C++ and C#.. I don't want to "translate" every possible symbol in every possible language. Translating != is much less important because it doesn't cause any confusing in titles. –  Andreas Bonini Feb 3 '10 at 3:15
    
@Koper: Sure, however the problem is SO is open to so many people with so many agendas, you can't just add a feature for C type language and ignore everything else; many users would be upset (not that I would, but that is the problem with this type of feature.) –  Hogan Feb 4 '10 at 17:06

Some freaks out there think, that your URL is not perfectly valid:

2.2. Reserved Characters

Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI.

 reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                "$" | ","

The "reserved" syntax class above refers to those characters that are allowed within a URI, but which may not be allowed within a particular component of the generic URI syntax; they are used as delimiters of the components described in Section 3.

share|improve this answer
1  
I don't think it really matters. This is when standards get in the way.. For example, the HTML of stackoverflow is very far from being standards complaint, if that's ok I don't see why using +'s only for the "intended purpose" is important. –  Andreas Bonini Jan 31 '10 at 1:57
4  
According to "3.3. Path Component" of the RFC you linked, "+" is a valid character in this place of an URI. –  sth Jan 31 '10 at 6:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .