Submitted by gouki on 2009, January 23, 10:56 PM
看到这篇文章,就随手转贴了一下,因为我自己也在使用这样的功能,而且,现在的网站几乎都有google的广告。所以从yahoo的14条军规来说,这并不违反这个规则:使用CDN,尽量不要有超过4个域名的链接。所以你想呀,有一些google广告和yahoo的统计再加上1至2个其他的链接,肯定是没有超过4个域名了。CDN,有现成的,使用了,也算是完成了14条军规中的一些了。不是吗?所以。。。。。。
原文:http://shawphy.com/2009/01/why-google-cdn.html
自从之前jQuery 1.3版起,就已经没有提供pack版了,而我也十分赞成使用Google CDN进行代码托管。
这样做有以下几个好处:
1,更小下载量。
都知道jQuery 1.3 pack后有38k之多,如果当然可以删除版权注释以获得更小的代码,遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版,只有18k,对用户来说下载量更小。
2,减轻服务器压力。
虽然现代浏览器都有了缓存,但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的(哪位同学能帮忙找到资料请下面留言,不胜感激~)。所以,让Google为我们提供服务,而不用自己操心自己的流量~少个库可以少个连接数,何乐而不为。
3,多个网站共享缓存。
如果用户访问的多家网站都使用Google提供的jQuery,那么对于用户来说,只需要缓存一次后即可只读取缓存中的数据!而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。
4,更快执行速度。
jQuery 1.3.1发布的发布信息中, 为jQuery不提供pack版给出了官方的解释。除了不易debug,在Adobe AIR和Caja-capable等环境下无法使用之外,更重要的是因为执行速度问题。随着jQuery逐渐变“胖”,用pack压缩后在浏览器端“解压 缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给 出了一些数据,有兴趣的同学可以看看。
反对的声音:
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢?”、“以前刚开始的时候就down过”
我认为(晕……怎么我觉得我在写四六级作文……)Google服务器down的几率与我们自己服务器down的几率不会有显著性差异(抱歉,我又空 口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设,认可备选假设的,欢迎提供,再次不胜感激~)。所以就放他们那边吧,挺安全的。
另外我还听到关于不能让整个世界为着Google转,Google阴谋论,Google威胁论的声音。实际上Google确实正朝这个方向发展,让 整个互联网围着他转。可以看他提供的一些服务,什么云计算,什么App Engine之类的,都企图让人们的应用都建立在Google至上,当Google成为了空气的时候,他已经无处不在了。这点来说,值得担忧。
Tags: cdn, google, yahoo
Misc | 评论:0
| 阅读:20144
Submitted by gouki on 2009, January 22, 10:22 PM
trunk:表示开发时版本存放的目录,即在开发阶段的代码都提交到该目录上。
branches:表示发布的版本存放的目录,即项目上线时发布的稳定版本存放在该目录中。
tags:表示标签存放的目录。
在这需要说明下分三个目录的原因,如果项目分为一期、二期、三期等,那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches 上,这样二期开发的代码就对一期的代码没有影响,如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码,如 果用户使用的过程中发现有bug,则只要在branches上修改该bug,修改完bug后再编译branches上最新的代码发布到生产环境即可。 tags的作用是将在branches上修改的bug的代码合并到trank上时创建个版本标识,以后branches上修改的bug代码再合并到 trunk上时就从tags的version到branches最新的version合并到trunk,以保证前期修改的bug代码不会在合并。
branches其实也就是分支,它究竟是干什么用的呢?
分支用于解决什么样的问题?
在手机游戏开发过程中,经常会遇到多种机型移植的问题。通常开发人员都说以一种机型作为 release 基础版本的目标,然后再此基础上进行相关的适配工作,如,键值修改,屏幕大小的修改单等。
然而同时维护多个版本是异常头疼的事情,因为很少有人能保证在移植之前,基础版本是没有 bug 的,特别是在工期很紧的情况下。这样一来,基础版本中出现了 bug ,就需要手动的“ Ctrl+C/Ctrl+V ”到其他的所有版本,各种版本的管理非常混乱,经常一不小心就会出现这样那样的问题。
而 SVN 的分支 (branch) 虽然不能做到自动将基础版本中的修改复制到其他版本中,却可以对各种版本的管理提供更有效和更规范的支持,避免了很多人为造成的问题。使用 SVN 来管理,可以将基础版本作为主干 (trunk) ,并从项目启动到 alpha 版本的推出,都可以在主干上进行开发。 alpha 版本发布以后,对于其他版本可以分别建立分支,如: branch_moto , branch_s603 等
如何创建分支?
创建分支非常简单,只需在需要创建分支的工作目录上,使用TortoiseSVN → Branch/Tag命令,在 "To URL" 项指定待创建的分支 url 即可。具体 可查看TortoiseSVN的帮助文档中的“ Braching/Taging ”一节
如何在分支下工作?
假设我们的主干名为 trunk ,分支目录名为 branch 。 branch 实际上是 trunk 目录在 branch 创建时的 copy ,而创建以后, branch 与 trunk 实际就是互不干扰的工作了, branch 上的修改不会影响到 trunk ,反之亦然。
如何合并分支?
事实上,我们并没有解决本文开头所提出的问题,即, trunk 有了修改之后,并不会自动提交到 branch 中(不知道有没有其他的版本管理工具可以做到),这一切都需要手动来实现,而这个过程在 SVN 中称为“合并 (merge) ”。
SVN 合并与原始的“ Ctrl+C/Ctrl+V ”相比,有以下几点好处(假设是将 trunk 合并到 branch 中):
1 、 trunk 中新增的文件可以自动合并到 branch 中
2 、提示 trunk 与 branch 中的同名文件的冲突内容,便于用于编辑冲突
合并操作步骤
在 TortoiseSVN 中提供便捷的合并功能。在待合并的工作目录上(如: branch ),使用TortoiseSVN → Merge命令,在“ From:(start URL and revision of the range to merge) ”中选择希望合并的目录 ( 如: trunk) ,并指定希望合并的开始 revision 编号,在“ To:(end URL and revision of the range to merge) ”中选择结束 revision 编号。然后点击“ merge ”完成合并操作,剩下的工作就是编辑冲突了,当然运气好的话是不需要这个过程滴。
值得注意的是,“ From: ”和“ To: ”中的 URL 通常是相同的,切记不要与创建分支时的含义混淆。
与合并相关的操作可查看TortoiseSVN的帮助文档中的“ Merging ”一节
本文为两篇摘录编辑而文,原文博客为:http://www.phpweblog.net/fuyongjie/
Tags: svn, 资料
Software | 评论:0
| 阅读:21136
Submitted by gouki on 2009, January 21, 10:25 PM
今天有点激动,回到家和小孩玩的时候,小孩憋了半天,叫了papa,我也就很激动的在说:叫爸爸,叫爸爸。然后他又憋了半天,终于又叫了一声papa,然后害羞的头撇过去了。
哈哈
记下今天的日子:2009年1月21日。小孩会叫papa了。
等下次会发b音的时候,我再贴上来
Tags: baby, papa
Baby | 评论:3
| 阅读:21699
Submitted by gouki on 2009, January 20, 11:00 PM
本文也是转摘,不过看到它的时候,我想起了discuz的URL解析,discuz在做rewrite的时候,并没有主动都对模版中的链接进行更换,而是在输出前,对于符合规则的那些链接使用rewrite的规范进行了一次批量替换。
这次我转摘的文章也是用了类似的方法,只是他又是.NET处理的,我也不翻译了。知道了原理就行了(和discuz一样,不过这种方法应该只适合做语言包)
原文:
一直以来多语言问题都是个让人头疼的问题,不是这个问题有多难,而是很繁琐,而我们目前的这个项目有点特殊,我希望最大限度的化繁为简,以下是我解决这个问题的方案。
我们的项目有这样两个前提:
1、要支持多语言但最多三种语言,一般情况下就两种语言,所以并没有随时切换语言的要求。
2、我们希望有一种可以初期不用管语言问题,之后统一翻译的方案
基于这么两点,我们提出了这样的方案:
1、初期写程序时不用关心多语言的翻译工作,只要将所有使用到中文的地方都用{}扩上
2、在数据库中Chinese会设置为唯一约束
3、所有的翻译工作会在BasePage中的Render方法中作
4、所有的页面会继承BasePage
5、翻译时会根据当前的语言设置构建以language表中Chinese做key,相应的语言为value的字典,然后查找需要翻译的字符串是不是在字典中,如果不在就生成这一行。
数据库设计四个字段
ID,Chinese,English,Other
BasePage源码:
这样设计的
优点
1、初期写程序时不用关心多语言的翻译工作,只要将所有使用到中文的地方都用{}扩上
2、省去了大量命名相应文字的工作
3、直接用中文标示要显示到页面的文字,容易理解
缺点
1、如果中文是一样的翻译,而其他语言翻译却不一样时不好解决,但这种情况似乎不常见
————————END————————
缺点就是我说的,只能用来做语言包,呵呵。
Tags: web, 语言包, 数据库
PHP | 评论:0
| 阅读:24969
Submitted by gouki on 2009, January 20, 10:54 PM
GET和POST接收编码格式不一样?说实话,原先没有考虑过这些问题。因为在一个项目中,程序的编码由项目开始到结束肯定都会一样的,当然在ajax处理的时候可能会有点变化。毕竟ajax的东西采用了UTF8进行传递。除此之外,其他的编码一般来说都是一致的。在看到这篇文章的时候,觉得不错。同时也是提醒一下自己需要注意。
因为他的代码是.NET的,临时转载,就不翻译成PHP了,看看别人的思路就行了。。。
原文地址:http://www.cnblogs.com/zhangziqiu/archive/2009/01/20/encoding.html
原文:
在查阅了一天资料,做了很多的试验, 精简提炼语言后, 完成了下面的文章.我发现在项目中太多的程序员对编码,尤其是Web程序中的中文参数编码一知半解.本文将作为一种规范提出, 以后将会应用到我制作的项目中.希望能够对大家有所启示.
[参数编码规范]
[原则]
避免在get或者post参数时直接传递中文字符.每次都经过指定格式的url编码后再传递.
[原因]
传递中文字符时,自动的编码解码格式和浏览器与服务器的设置有关.
测试Firefox3和IE6的Get方式发送中文参数, Firefox默认使用UTF-8格式编码中文参数, 而IE6即使在高级设置中设置了"总是以 UTF-8 发送URL", 仍然自动使用GB2312编码中文参数.
对于服务器端我们可以自由的控制解码的格式.但是往往是通过更改服务器配置进行全局的统一设置.比如对于ASP.NET程序.可以在Web.Config中设置服务器段的编码和解码格式:
XML/HTML代码
- <globalization culture="zh-CN" uiCulture="zh-CN" requestEncoding="UTF-8" responseEncoding="gb2312" />
但是我们没法控制浏览器端行为.用户可能使用不同的浏览器.
[解决方案]
一.统一默认的编码格式
1.设置服务器端的编码格式为UTF-8
2.传递参数全部进行编码,.服务器端(C#)使用Server.UrlEncode方法,客户端(javascript)使用encodeURIComponent方法.
说明:
客户端的javascript函数encodeURIComponent只能使用UTF-8编码格式. 所以需要设置服务器端request和response都为UTF-8.
缺陷是如果某些合作伙伴必须传递其他的编码格式的参数, 则服务器端或获取到乱码.此方案实现简单,适合大部分场景.
二.通过编码参数指定编码格式
为了解决可能存在的无法统一编码格式的问题, 我们使用一个参数"encoding"来显示的指定编码格式.encoding参数需要在所有的请求中传递,无论是get还是post.
1.对于javascript客户端编码而言, 仍然使用encodeURIComponent方法编码, 此时指定encoding参数的值为"UTF-8".
2.对于传入给服务器端的 其他编码格式, 比如GB2312, 我们不能使用默认的Request.Form或者QueryString方法进行编码.因为服务器端的编码格式可能设置为了UTF-8.此时使用 Request.Form或者QueryString会自动使用服务器端指定的编码格式进行解码. 所以需要使用下面的方法自己处理请求,获取参数:
C#代码
- /// <summary>
-
-
-
-
-
- public static NameValueCollection GetRequestParameters(HttpRequest request, string encode)
- {
- NameValueCollection result = null;
- Encoding destEncode = null;
-
-
- if (!String.IsNullOrEmpty(encode))
- {
- try
- {
-
- destEncode = Encoding.GetEncoding(encode);
- }
- catch
- {
-
- destEncode = null;
- }
- }
-
-
- if (request.HttpMethod == "POST")
- {
- if (null != destEncode)
- {
- Stream resStream = request.InputStream;
- byte[] filecontent = new byte[resStream.Length];
- resStream.Read(filecontent, 0, filecontent.Length);
- string postquery = destEncode.GetString(filecontent);
- result = HttpUtility.ParseQueryString(postquery, destEncode);
- }
- else
- {
- result = request.Form;
- }
- }
- else
- {
- if (null != destEncode)
- {
- result = System.Web.HttpUtility.ParseQueryString(request.Url.Query, destEncode);
- }
- else
- {
- result = request.QueryString;
- }
- }
-
-
- return result;
- }
此方法的返回值是一个NameValueCollection集合.客户端实例代码如下:
C#代码
- protected override void OnLoad(EventArgs e)
- {
- string sUrl = String.Empty;
- string tUrl = String.Empty;
- string encoding = String.Empty;
-
- Response.Clear();
-
- try
- {
-
- if (Request.HttpMethod.ToUpper().Trim() == "POST")
- {
- if (!String.IsNullOrEmpty(Request.Form["encoding"]))
- {
- encoding = Request.Form["encoding"].ToUpper();
- }
- }
- else
- {
- if (!String.IsNullOrEmpty(Request.QueryString["encoding"]))
- {
- encoding = Request.QueryString["encoding"].ToUpper();
- }
- }
-
-
- NameValueCollection paramList = EncodeUtility.GetRequestParameters(Request, encoding);
-
-
- sUrl = paramList["surl"];
- tUrl = paramList["turl"];
-
-
- if ( !( String.IsNullOrEmpty(sUrl) && String.IsNullOrEmpty(tUrl) ) )
- {
- Response.Write(OrderFromBL.OrderFromAnalysis(sUrl, tUrl));
- }
- }
- catch(Exception ex)
- {
- WebLog.CommentLog.CommonLogger.Error("OrderFromAjaxProxy.aspx页发生错误", ex);
- }
-
- Response.End();
- }
如果没有传入encoding参数,则使用服务器端默认的编码方式.
[总结]
两种解决方案首先都是要做到避免使用浏览器的中文自动编码, 中文参数一定要先编码再传递. 同时统一客户端和服务器端的编码格式.
[知识扩展]
[浏览器端的编码方式]
Get:
对于Get方式发送的请求, 不同的浏览器使用不同的编码方式自动为中文参数编码.比如:Firefox/3.0.5 使用UTF-8, IE6使用GB2312.
Post:
对于Post方式发送的 请求, 表单中的参数值对是通过request body发送给服务器,此时浏览器会根据网页的ContentType("text/html; charset=GBK")中指定的编码进行对表单中的数据进行编码,然后发给服务器。在HTML代码的Head中添加:
<meta http-equiv="Content-Type" content="text/html;charset=gb2312" />
Firefox/3.0.5 会使用根据charset中设置的编码格式编码post的中文参数.
IE6不起作用.
实验表明使用客户端浏览器默认编码格式具有不确定性.所以传递中文时我们要手工编码参数.
[Javascrip中的编码]
Javascrip语言中编码解码相关的方法主要有:
函数名称
|
函数说明
|
解释
|
escape()
|
escape() 函数可对字符串进行编码,这样就可以在所有的计算机上读取该字符串。
|
该方法不会对 ASCII 字母和数字进行编码,也不会对下面这些 ASCII 标点符号进行编码: - _ . ! ~ * ' ( ) 。其他所有的字符都会被转义序列替换。
[已过时] 请使用 encodeURI() 或 encodeURIComponent()
|
unescape()
|
unescape() 函数可对通过 escape() 编码的字符串进行解码。
|
该函数的工作原理是这样的:通过找到形式为 %xx 和 %uxxxx 的字符序列(x 表示十六进制的数字),用 Unicode 字符 \u00xx 和 \uxxxx 替换这样的字符序列进行解码。
[已过时] 请使用 decodeURI() 或 decodeURIComponent()
|
encodeURI()
|
encodeURI() 函数可把字符串作为 URI 进行编码。
|
该方法不会对 ASCII 字母和数字进行编码,也不会对这些 ASCII 标点符号进行编码: - _ . ! ~ * ' ( ) 。
该方法的目的是对 URI 进行完整的编码,因此对以下在 URI 中具有特殊含义的 ASCII 标点符号,encodeURI() 函数是不会进行转义的:;/?:@&=+$,#
[提示] 如果 URI 的参数中含有不能转移的字符,则应当使用 encodeURIComponent() 方法分别对各参数进行编码。
|
decodeURI()
|
decodeURI() 函数可对 encodeURI() 函数编码过的 URI 进行解码。
|
|
encodeURIComponent()
|
encodeURIComponent() 函数可把字符串作为 URI 组件进行编码。
|
该方法不会对 ASCII 字母和数字进行编码,也不会对这些 ASCII 标点符号进行编码: - _ . ! ~ * ' ( ) 。
其他字符(比如 :;/?:@&=+$,# 这些用于分隔 URI 组件的标点符号),都是由一个或多个十六进制的转义序列替换的。
[提示] 此方法会编码URI中的特殊字符
|
decodeURIComponent()
|
decodeURIComponent() 函数可对 encodeURIComponent() 函数编码的 URI 进行解码。
|
|
举例
document.write(encodeURIComponent("http://www.w3school.com.cn")+ "<br />")
document.write(encodeURI("http://www.w3school.com.cn")+ "<br />")
结果
http%3A%2F%2Fwww.w3school.com.cn
http://www.w3school.com.cn
总结
对于一个URI(URL也是一中URI),如果我们希望将它作为完整的网址发送请求, 但是上面带有中文, 则应该使用encodeURI方法.
如果是要编码参数,则应该使用encodeURIComponent.
Tags: 编码, get, post, 方案
PHP | 评论:0
| 阅读:25387