中文和 unicode 实现除了在服务器端实现，javascript 同样可以实现：
[javascript]
js文件中，有些变量的值可能会含有汉字，画面引入js以后，有可能会因为字符集的原因，把里面的汉字都变成乱码。后来发现网上的一些js里会把变量中的汉字都表示成”\u“开头的16进制编码，这样应该可以解决上面的问题。
最近有时间在网上查找了一下实现方式，一种比较大众化的：
function tounicode(data)
if(data == '') return '请输入汉字';
var str ='';
for(var i=0;i&data.i++)
str+="\\u"+parseInt(data[i].charCodeAt(0),10).toString(16);
function tohanzi(data)
if(data == '') return '请输入十六进制unicode';
data = data.split("\u");
var str ='';
for(var i=0;i&data.i++)
str+=String.fromCharCode(parseInt(data[i],16).toString(10));
还找到一个相对简单一些,但比较另类的:
var GB2312UnicodeConverter={
ToUnicode:function(str){
return escape(str).toLocaleLowerCase().replace(/%u/gi,'\\u');
,ToGB2312:function(str){
return unescape(str.replace(/\\u/gi,'%u'));
不过都有些问题，这两种方式，都会把出汉字以外的其他字符都给转换掉，做个简单的加密解密算法还是可以的，但要是用来处理js文件，把回车、换行、空格、tab字符全换了，转完以后，js文件也没法运行了。
偷懒不成，只能自己按照上面代码处理逻辑写一个了，只要保证只转换汉字字符就可以了：
// 汉字转为Unicode字符码表示
function toUnicode(s){
return s.replace(/([\u4E00-\u9FA5]|[\uFE30-\uFFA0])/g,function(){
return "\\u" + RegExp["$1"].charCodeAt(0).toString(16);
方法写完了，为了方便转换js文件的内容，再做个简单的页面，加一个button在画面上。先要做的是在js文件Ctr+A，Ctr+C，把内容拷贝 到剪贴板里，然后再新建的这个画面上，点button的时候，从剪贴板里把内容读出来，调用方法转一下，在把内容放回剪贴板。然后再到 js文件里Ctr+A，Ctr+V一下就可以了。代码如下：&html&
&script language="javascript"&
function Window_Load(){
var G = document.getElementById;
G("cmdToU").onclick = function(){
clipboardData.setData("text",toUnicode(clipboardData.getData("text")));
// 汉字转为Unicode字符码表示// 原函数是，红色是是错误的，导致多个中文时，结果都是最后一个汉字的unicode码；
function toUnicode(s){
return s.replace(/([\u4E00-\u9FA5]|[\uFE30-\uFFA0])/g,function(){
return "\\u" + RegExp["$1"].charCodeAt(0).toString(16);
} 　　　　// 经@b4b4指正，现更改
　　　　function toUnicode(s){
return s.replace(/([\u4E00-\u9FA5]|[\uFE30-\uFFA0])/g,function(newStr){
return "\\u" + newStr.charCodeAt(0).toString(16); 　　　　　　}); 　　　　}
&/script& &/head& &body onload="Window_Load();"& &button id="cmdToU"&汉字转为Unicode&/button& &/body& &/html&
这个页面只能在IE内核的浏览器下才能正常运行，因为clipboardData对象好像只在IE下面有。
没有更多推荐了，当前位置浏览文章
最普遍的答案我一直就觉得GET和POST没有什么除了语义之外的区别，自打我开始学习Web编程开始就是这么了解的。可可以很多人都已经猜到了，他要的答案是：GET用URL或者Cookie传参。而POST将数据放在BODY中。GET的URL会有长度上的限制，则POST的数据则能非常大。POST比GET安全，由于数据在地址栏上不可见。但是很不幸，这些区别全是错误的GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，用哪个Method与应使用层的数据如何传输是没有相互关系的。HTTP没有要求，假如Method是POST数据就要放在BODY中。也没有要求，假如Method是GET，数据（参数）就肯定要放在URL中而不可以放在BODY中。那么，网上流传甚广的这个说法是从何而来的呢？我在HTML标准中，找到了类似的形容。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的使用法的商定。怎样可以当成GET和POST的区别呢？而且，现代的Web Server都是支持GET中包含BODY这样的请求。尽管这种请求不可可以从浏览器发出，但是现在的Web Server又不是只给浏览器使用，已经完全地超出了HTML服务器的范畴了。知道这个有什么使用？我不想解释了，有时候就得自己痛一次才记得住。 HTTP协议对GET和POST都没有对长度的限制HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的起因造成：浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下是正常的。网上的东西，哪怕是Wikipedia上的，也不可以信。服务器。URL长了，对服务器解决也是一种负担。本来一个会话就没有多少数据，现在假如有人恶意地构造几个几M大小的URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数，而后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种成心的次次访问超时也可以让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳固啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。 安全不安全和GET、POST没有关系服务器开放接口是基于REST理念设计的，用的协议是HTTP，但是传输的内容不是HTML。这不是Web Server，而是一个Web Service）所以我对于GET和POST的了解，是纯粹地来源于HTTP协议。他们只有一点根本区别，简单点儿说，一个使用于获取数据，一个使用于修改数据。具体的请参考RFC文档。假如一个人一开始就做Web开发，很可可以把HTML对HTTP协议的用方式，当成HTTP协议的唯一的正当用方式。从而犯了以偏概全的错误。可可以有人会觉得我钻牛角尖。我只是不喜欢模棱两可，不喜欢边界不清、概念不明，不喜欢“拿来主义”，也不喜欢被其它喜欢钻牛角尖的人奚落得无地自容。“知之为知之，不知为不知，是知也。”}