多语言网站开发(转)

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

多语⾔⽹站开发(转)

多语⾔⽹站,顾名思义就是能够以多种语⾔(⽽不是单种语⾔)为⽤户提供信息服务,让使⽤不同语⾔的⽤户都能够从同个⽹站获得内容相同的信息。

多语⾔⽹站实现⽅案

1,静态:就是为每种语⾔分别准备⼀套页⾯⽂件,要么通过⽂件后缀名来区分不同语⾔,要么通过⼦⽬录来区分不同语⾔。

例如对于⾸页⽂件 index_en.htm提供英语界⾯,index_gb.htm提供简体中⽂界⾯,index_big.htm提供繁体中⽂界⾯,或者是 en/index.htm 提供英语界⾯,gb/index.htm提供简体中⽂界⾯,big/index.htm提供繁体中⽂界⾯,⼀旦⽤户选择了需要的语⾔后,⾃动跳转到相应的页⾯,⾸页以下其他链接也是按照同样⽅式处理。从维护的⾓度来看,通过⼦⽬录⽐通过⽂件后缀名来区分不同语⾔版本显得要简单明了。

2,动态:站点内所有页⾯⽂件都是动态页⾯⽂件(PHP,ASP等)⽽不是静态页⾯⽂件,在需要输出语⾔⽂字的地⽅统⼀采⽤语⾔变量来表⽰,这些语⾔变量可以根据⽤户选择不同的语⾔赋予不同的值,从⽽能够实现在不同的语⾔环境下输出不同的⽂字。

例如:语⾔变量ln_name,当⽤户选择的语⾔是英语时赋值为“Name”,当⽤户选择的语⾔是简体中⽂时赋值为“姓名”,这样就可以适应不同语⾔时的输出。

采⽤静态⽅式的优点是页⾯直接输出到客户端,不需要在服务器上运⾏,占⽤服务器的资源⽐较少,系统能够⽀持的并发连接数较多,缺点是要为每种语⾔制作⼀套页⾯⽂件,很多内容即使是和语⾔⽆关的也要分不同语⾔来存储,因此占⽤的存储空间较多。

采⽤动态⽅式和静态⽅式的优缺点正好相反,它的优点是动态页⾯⽂件只有⼀套,不同语⾔的⽂字使⽤语⾔变量来存储,和语⾔⽆关的内容只存储⼀份,占⽤的存储空间较少,并且扩展新语⾔⽐较容易,缺点需要在服务器上运⾏,然后把结果输⼊到客户端,占⽤服务器的资源⽐较多,系统能够⽀持的并发连接数较少。

动态数据存贮涉及的⼀些技术问题

由于现在⽹站上动态应⽤⽇益增多,相当多的⽹站还会使⽤⽂件或者数据库来存储应⽤信息,因此如果⽂件或者数据库中存储的内容与语⾔相关时,还需要特别注意。对于存储在数据库中信息,可以采取以下⼏种⽅式⽀持多语⾔:

1,在数据库级别⽀持多语⾔:为每种语⾔建⽴独⽴的数据库,不同语⾔的⽤户操作不同的数据库。

2,在表级别⽀持多语⾔:为每种语⾔建⽴独⽴的表,不同语⾔的⽤户操作不同的表,但是它们在同⼀个数据库中。

3,在字段级别⽀持多语⾔:在同⼀个表中为每种语⾔建⽴独⽴的字段,不同语⾔的⽤户操作不同的字段,它们在同⼀个表中。

由于数据库中有⼤量的信息(如标志,编码,数字等)是⽤于内部处理使⽤的,与语⾔⽆关的,因此在数据库级别⽀持多语⾔会导致空间的极⼤浪费,在字段级别⽀持多语⾔最⼤的问题是⼀旦需要⽀持新的语⾔,由于需要修改表结构,维护起来⾮常⿇烦,可扩展性不好。

相⽐之下,在表级别⽀持多语⾔⽐较好,因为并不是所有的表都需要⽀持多语⾔,对于与语⾔⽆关的表,不同语⾔的⽤户共⽤⼀套,那些和语⾔相关的表根据⽀持语⾔的种类来建⽴,不同语⾔的⽤户存取访问不同的表格。这样使得维护简单,节省了存储空间,即使是扩展起来也⽐较⽅便,只要把需要⽀持多语⾔的表,多建⽴⼀套即可。

还需要注意的问题是:有些表中某些字段是不同语⾔版本的表共享的(例如库存量),由于各种语⾔的表之间的相对独⽴性,使得数据共享有些困难。解决的⽅法有两个:

1,不同语⾔的表的共享字段同步:也就是说,只要修改了其中⼀个表的共享字段,其他语⾔表中该字段也作相应改变,实际上当不同语⾔的⽤户同时访问时处理还是⽐较⿇烦的,并且扩充新语⾔时修改⼯作⽐较⼤。

2,增加⼀个新的表:把所有语⾔共享的字段(例如货物编号,产地编码等)全部放在这个表,⽀持多语⾔的表只存放与各种语⾔相关的字段。不同语⾔的⽤户在使⽤数据库时,需要操作两个数据表。

⽐较⽽⾔,第⼆种⽅法⽐较简单,并且效率⽐较⾼,维护也⽐较⽅便。

应⽤字符集的选择

⼀个定位于不同语⾔国家的企业⽹站势必需要提供多种语⾔版本的产品和销售信息来满⾜其世界各地使⽤不同语⾔的客户和合作伙伴,其中包括法语、德语、意⼤利语、葡萄⽛语、西班⽛语、阿拉伯语等等。但有⼀个问题却极易被⽹站设计者们所忽略。这就是⽹站的字符集设置问题。

⼀般我们使⽤的是简体中⽂(GB2312)字符集,⽽对多语⾔⽹站来说,中⽂字符集却可能会使你⾟⾟苦苦的努⼒功亏⼀篑。原因很简单:就是这个毫不起眼的⼩⼩字符集在作怪。

计算机应⽤领域中存在着⼏⼗种互不相同的字符集,⽽不同语⾔客户在浏览不同语⾔⽹页时,往往会因为相互间所使⽤字符集⽆法兼容⽽出现乱码情况。我们在浏览国外⼀些⽹站时,往往也会出现为了能正常地看到⽹站上的信息⽽不得不在各种字符集之间来回切换的情况。

试想⼀下:如果⼀个⽹站提供了中,英,法,德等多种语⾔版本的内容,内容全之⼜全,设计美仑美奂。我们在中⽂编码环境下浏览这些⾮

中⽂版本的页⾯觉得⾮常完美,现在⼀个法国客户对你的产品发⽣了兴趣,当他进到法语版⾯⼀看—乱码多多,甚⾄可能整个版⾯都⼀塌⾥糊涂。你的⽹站再下⼤⼯夫⼜有什么意义呢?

所以对提供了多语⾔版本的⽹站来说,Unicode字符集应该是最理想的选择。它是⼀种双字节编码机制的字符集,不管是东⽅⽂字还是西⽅⽂字,在 Unicode中⼀律⽤两个字节来表⽰,因⽽⾄少可以定义65536个不同的字符,⼏乎可以涵盖世界上⽬前所有通⽤的语⾔的每⼀种字符。所以在设计和开发多语⾔⽹站时,⼀定要注意先把⾮中⽂页⾯的字符集定义为“utf-8”格式。

这⼀步⾮常重要,原因在于若等页⾯做好之后再更改字符集设置,可说是⼀件⾮常⾮常吃⼒不讨好的⼯作,有时候甚⾄可能需要从头再来,重新输⼊⽹站的⽂字内容。

HTML中的META标签:

<META HTTP-EQUIV=“Content-Type” CONTENT=“text/html; CHARSET=字符集">

不写,根据浏览器默认字符集显⽰

charset=gb2312 简体中⽂

charset=big5 繁体中⽂

charset=EUC_KR 韩语

charset=Shift_JIS 或 EUC_JP ⽇语

charset= KOI8-R / Windows-1251 俄语

charset=iso-8859-1 西欧语系(荷兰语,英语,法语,德语,意⼤利语,挪威语,葡萄⽛语,瑞⼠语.等⼗⼋种语⾔)charset=iso-8859-2 中欧语系charset=iso-8859-5 斯拉夫语系(保加利亚语,Byelorussian语,马其顿语,俄语,塞尔维亚语,乌克兰语等)

charset=uft-8 unicode多语⾔

PHP与脚本引擎页码的概念

由于我们传统使⽤的内码像Big5,GB2312与unicode并不是⼀⼀对应,故两者之间的转换要靠codepage(页码)来实现

<?php=Language=VBScript CodePage=xxx?>

不写,根据服务器端解析引擎默认代码页⾃动解析并返回浏览器。

如果制作的⽹页脚本与WEB服务端的默认代码页不同,则必须指明代码页:

codepage=936 简体中⽂GBK

codepage=950 繁体中⽂BIG5

codepage=437 美国/加拿⼤英语

codepage=932 ⽇⽂

codepage=949 韩⽂

codepage=866 俄⽂

codepage=65001 unicode UFT-8

相关文档
最新文档