易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

易栈网-膘叔

SVN知识

小孩会叫papa了

语言包？

参数编码完全解决方案[ZZ]

按照AdSense要求投放广告代码

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

SVN知识

小孩会叫papa了

语言包？

参数编码 完全解决方案[ZZ]

按照AdSense要求投放广告代码

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

参数编码完全解决方案[ZZ]

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/

今天有点激动，回到家和小孩玩的时候，小孩憋了半天，叫了papa，我也就很激动的在说：叫爸爸，叫爸爸。然后他又憋了半天，终于又叫了一声papa，然后害羞的头撇过去了。

哈哈

记下今天的日子：2009年1月21日。小孩会叫papa了。

等下次会发b音的时候，我再贴上来

本文也是转摘，不过看到它的时候，我想起了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源码：

C#代码

using System;

using System.Data;

using System.Configuration;

using System.Linq;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.HtmlControls;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Xml.Linq;

using System.Text.RegularExpressions;

using System.Text;

using System.Collections;

using System.Collections.Generic;

using System.IO;

using System.Diagnostics;

/// <summary>

///BasePage 的摘要说明

/// </summary>

public class BasePage : System.Web.UI.Page

{

//利用Dictionary来筛选所有的多语言标签,然后做替换,可以缓存

Dictionary<string, string> dic;

public BasePage()

{

}

//需要替换的标签，标签头为数字字母下划线汉字

static readonly Regex re = new Regex

(@"((\{)|(\%7B))[\w\-\+\|u4e00-\u9fa5]+?((\})|(\%7D))",

RegexOptions.Multiline | RegexOptions.IgnorePatternWhitespace);

//不需要替换的标签

static readonly Regex re_nr = new

Regex(@"<NOREPLACE>[\w\W]*?</NOREPLACE>", RegexOptions.Multiline | RegexOptions.IgnoreCase);

private string RenderTag(ref string content)

{

if (re_nr.IsMatch(content))//不需要替换标签

{

StringBuilder sb = new StringBuilder();

MatchCollection grouplist = re_nr.Matches(content);

string[] reList = re_nr.Split(content);

for (int i = 0; i < grouplist.Count; i++)

{

sb.Append(ReplaceTag(ref reList[i]));

sb.Append(grouplist[i].Value);

sb.Append(ReplaceTag(ref reList[i + 1]));

}

content = sb.ToString();

}

else

{

content = ReplaceTag(ref content);

}

return content;

}

private string ReplaceTag(ref string content)

{

//模板标签{yes},{no},{search}

MatchCollection mc = re.Matches(content);

if (dic == null)

{

dic = LanguageManager.GetResource();

}

for (int i = 0; i < mc.Count; i++)

{

//如果数据库中还没有此字符串

if (!dic.ContainsKey(mc[i].Value.TrimStart('{').TrimEnd('}')))

{

content = content.Replace(mc[i].Value, mc[i].Value.TrimStart('{').TrimEnd('}'));

if (!dic.ContainsKey(mc[i].Value.TrimStart('{').TrimEnd('}')))

{

LanguageManager.AddLanguageString(mc[i].Value.TrimStart('{').TrimEnd('}'));

}

else if (dic[mc[i].Value.TrimStart('{').TrimEnd('}')] == null)

{

content = content.Replace(mc[i].Value, "$$$$");

}

else

{

content = content.Replace(mc[i].Value, dic[mc[i].Value.TrimStart('{').TrimEnd('}')].ToString());

}

return content;

}

protected override void Render(HtmlTextWriter writer)

{

Stopwatch stopwatch = new Stopwatch();

stopwatch.Reset();

stopwatch.Start();

try

{

//会把页面的输出结果存储在这个StringBuilder中

StringBuilder sb = new StringBuilder();

StringWriter sw = new StringWriter(sb);

HtmlTextWriter htw = new HtmlTextWriter(sw);

base.Render(htw);

string content = sb.ToString();

content = RenderTag(ref content);

//重新写入页面

writer.Write(content);

}

catch (Exception ex)

{

Response.Write(ex.ToString());

Response.End();

}

finally

{

stopwatch.Stop();

Response.Write("runtime:" + stopwatch.ElapsedMilliseconds.ToString() + "ms");

}

这样设计的
优点
1、初期写程序时不用关心多语言的翻译工作，只要将所有使用到中文的地方都用{}扩上
2、省去了大量命名相应文字的工作
3、直接用中文标示要显示到页面的文字，容易理解

缺点
1、如果中文是一样的翻译，而其他语言翻译却不一样时不好解决，但这种情况似乎不常见

————————END————————

缺点就是我说的，只能用来做语言包，呵呵。

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>
/// 根据指定的编码格式返回请求的参数集合 ziqiu.zhang 2009.1.19
/// </summary>
/// <param name="request">当前请求的request对象</param>
/// <param name="encode">编码格式</param>
/// <returns>键为参数名,值为参数值的NameValue集合</returns>
public static NameValueCollection GetRequestParameters(HttpRequest request, string encode)
{
NameValueCollection result = null;
Encoding destEncode = null;
//根据指定的编码格式获取Encoding对象
if (!String.IsNullOrEmpty(encode))
{
try
{
//获取指定的编码格式
destEncode = Encoding.GetEncoding(encode);
}
catch
{
//如果获取指定编码格式失败,则默认为null
destEncode = null;
}
}
//根据不同的HttpMethod方式,获取请求的参数.
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;//来源页Url
string tUrl = String.Empty;//目标页Url
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);
//获取OrderFrom判断需要的参数
sUrl = paramList["surl"];
tUrl = paramList["turl"];
//获取OrderFrom的Cookies字符串
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.

虽然我的google adsense广告几乎没有人点，但是今天看到adsense小组说的重复投放的事情，还是有必要转帖一下，帮助其他人，免得重复。。。

AdSense中文小组告诉我们：

自从我们发布了服务器端广告设置这个功能以后，大家修改代码就更加方便了。Google AdSense代码投放的最好办法是直接通过帐户获取代码并嵌入到要投放的网站页面源代码中，但是我们发现有一些网站调整了AdSense广告代码的展示。比如在一部分文学网站和一些内容管理系统中有类似于此的AdSense代码投放方式：

<div id="span_ad_01" style="display:none">
<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div>

<div id=”span_ad_04”></div>
<script>
span_ad_04.innerHTML=span_ad_01.innerHTML;
span_ad_01.innerHTML="";
</script>

该种广告投放方式会导致一个广告位对系统产生多次广告查询，浏览器会多次处理这些请求，这样会影响用户体验。为了避免出现该问题，我们建议您按照以下方式修改广告代码：
1. 直接粘贴您的AdSense代码到页面源代码中
2. 通过iframe调用广告代码，但是一个页面只能嵌入一个iframe单元

AdSense 产品部门正在对广告后台进行一些调整以提升广告投放的准确性，如果您在使用类似上述原理的方式投放Google AdSense广告，那么接下来的这些调整可能会影响到您网站的广告投放。我们建议您尽快按照上述符合要求的方式投放AdSense广告，以避免接下来的调整影响到您网站的AdSense广告投放。

我们注意到大家采用该方式以解决页面内容下载过慢的问题，但是从我们目前的数据和发布商反馈来看，AdSense广告在本地区的投放是不会影响页面内容下载的。

我们会通过系统邮件通知一部分以该方式投放代码的发布商，也希望大家相互转告，尽快实现代码的更换，以避免接下来的产品调整影响您网站的广告展示。如果您对此还有疑问，也欢迎通过支持链接和我们联系。

« 2025年02月 »