不需要像很多讨论到的要转码甚至有人写出大段的转码程序，当然，客户端如果是别的编码方式，
改一下就行了。
2.2. 客户端用 JSON 方式处理接收数据时，eval() 函数不能正确地把收到的数据解释为代码片段
比如用 var obj = eval( "{ p1:1, p2:2 }" ) 这样的形式，obj 是不能正确被初始化为对象实例的，而是会
收到一个缺少分号的错误，而用 eval( "var obj = { p1:1, p2:2 }" ) 这样的形式，就能正确地生成一个
obj 的有效对象实例。
其实仔细想一下，似乎也对，eval() 并不是如书上所讲，直接把串作为代码的一部分插入到整个代码
段中，而是返回转入的表达式的值，而以‘{...}'的形式定义的空函数对象，其表达式值本身是
undefined，而若其中成员多于一个，则此表达值根本不能作为合法语法独立存在，所以才会报错；
而后一种形式，其实质其实是一个赋值表达式，虽然前缀了 var 会导致整个表达式值为 undefined，
但此过程中却真实地生成了 obj 对象实例。在之后的上下文中引用 obj 就是有效的了。
经过实验看来，书上和部分前辈文章提到的第一种用法，其实是不能正确工作的，至少在我的机器
上，它确实失败了。当然，不能不考虑有可能是我的浏览器甚至是 OS 本身的原因，这个就深了。
解决：不管有多深，问题总是要解决的。也很简单，只需要按第二种形式，把接收变量的定义一起放
到 eval() 中，即可正常工作。
另外，回转 JSON 数据时，也要考虑B/S双方编码问题，如果不一致，按 2.2 中的方法即可解决。
很重要的一点是，有时候 debug 或 trace 出来的结果，特别是字符串，看起来确实是正确的，但就
是不能正常工作，那时候就需要从编码的层次去验证，而不要仅仅考虑代码本身逻辑的问题。因为有
些非打印编码，在 debug 和 trace 时都是不会被回显到屏幕上的。“眼见非实”，这一点，在任何
地方永远适用。
综合感受
Ajax 作为一种技术，其本身并无先进之处，相反过多地依赖和信仰会令其成为开发中的累赘，大量
的精力耗费在基础工作中，思路游离于业务逻辑之外，这是一件好事，可以令你的工作更快地以失败
告终。
但，Ajax 作为一种思想，反而是值得推崇的，这种思想，早已经由卖童装的美特斯邦威作出了精辟
的概括——不走寻常路。
数年来，在世界各地，
