友善端口_友善网址

友善端口

So I hope everyone in the US has survived the Daylight Savings Time crisis of 2007! I don’t know about you but i didn’t even feel it :)

因此，我希望美国所有人都能度过2007年的夏令时危机！ 我不认识你，但我什至没有感觉:)

I was browsing the forums recently, as i typically do when I’m looking for a topic to blog on, and I came across a post by forumposters entitled “Clean and descriptive url’s“. In this post forumposters asks:

我最近在浏览论坛，就像在寻找要在其上写博客的主题时一样，并且在论坛上发帖时看到一个名为“ 干净且描述性的URL ”的帖子。 论坛帖子在此帖子中问：

“What have you fellow CF developers done to make your URLs look better? I’d like to see many examples and options if you would all be so kind to share”

“其他CF开发人员做了哪些工作来使您的URL看起来更好？ 如果您愿意与大家分享，我希望看到许多示例和选项”

I thought this was a good topic for me since I have a good bit of experience both historically and recently with this very issue.

我认为这对我来说是个好话题，因为我在历史上和最近对这个问题都有很多经验。

For the longest time search engines would treat URLS with query strings aka dynamic URLs, everything after the question mark (?) in the URL, differently. Mostly pages which had these query strings would be ranked lower than a page which didn’t. So if you had the URL:

在最长的时间里，搜索引擎会以查询字符串(即动态URL)来对待URL，URL中问号(？)之后的所有内容都不同。 通常，具有这些查询字符串的页面的排名将低于没有查询页面的页面。 因此，如果您有URL：

http://www.example.com/books/index.cfm?category=coldfusion&author=forta

it would rank lower in search results versus a URL formatted like so:

与格式如下的URL相比，它在搜索结果中的排名较低：

http://www.example.com/books/coldfusion/forta/

So it’s been a pretty big tasks for developers to try and get their URLs to be “clean”, meaning they wanted to remove the question marks (?), ampersands (&), and equal signs (=) from the mixture. This would result in what is commonly known as a Search Engine Friendly URL and allow your site to achieve better rankings. A quick tangent here; Google has said that it will better index dynamic URLs so the issue of search engine friendly URLs is fading but now it’s turning more into a user friendly URL issue. Meaning developers, customers and users want URLs others users can understand, remember and share easier then those longer dynamic URLs. All in all the idea of a friendly URL is much more accepted.

因此，对于开发人员来说，尝试使其URL变得“干净”是一项非常艰巨的任务，这意味着他们希望从混合物中删除问号(？)，＆符(＆)和等号(=)。 这将导致通常被称为“搜索引擎友好” URL，并使您的网站获得更好的排名。 在这里快速切线； 谷歌曾表示 ，它将更好地为动态URL编制索引，因此搜索引擎友好的URL问题正在逐渐消失，但现在它已更多地转变为用户友好的URL问题。 这意味着开发人员，客户和用户希望其他用户可以理解，记住和共享的URL比那些较长的动态URL更容易。 总而言之，友好URL的想法已被广泛接受。

So what are your options when it comes to dealing with creating friendly URLs? There thankfully are a lot of options to choose from depending on your setup, time, and abilities. The most widely accepted method to deal with turning the dynamic URL to a friendly URL is to use a rewrite module. This rewrite module will do the heavy lifting of translating a friendly URL into a dynamic URL so your code can operate as expected. so using our example above a rewrite module would turn

那么在创建友好的URL时您有什么选择呢？ 幸运的是，根据您的设置，时间和能力，有很多选项可供选择。 将动态URL转换为友好URL的最广泛接受的方法是使用重写模块。 此重写模块将繁重的工作将友好的URL转换为动态URL，以便您的代码可以按预期运行。 因此，使用上面的示例中的重写模块将使

http://www.example.com/books/coldfusion/forta/

into

进入

http://www.example.com/books/index.cfm?category=coldfusion&author=forta

Our users would only see the friendly URL but the server and our code would see the dynamic URL and all the associated URL variables would be created for our use as well.

我们的用户只会看到友好的URL，而服务器和我们的代码将看到动态URL，并且所有关联的URL变量也将创建供我们使用。

Depending on your web server you might already have a rewrite module installed and ready to use. If you are running ColdFusion on Apache then you have the popular mod_rewrite at your disposal for those on IIS it’s a bit more work as IIS doesn’t support rewriting out of the box. Thankfully there are options out there though which make IIS just as cool as Apache for both a fee and for free. The fee option I typically recommend is IsapiRewrite by Helicon. It’s an ISAPI plug-in which acts very similar to mod_rewrite, in fact version 3 uses the same exact rules! They have a free version for 1 site or for $99 you can get a license for unlimited IIS sites. If you are on a budget there is also Ionic’s ISAPI Rewrite Filter which is totally free and pretty robust as well.

根据您的Web服务器，您可能已经安装了重写模块并可以使用它。 如果您在Apache上运行ColdFusion，则可以使用流行的mod_rewrite来替代 IIS上的mod_rewrite，因为IIS不支持开箱即用，因此工作量更大。 值得庆幸的是，尽管有一些选择，这些选择使IIS与Apache一样酷，无论是付费还是免费。 我通常推荐的收费选项是Helicon的IsapiRewrite 。 这是一个ISAPI插件，其行为与mod_rewrite非常相似，实际上版本3使用了完全相同的规则！ 他们有1个站点的免费版本或99美元，您可以获得无限IIS站点的许可证。 如果预算有限，还可以使用Ionic的ISAPI重写过滤器 ，它完全免费，而且功能强大。

I’m not going to go into any real details about these products since they each have their own little ways about them but most rewrite modules use some form of Regular Expressions to translate a URL from one form to another. Most of the translations you’ll probably need to do can easily be written with just a basic knowledge of regular expressions.

我将不涉及这些产品的任何实际细节，因为它们各自都有自己的小方法，但是大多数重写模块都使用某种形式的正则表达式将URL从一种形式转换为另一种形式。 仅需具备正则表达式的基本知识即可轻松编写大多数翻译。

But what if you don’t have Apache, and you cannot install a plug-in to IIS to get this great rewrite capabilities? Are you up the creek without a paddle? Left to suffer because of some corporate politics? Not at all! Before I go down this path let me just say that in my experience the rewrite modules are much more robust and will typically out perform anything we discuss here. However saying that it’s not uncommon to see a programmatic way for dealing with the friendly URL issue.

但是，如果您没有Apache，并且无法安装IIS插件来获得强大的重写功能，该怎么办？ 您在没有桨的小河上吗？ 因某些公司政治而受苦吗？ 一点也不！ 在我走这条路之前，我只能说，根据我的经验，重写模块要更健壮，并且通常会执行我们在此讨论的所有内容。 但是，说以编程的方式处理友好的URL问题并不少见。

One option which isn’t widely accepted and typically frowned upon in the developer world is the 404 method. This is where you setup a 404 page for your site and using some coding practice (like switch case statements) you’d check to see if you had a match and then include the proper code to make it work. I’m not gong to go down this path because I don’t recommend it for a lot of reasons. The biggest reason is that it really messes up the statistics for your site since everything is reported as a 404 error in the logs. It’s my understanding that many search engines are removing 404 pages from their indexs, but hey who needs the search engines, yea right try explaining that to a customer!

404方法是一种未被广泛接受并且在开发人员世界中通常不被接受的选项。 在这里，您可以为网站设置404页面，并使用一些编码习惯(如switch case语句)来检查是否存在匹配项，然后添加适当的代码以使其正常工作。 我不愿意走这条路，因为出于很多原因我不建议这样做。 最大的原因是它确实弄乱了您网站的统计信息，因为在日志中所有内容均报告为404错误。 据我了解，许多搜索引擎正在从其索引中删除404页，但是嘿谁需要搜索引擎，是的，请尝试向客户解释这一点！

The other option is to use what I call a gateway script. This gateway script allows you to run everything from a central place and using some fancy coding you can make those friendly URLs without getting a bunch of 404 errors. In fact I’m sure you’ve already seen this in practice in a few of the ColdFusion blogs you read! Most users who use the wonderful BlogCFC have had friendly URLs for a while using this method. In a BlogCFC application the URLs typically look like:

另一个选择是使用我所谓的网关脚本。 该网关脚本使您可以从一个中心位置运行所有内容，并使用一些精美的编码，可以创建那些友好的URL，而不会遇到一堆404错误。 实际上，我相信您在阅读的一些ColdFusion博客中已经在实践中看到了这一点！ 大多数使用出色的BlogCFC的用户使用此方法已有一段时间友好的URL。 在BlogCFC应用程序中，URL通常如下所示：

http://ray.camdenfamily.com/index.cfm/2007/4/3/Did-you-know-about-the-Log-Viewer-Filter

In the URL above Ray has the gateway script running in the root index.cfm in his site. Then using a bit of CF code he’s able to extract the “/2007/4/3/Did-you-know-about-the-Log-Viewer-Filter” and do stuff with it. The benefits of using the gateway script is that index.cfm actually exists on the server so your web server doesn’t return it as a 404 error AND it also records the full page as unique URL so you can still see what pages your users are visiting etc. So how did he do this? Let’s take a peak at his code:

在Ray上方的URL中，网关脚本在其站点的根index.cfm中运行。 然后，使用一点CF代码，他就可以提取“ / 2007/4/3 /您知道关于日志查看器过滤器”的内容并对其进行处理。 使用网关脚本的好处是index.cfm实际上存在于服务器上，因此您的Web服务器不会将其作为404错误返回，并且还将整个页面记录为唯一的URL，因此您仍然可以看到用户所在的页面拜访等等。那么他是怎么做到的呢？ 让我们来看看他的代码：

/**
 * Parses my SES format. Demands /YYYY/MMMM/TITLE or /YYYY/MMMM/DDDD/TITLE
 * One line from MikeD
 *
 * @author Raymond Camden (ray@camdenfamily.com)
 * @version 1, June 23, 2005
 */ 
function parseMySES() {
	//line below from Mike D.
	var urlVars=reReplaceNoCase(trim(cgi.path_info), '.+.cfm/? *', '');
	var r = structNew();
	var theLen = listLen(urlVars,"/");

	if(len(urlVars) is 0 or urlvars is "/") return r;
	
	//handles categories
	if(theLen is 1) {
			urlVars = replace(urlVars, "/","");
			r.categoryName = urlVars;	
			return r;
	}

	r.year = listFirst(urlVars,"/");
	if(theLen gte 2) r.month = listGetAt(urlVars,2,"/");
	if(theLen gte 3) r.day = listGetAt(urlVars,3,"/");
	if(theLen gte 4) r.title = listLast(urlVars, "/");
	return r;
}

The first thing you’ll notice is that Ray’s blog and function require your URLs to be in a specific format. This is a common practice when using a gateway script, but with a little work and a bit more code you can make your script and URLs be more versatile.

您会注意到的第一件事是Ray的博客和功能要求您的URL采用特定格式。 使用网关脚本时，这是一种常见的做法，但是，只需做一些工作和添加更多代码，您就可以使脚本和URL更具通用性。

The basics of the function above is to take in the CGI.PATH_INFO variable returned by ColdFusion and parse out everything after the “.cfm” and use the forward slash “/” as the delimiter. The  CGI.PATH_INFO variable returns extra path information after a script name. So in our example above from Ray’s Blog this would be “/2007/4/3/Did-you-know-about-the-Log-Viewer-Filter” which is everything after the index.cfm. Now in versions prior to ColdFusion 7 the CGI.PATH_INFO variable would actually return the script name AND extra path information so it wold look something like so “index.cfm/2007/4/3/Did-you-know-about-the-Log-Viewer-Filter”. Ray handles this by stripping out the .cfm and everything in front of it before parsing the string as seen by this line of code:

上面函数的基础是接受ColdFusion返回的CGI.PATH_INFO变量并解析出“ .cfm”之后的所有内容，并使用正斜杠“ /”作为分隔符。 CGI.PATH_INFO变量在脚本名称之后返回额外的路径信息。 因此，在我们上面来自Ray's Blog的示例中，该目录将是“ / 2007/4/3 / Did-you-know-about-the-Log-Viewer-Filter”，它位于index.cfm之后。 现在，在ColdFusion 7之前的版本中，CGI.PATH_INFO变量实际上会返回脚本名称和额外的路径信息，因此看起来就像“ index.cfm / 2007/4/3 / Did-you-know-about-the- Log-Viewer-Filter”。 Ray通过在解析字符串之前去除.cfm及其前面的所有内容来处理此问题，如以下代码行所示：

var urlVars=reReplaceNoCase(trim(cgi.path_info), '.+.cfm/? *', '');

Once he has a “clean” set of vars he can then treat it as a list using the forward slash “/” as the delimiter. You can see from the rest of his script above he just does a simple list length check to determine which variables can be setup and used.

一旦他拥有一组“干净”的变量，就可以使用正斜杠“ /”作为分隔符将其视为列表。 您可以从上面的脚本其余部分看到，他只是进行了简单的列表长度检查，以确定可以设置和使用哪些变量。

Using the CGI.PATH_INFO variable is a great way to create friendly looking URLs that any search engine and most people will enjoy. Now there are other “things” you can do to help remove the .cfm file extension but these typically require a bit more work from the web server side of the house and aren’t worth the extra effort. If you are in need of that “look” I’d recommend going with one of the modules mentioned above.

使用CGI.PATH_INFO变量是创建外观友好的URL的好方法，任何搜索引擎和大多数人都会喜欢它。 现在，您可以执行其他“操作”来帮助删除.cfm文件扩展名，但是这些操作通常需要在房屋的Web服务器端进行更多工作，因此不值得付出额外的努力。 如果您需要这种“外观”，我建议您使用上述模块之一。

So there you have it, a few options to get you started down the path of friendlier URLs.

因此，您已经有了一些选择，可以帮助您开始使用更友好的URL。

翻译自: https://www.sitepoint.com/friendly-urls/

友善端口