URLs and how to spread them around without breaking them
OK, I've got a pet-peeve to share with you. Or perhaps it's more like a windmill that I'd like to take a tilt at. Have you ever recieved a message from a friend that contains an interesting URL? (I thought you might have). Ever clicked on that URL and had your web browser open a page (or not open the page) because it's not there?
Maybe, if you're used to this stuff, you check the URL that got pasted and see the error, but a lot of people either just give up or they go back tot he email and click the link again and have the same problem.
I'll use an example that hapened earlier today to explain this. My friend, Allen, in addtion to sending me typical friendly "how ya doin?" personal messages, also sends out humor and interesting stuff blasts to a larger audience. Today he send a quick blurb about the Stanford Manufacturing "How Everyday Things are Made" site.
Here's what he sent:
A new Stanford website, "How Everyday Things Are Made" (http://manufacturing.stanford.edu), takes a look at the manufacturing process for products including candy, clothes, airplanes and steel. The site, an online educational experience targeted to the general public, will give non-engineers a window into manufacturing technology. Stanford's Alliance for Innovative Manufacturing (AIM) funded the site, which was designed and produced by Design4X Inc. of Oakland, Calif., an education and information resource for engineers.
So I think this is worth looking at, so I click the URL and I get (graphic):
Hmmph. Having been through this before, I notice that the URL reported is:
http://manufacturing.stanford.edu),
Yuck. There's a parenthesis and a comma at the end! I get rid of these and proceed to the proper site. Then, I remember that I'm on a crusade! I'm out to teach the world how to make these URLs clickable!
Folks, there's an easy answer to this. Follow the RFCs.
What's that? Oh. An RFC is a Request For Comment. They run the internet. It's a set of rules set up by the Internet Engineering Task Force (IETF). For more information on RFCs, check out <URL:
http://www.rfc-editor.org/>.
The particular RFCs that we care about in regard to this whole URL thing are:
RFC-1738,
RFC-1808,
RFC-2368RFC-2396, etc. Going all the way back to
RFC-822 (which has been obsoleted by
RFC-2822). A good interface to look at the cross references to all of these is
Zvon's RFC Repository.
Now then, you don't need to rush off and read all those, but you're welcome to. The basics are that RFC-822 (the obsolete one) tells us about mail headers. Within mail headers, you should only use angle brackets as delimiters to define the beginning and end of things so they can be interpreted. Originally, this was used to denote addresses in email headers. It evolved when the World Wide Web was created and other Uniform Resource Locaters (URLs) were needed. And so RFC-1738 was born.
This document describes the syntax and semantics for a compact string
representation for a resource available via the Internet. These
strings are called "Uniform Resource Locators" (URLs).One big thing about RFC-1738 is that it tells you what not to use as part of a URL.
Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".
So, because URLs can include things like slashes to denote different levels in a directory structure, ampersands to denote a connection in a database, question marks for queries, etc., there needed to be some way of denoting the beginning and end of a URL. They choose angle brackets.
Thus when you're sending a URL to someone, wrap it in angle brackets. It will make it so that people will get what you want them to. It evens works for those huge URLs that you get from map sites or databases. As a bonus, you can include "<URL:" as part of the URL to let people know that you undersand the RFC.
Examples
Apple Headquarters via
Yahoo Maps:
<URL:http://maps.yahoo.com/maps_result?ed=Qhv9Sep_0TpMK_N0ZiGCFtdN02ktvmAL&csz=Cuperti
no%2C+CA&country=us>
Apple Headquarters via
MSN (formerly MapBlast):
<URL:http://mappoint.msn.com/(53amzv45isbphq45rcneqd45)/map.aspx?ID=27CiJ.&C=37.33182%2
c-122.03118&L=USA&A=12&PN=1097513573&S=800%2c740&P=%7C37.33182%2c-122.03118%7C1%
7C1+Infinite+Loop%2c+Cupertino%2c+CA+95014%7CL1%7C&TI=1+Infinite+Loop%2c+Cupertino%2c+
CA+95014>
Trickier is to embed a URL in a sentence like:
To get to Apple HQ, check out <http://maps.yahoo.com/maps_result?ed=Qhv9Sep_0TpMK_N0ZiGCFt
dN02ktvmAL&csz=Cupertino%2C+CA&country=us>. Feel free to zoom in!
I hope that helps. I'm trying to get at least one web browser to properly wrap URLs dragged from the location area to a text area, but I haven't succeeded yet.
