易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

易栈网-膘叔

ChangeLog

jQuery插件——文章自动生成导航

xml?xsl?css?xhtml

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

PHP函数：debug_backtrace()

ChangeLog

好图

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

jQuery插件——文章自动生成导航

xml?xsl?css?xhtml

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

PHP函数：debug_backtrace()

ChangeLog

好图

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

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

这个插件很实用，适合那种写着教程内容的页面，以前如果有多个标题的话，必须一个一个的加锚点，然后再加链接，这样不太方便。所以看到这个插件的时候，我忍不住记录下来。

代码我没有细看，我只看了demo，自己觉得还是很有用的。
代码来自CSSRain.cn，图片同样来自他那里。
网站说：

XML/HTML代码

首先根据文章自动在右上角生成导航菜单，
然后导航菜单可以跟随滚动条滚动，实时导航。
导航采用平滑方式，更人性化。
演示：
http://cssrain.cn/demo/createTitle/title.html
下载：
http://cssrain.cn/demo/createTitle/createTitle.rar
有问题请留言，只测试了 google 和 firefox 。

不过，IE或者其他的一些多窗口版的浏览器，会不会把它当成AD层屏蔽掉呢？
截图：

源码分流：
createtitle.rar

虽然，我写页面代码都是editplus写的，从来不用DW或者其他所见所得编辑器，但并不代码我的CSS就写的特别好，其实我一直很有疑问。CSs是否就是王道？

然后我看到这篇文章，觉得也是我心里想的东西。就贴出来了。。。

其实去年年底，jQuery 1.3尚未发布的时候就已经盘算着将中文文档以xml的形式发布了。这样有个好处，就是页面结构可以用xsl随便换。各位同学想做不同的发行版可以随便换着玩~实际上我现在愈发觉得css的局限性了，很多时候所谓的css为了后期维护方便，可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。我就不信有多少同学遇到过改版的时候只改css而不改html的。当然也有可能是我的局限性而非css的局限性。

所谓的圣杯布局和双飞翼布局确实在很大程度上能解决布局(Layout)上的问题，但别忘了，开发工作可不只是布局，还有排版(Typography)，数据结构和页面表现结构交织在一起的时候，想崩溃都觉得老板会从地域里拖你起来。

xml+xslt这种手段其实我几年前就看到过，当时也曾为之心动，无奈当时技术水平有限无法体会其中精妙。然借此jQuery 1.3文档大改之际便又萌发了尝试的冲动。

xml+xslt好吗？很好！居然ie 5就开始支持了，ie 6支持的程度也很不错，基本上没有遇到什么兼容性问题，比起万恶的ie6对css的支持度好多了。目前我除了发现document()函数在ie中表现的跟其他浏览器不一致之外，以及Firefox居然不支持disable-output-escaping=”yes”，并且争论长达7年多尚未有解决的迹象。除此之外似乎没发现更多问题。

实际上让一部分处理页面的逻辑放到了前端来做，后台只负责输出数据，这种数据（XML），结构(XSLT)，表现(CSS)，行为(JS)4者相对分离的状态是十分有利于这个前端产业工业化发展的。随着前端工种的进一步细分，我觉得这里大有可挖。好处显而易见，如果要大面积改版（即便是小范围），由于后台只负责输出数据而没有HTML格式，高度分离的情况下，基本上只需要前端小组改一下即可。即便是对后台语言完全不了解都可以（我承认这不好）。
此外，xslt支持include/import等语句，包括上面提到的document()，可以很方便的实现页面各个部分的模块化。

但随之带来的问题也显而易见，数据过于结构化，页面内容轻易被人抓取而后分析（都不用分析……直接解析……）
此外，很多pda，手机之类的可能对xslt无法解析，但我估计屏幕阅读器应该没问题，因为很多屏幕阅读器都是基于现有浏览器的，也就是说现有浏览器支持，他也就支持。
还有上面提到的模块化问题，一不小心就可能导致连接数过多。每个模块的粒度得把握好。

解决这些问题的一个简单途径是，xml+xslt在服务器端解析生成。服务器端可以通过检测浏览器来判断直接输出xml+xslt还是输出生成的页面。这对于pda和手机之类的能提高很大兼容性。而对于一般浏览器又无需消耗服务器资源。
网上有篇流传甚广的文章XML在B/S架构开发中的应用，正是描述了此类情景。我考据下来可能是原著地址（我找到个更早的地址但上面的写的作者也是他，请宽恕我的网络考古情结）。

其中也提到了http://xml.apache.org/cocoon/ 似乎可以直接使用，没深究。

好了，得回到正题了。jQuer现在弄了个专门是放api的地址:http://api.jquery.com。说实话，我一直很不喜欢他现在弄的样子，当我需要在不同的方法之间切换的时候很不方便。有喜欢的可以自己尝试。另外，分析代码发现原来这个api也是从 wiki里扣出来的xml进行解析得来的。另有air版，喜欢的可以自己下。扣的程序是Python 2.4写的，遗憾我这里只有Py3k环境，执行失败，且自己道行过浅，无法改成3.0版以供自己用。忘有此能力的同学能帮我改一下，可直接从jq的svn 里拿到，点击下载。没有达人帮忙其实也没事，见到还有地址可以在线生成，前面在线生成的地址如果不加参数则可以直接查看这个生成器的文档。用urllib.request.urlretrieve(url,path)直接下载真的是很惬意的事情，Python真的是很强悍啊……
我随便写了个xslt，可以直接浏览jQuery 的英文文档。暂不提供下载，喜欢的就自己另存为吧……不喜欢的就自己写一套吧……
暂时计划是将中文文档转换成xml（这步已经在前天完成，转的我残念……请原谅我能力有限只能用这么离奇的办法转格式……）。不过之前写这个的时候还没有看到上面那个wiki2xml生成器（其实早就见过了，被我无视了而已……），所以对应的标签以及格式还不是很对上号。改天整整。另外，单个xml拆分成散件的xml的py脚本也写完了，实验成功，现在生成chm版的文档只差单文件xml的校对和chm文件的目录以及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……
原文：http://shawphy.com/2009/01/about-jquery-xml-doc.html

————————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.

不知道你的函数在哪里被调用了？没关系。。
不知道你的函数在哪行？哪个方法？哪个参数里被触发？没关系。
请使用 debug_backtrace函数吧。

呵呵，好象广告一样。

看到这个函数，其实是有点意外的，本来是想好好的做一个LOG，然后想用个观察者模式，最初的发现是，如果我不主动将行数、函数名放进参数里，那就很难在处理的时候，得到这些信息，可以让我快带定位。

结果就看到了这个函数：debug_backtrace();

Table 1. Possible returned elements from debug_backtrace()

Name	Type	Description
function	string	The current function name. See also __FUNCTION__.
line	integer	The current line number. See also __LINE__.
file	string	The current file name. See also __FILE__.
class	string	The current class name. See also __CLASS__
object	object	The current object.
type	string	The current call type. If a method call, "->" is returned. If a static method call, "::" is returned. If a function call, nothing is returned.
args	array	If inside a function, this lists the functions arguments. If inside an included file, this lists the included file name(s).

Version	Description
5.1.1	Added the current object as a possible return element.

仔细看看还是挺有必要的，这些参数，对象都非常重要。。
让我很难过的是，看到这些，我还有必要写LOG吗？当然也只是说说，要想让LOG的信息更完整，对于这些取回来的信息，还是需要作进一步处理的

看到好图不敢独享，是QQ里，其他好友当表情发来的。
于是发在博客上，也算是祝福新年

顺便说一下，晚上写年终总结

« 2025年07月 »