推荐:使用友好的URL
URL设计是网站架构中的重要内容，本文不仅仅可供网站管理人员参考，更是内容管理系统开发者所需要阅读和参照的。良好的url不仅仅提供更好的搜索引擎亲和度，而且在面对特殊的客户或者客户端时，网站将有更好的表现。
由于传统URL难于输入，记忆和保存，多年来，人们一直在构想新方式以取代它。
如今，URL的用处并没有太多的改进；但是，与此同时，对其改进所进行的实践和网络服务器技术方面都在力图改善，从而推进新一代URL的发展进步。
不洁的URLs
复杂的，难以认读的URL常被称作不洁的URL，因为它们混有很多普通用户无法识别的标点和符号。比如：http://www.example.com/cgi-bin/gen.pl?id=4&view=basic，这些URL在如今的动态网络中很普遍。但是，不洁的URL有很多缺陷，其中包括：
不洁的URL不易输入
这类URL长度大，又含有字符，非常复杂，这将极易导致用户出现输入错误。 www. asp xu exi.com asp学习网站
不洁的URLs不能增加实用性
由于不洁的URL既长又复杂，一般而言，用户很难记忆它们，也没法从中得到有效信息线索，以及推测出这个地址上的具体资源到底是什么内容，有什么功能。
不洁的URLs存在安全隐患
不洁的URL中，问号（？）后面的询问字符串经常被黑客利用修改，黑客企图以此对网络应用程序进行正面攻击。复杂URL中真实的文件扩展名，例如：.asp, .jsp, .pl等等，也会暴露关于动态网站执行的相关信息，这些也可能被黑客用作攻击的手段。
清洁URL不利于服务器维护和数据抽取
由于不洁的URLs通常会通过文件的扩展名暴露所使用的网站开发技术，以及通过询问字符串暴露所使用的参数，这会不利于服务器数据的抽取。不洁的URL没有把执行细节隐藏起来，相反的，它暴露了站点的潜在“路径（线索）”。结果导致了技术转型非常困难；并且由于过多无效连接使得过程处理变得非常复杂。
使用不洁URLs的原因
我们在这里列出了不洁URLs的种种缺陷后，也许有人会问，既然如此为何还要用它们呢？最显然的原因是出于惯例——在网络发展过程中，使用不洁的URL一直是，到目前为止仍然是被人们认同的惯例。除此外，不洁的URLs也确实有它的一些好处，其中包括：
URL携带信息方便
不洁的URL通常包含了重建某具体动态查询的全部信息。举个例子，试想在Google网站上，关于“网络服务器软件”的信息查询是怎样显示结果的？是这样：http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=Web+server+software。有了这个URL提供的查询关键字,以后无论何时你都可以重新进行相同查询了。虽然整个URL很难输入，但把它用作查询的“书签”还是挺方便的。
不洁的URL可以控制访问权限
当网络主们不希望用户输URL，记住它，或把它保存为“书签”的时候，不洁的URL的消极方面反倒是成了积极方面。不洁的URL颇有威慑力的复杂内容和长度，算是对用户和搜索引擎发出信号：此页面有限制，还是不用它为好。不洁的URL的这种副面效应很简单，但经常备受欢迎。它比人为的访问权限控制措施要好一些：通过使用Session变量，或进行URL检查等方式控制URL的实际使用，总是收效甚微。
Cleaning URLs
简化URL
大多数情况下不洁的URL的缺陷要远多于它的优点。如果说软件产业这三四十年来的发展历程，多少都对网络将来的发展趋势有所指向的话，那就是随着网站和应用程序的不断复杂化，服务器的抽取和数据隐藏的需要将不可避免地增加。
URL要保持简短和友好。
URL升级的第一步，是从头开始的合理设计。站点目录和文件名要保持简短且有意义。显然，/products比/p要好，但注意不要描述得过于详尽。例如www.xyz.com/productcatalog，它就没有多大意义（如果用户想找一份产品目录，他们很可能期望找到关于产品总目录的页面），反而对于将来页面可包含的内容，造成了不必要的内容限制。况且名称太长，更不利于记忆和推测。URL的标符要简短，和关于页面（或网页目录）的内容，功能的总体描述要一致。
文件名避免包含标点符号
设计者经常会用“product_spec_sheet.html”或“product-spec-sheet.html.”这样的文件名。下划线容易被人忽略，也不易输入，而且连接符也常被看作是网站结构设计粗糙的象征。只有迫不得已时才能使用它们。
尽量使用小写，并处理好有关大小写区分的事项
在明白了前面一点后，你也许会重新命名一个文件名为：ProductSpecSheet.html。然而，URL中的大小写区分是非常麻烦的，因为网络服务器的操作系统不同，它们对文件名和目录的大小写区分要求也不同。例如，基于UNIX系统， http://ww.xyz.com/Products.html和http://www.xyz.com/products.html所指的两份文件是不同的，但是基于Windows系统，它们却是相同的。此外，www.xyz.com 和 WWW.XYZ.COM这两个域名也是相同的，由此产生混乱的可能也变得明显了。最佳解决方法是：文件名和目录都默认为小写；另外，在服务器系统是区分大小写的情况下，要保证无论输入URL的大小写状况，它们都能被正确地处理。即使URL的重写和拼写检查措施能有所帮助，在Unix或Linux系统的Apache[阿帕奇]状态下，遇到上述情况URL还是不能保证被正确处理。
目录名不要暴露所使用的建站技术。
通常目录名会和服务器相关技术有联系，这可能导致服务器执行细节的泄露，以及URL无法持久有效。尽量多用普通路径。例如，“/cgi-bin”可替换成“/scripts directory”，“/css, use /styles”和“instead of /javascript”可替换成“/scripts”，等等。
主机产生错误域名typo的有关准备
用户导航走向末路的现实原因是：所有网站有近一半的通信量，是由于直接访问和书签式访问获得的。如果用户想浏览Amazon的网站，他们会在地址栏输入www.amazon.com。然而，如果用户匆忙,也可能会凑巧输成ww.amazon.com 或 wwww.amazon.com。针对上述情况，在涉及有关站点域名的工作方面，我们可以多准备一些typo域名（与正确域名相近，但错误的域名），这样用户在输入w,ww或wwww的情况下，依然能链接到主页，另外常见的还有www.site.com和site.com,这些工作几分钟就能完成，意义却不可低估。
域名typo的相关准备
如果可能的话，要照顾到用户输入域名时普遍存在的“粗手指失误”。键盘上按键排列紧密，用户可能把“z”键错按到它周围的“x”,”s”或 ”a”键，因此，Amazon网站会有像amaxon.com这样的Typo域名也就不难理解了。而Google网站还准备了像gooogle.com 和gogle.com.这样的域名typo。不妙的是，很多网络投机者会抢注关于大网站的域名typo，但无论怎样，组织机构都该为其网站注册好一些容易产生的相关域名typo，这样用户更有机会找到他们的网站。有的组织机构名称不易拼写，比如"Ximed,"那么它应该注册像"Zimed" 或"Zymed" 的相关域名，以方便那些知道组织名称，但不会正确拼写的用户 。公司如果有特殊的域名，应该在常规联系时及时告诉客户。
支持多重域名 
如果组织名称有很多不同形式，比如International Business Machines [国际商用机器] 和IBM，那么组织最好将两个域名都进行注册。一些公司会注册很多合法的域名，比如假设有XYZ, LLC或 ABC公司，他们除注册主要域名外，还可能会注册像xyzllc.com 和abcinc.com这样的域名。这样看起来似乎投资巨大，但是如果你找花费低廉的新注册点（比如itsyourdomain.com）注册，每年为站点大量域名的花费就显得可以接受了。域名后缀有net, .org, .biz等等可供选择，应该选择哪个呢？使用新域名后缀可能效果会不太好（比如biz, .cc），最好使用普通的域名后缀 (如.com)，或者表示所处地域的域名后缀（比如co.uk）
建立多重URL
因为用户寻找网站时会推测网站域名，所以用户特别是高级用户，会有可能推测URL中的目录路径。比如说，想了解Microsoft Word相关信息的用户，可能会输入http://www.microsoft.com/word。对于站点各个入口来说，建立多个URL是非常容易的。很多网站已经开始这么做了。举个例子，访问一个网站有关就业的部分，规范的URL可能是http://www.xyz.com/careers。然而，如果建立起别的URL，例如http://www.xyz.com/career， http://www.xyz.com/jobs， 或 http://www.xyz.com/hr，那么输入这些URL的用户也可以找到相同目的地了。你还可以添加像http://investor.xyz.com，http://ir.xyz.com，http://investors.xyz.com这样的域名，因而用户输入这些域名时能进入http://www.xyz.com/invvestor。这些对相关URL的考虑不仅增强了URL的实用性，还通过支持网站信息资源的模块化，促进了站点的长期维护。
尽可能的删除动态页所产生的查询字符串
一些复杂的URL，比如http://www.xyz.com/press/releasedetail.asp?pressid=5的产生，经常是由于动态页面的不合理使用造成。很多开发技术员会使用相关服务器脚本技术，比如ASP/ASP.NET, ColdFusion, PHP等等，看上去生成的是动态页面，其实它是静态的。如上述URL中，在ASP脚本形式下，“press”显示为“5”，数据库中的相关数据内容会被调动，生成页面。但是，几乎所有情况下，这种类型的页面无论在内容还是表达上都是静态的。在用户看来，动态地发生页面浪费服务器宝贵资源，减慢页面生成速度，不必要地增加URL复杂程度。一些动态的高速缓冲存储器和内容配置网络可以减轻这些影响，但URL还是照旧复杂。通过直接预先发生页面的静态形式，从而使URL得到简化，这并不困难。因而，http://www.xyz.com/press/releasedetail.asp?pressid=5 可能会简化为www.xyz.com/press/pressrelease5 。即使像描述性较强的http://www.xyz.com/press/03-02-2003 ，也比http://www.xyz.com/press/newproduct. 要好。至于何时生成页面，是预先生成还是等用户发出请求时生成。这个问题好比是在问，程序是应该口头阐释还是应该直接编译。
重写查询字符串
在页面必须是动态的情况下，也可以简化URL的查询字符串。容易的简化常常是把“?”,“ &”, 和 “+”等符号换成更易于输入的字符。因而，http://www.xyz.com/presssearch.asp?key=New+Robot&year=2003&view=print也许可以简化成http://www.xyz.com/pressearch.asp/key/New-Robot/year/2003/view/print。 这样虽然从URL看，页面是静态的，但实际却是动态。用户看到这样的URL也会觉得更顺眼，搜索引擎也会觉得它更“友好”（我们知道搜索引擎在碰到“？”字符时会中断工作）。和下一点提到的相同，由于黑客无法利用“？”区分静态和动态页面，他们就很难通过处理URL相关参数试图实施攻击了。重写URL是带有挑战的，这需要充足准备。重写可利用的主要工具有mod_rewrite for Apache 和 ISAPI Rewrite for IIS，但在开发设计者们使用常规表达时，这些工具的语法规则实在令人生畏。然而，为了学会使用这些工具所付出的努力还是非常有回报的。
清除URL和服务器资源中的文件扩展名
或许在URL改善方面，最有趣的算是“内容谈判”了。Despite being a long-supported HTTP specification，即使如今网络中“内容谈判”用得非常少。“内容谈判”的基本思想是：浏览器向服务器传输信息，告诉服务器它想要哪些资源，能接受哪些资源（所希望的MIME的类型，所用语言，所支持的代码，等等），服务器会处理信息，根据它的配置选择，动态地决定向浏览器返回何种内容和形式的信息资源。这就好比浏览器和服务器在互相进行谈判，考虑双方共同利益的情况下，讨论传送怎样的有用资源，怎样传送才是最佳的。这意味着如果用户输入了一个URL：http://www.xyz.com/products，返回内容的语言种类会被自动认定——结果就是：对于英语用户来说，返回内容的文件来源会是products-en.html，而对于西班牙语用户，则是products-es.html。相关技术选择例如文件格式(PNG或 GIF， xhtml或HTML)，也可以通过内容谈判决定，这样，站点可以满足终端用户浏览器的大部分要求了。
“内容谈判”不仅使开发者可以准备许多可供选择的资源内容，也对URL的完全绝对性有显著的影响。比如， “内容谈判”存在的情况下，http://www.xyz.com/products/robot，此URL是合法的，其中“robot”不指目录，而指文件。而实际所用的文件可以是robot.html，robot.cfm，robot.asp等等，这就要根据“内容谈判”相关规则而定了。除去文件扩展名有两大好处。首先，安全性得到显著提高，黑客无法立即通过扩展名识别出网站的背后技术。其次，若URL中除去扩展名，开发者可以方便地转换所用技术，不会受到原有的限制。如果你认为URL是对网络应用程序非常有效的访问途径，那么简化的URL是隐藏数据的基础。
利用执行“内容谈判”的Web服务器扩展，URL可以在服务器端被简化，类似服务器扩展有mod_negotiation for Apache 或 PageXchanger for IIS。但是，找到执行“内容谈判”的筛选还只是完成了一半工作。HTML文件和其他文件中隐藏的URL也要清除文件扩展名，以实现“内容谈判”带来的抽取和安全性方面的好处。要简单地清除源代码中的文件扩展名，可以使用Dreamweaver MX 或 HomeSite网页编辑软件中的“search(查找)”“replace(替代)”功能。像w3Compiler的一些工具也正不断改进，可以为“内容谈判”和对相关页面改善信息传输作准备。有一点要提醒：不要以为消除之后，再也不会有像page.html这样的文件名出现了。要记住，在你的服务器上，扩展名还是安全的保留下来的，“内容谈判”的执行只意味着把源代码，标记，和输入URL中的扩展名清除了。
URL中的目录和文件名的自动拼写检查
最后一点作用最小，但它最易于做到：对文件和目录名称进行拼写检查。用户输入的URL在文件名，扩展名，或路径上的拼写错误，断开的连接，这些都可以容易地被拼写检查自动修改恢复。比如若给出“404”，服务器的拼写模块会立即起作用，把与“404”最相近的文件名或目录名调用出来，以便随后修复。如果网站的文件名和目录名相对独立，那么针对大量的Typo 名称，上述匹配修复会很准确。如果不是相对独立，则得到的仍然是“404”。要建立如"Did you mean X?"这类简单的URL，须要安装简易的服务器筛选装置，像mod_speling for Apache 或 URLSpellCheck for IIS。拼写检查的设置并不是个大问题，因为修正筛选装置处理的只是类似“404”这样的小错误，而且发送匹配修正后的页面，总比一直向用户发送错误报告页面要好得多。简而言之，没有理由不设置拼写检查，但令人惊讶的是，现行的所有网络服务器竟然都没有这项设置。
结论
上述的大多数要点都浅显易懂，除了部分关于URL简化和重写的内容。这些建议都值得大家努力尝试一下。如果照这些建议做了，那么简化后的URL应该会简短，易懂，持久，且不泄露执行细节。如此简化的URL可以显著改善网站的实用性，可维护性和安全性。将来网络开发者和管理者可能拒绝新一代URL的理由有两个：服务器筛选在对新URL执行操作时，可能有问题出现；新URL与搜索引擎会涉及兼容性问题。关于前者，在Apache服务器上，已经出现了相当成熟的解决技术，他们的新型IIS equivalents很明显是模仿Apache exemplars的，所以前个问题解决是比较可观的。至于搜索引擎，较为幸运的是，Google对新URL并没反应出什么问题。因此可以说，新URL广泛使用的主要瓶颈在于，了解新URL有发展潜力的开发者为数太少，即使那些了解的开发者，也过于安于现状，没有热诚去探索研究新URL。这令人惋惜，因为虽然这些改良的新URL不能在短期内有所作为，但在长期过程中，必定会充分地改变用户和网络开发者的web体验。
本文主题URL
