挑战！！！谁能用C#开发一个繁体转简体的组件，请报个价？谢谢！！！

我可以帮你搞定，５０００元怎么样？
邮箱：[email protected]
联系！！！

解决方案 »

  1.   

    我也可以帮你搞定，价格你决定。
    邮箱：[email protected]
      

  2.   

    呵呵，刚好前几天我写了一个，发e-mail到[email protected]，我把程序给你？
    满意就给源代码。
      

  3.   

    juqing说得没错,C#本身就可解决.
      

  4.   

    回复人： aluony(阿罗) (  ) 信誉：100  2002-09-05 16:21:00  得分:0  
     
      我可以帮你搞定，５０００元怎么样？
    邮箱：[email protected]
    联系！！！
                   
    ------------->这种人太黑！ 
      

  5.   

    首先声明一下：这个组件我的要求是不用VB中的strconv或者在C#中采用外接查码表文件的方式实现转换，因为这个我也会！没多大意义，到处都有。因为这个组件对于高手来说工作量不会太大，因此我最多出500元。如果你觉得合适，请把测试组件和说明发到这个信箱：[email protected]测试通过马上付款！！！
      

  6.   

    to cwsj (cw)：
    1、strconv不能用
    2、码表不能用
    如果API也不能用我也想不到办法了,另请高手吧.....
    我不要钱，我要一个非测试版Obfuscators。哪个都可以。
    你能找到翻版也可以 :)
    如果要买，这个是最便宜的了：
    http://9rays.net/cgi-bin/components.cgi?act=1&cid=86
      

  7.   

    to juqiang(方枪枪（正在升级为惊艳一枪）) :
    Text.Encoding.Default 可以吗？to ydtime() :
    你不是跟人说话吧？
      

  8.   

    用算法应是可以实现简/繁内码的映射，不然在外面挂一个码表去查询，查到结果再去定位字库，这中间浪费太多的资源和时间。我想这肯定不是好的方法，但自已水平太低，始终未能找出简/繁内码的映射算法。下面是某大虾的高论，说明我的观点
    用JAVA转换简繁体的基础知识 (不用对照表，用算法实现) 
     姜丝 发表于 2001-3-9 18:04:56 Java程序设计 ←返回版面        [快速返回] 汉字编码标准与识别(一)  代码页(Code Page)初识  
    本节是根据以下文章编写出来的，建议认真研读这些专家的高论。  
    参考1 <> 张 轴 材   
    <<计算机世界>>周报 97-1-17  
    参考2 <<张轴材 谈汉字交换码标准建立历程>> <<计算机世界>>周  
    报记者 黄伟敏 肖春江 99-8-30  
    参考3 <<中文平台把住“根”留住>> 吴健 <<中国计算机报>>  
    出版日期：1998-12-21　总期号：348　本年期号：51  
    参考4 <<为种种UNIX中文平台号脉>> 孙玉芳 <<中国计算机用户>>  
    出版日期：1998-07-06　总期号：323　本年期号：26  
    参考5 CJK.INF:ftp://ftp.ora.com/pub/examples/nutshell/ujip/  
    doc/cjk.inf  因为本人只是业余水平，不是专家，对于参考资料中许多术语还不  
    理解，更没有见过任何一种标准的正式文本，错误和模糊之处再所  
    难免。同时，因为国家有关部门对于宣传，推广和贯彻国家标准方  
    面力度不够，致使象我这样的初学者或初涉该领域的小企业因信息  
    资源不足而处于不利的竞争地位。  
    ASCII制订的时候，并没有考虑对多语种，特别是对象中国汉字这样  
    的象形文字的支持。为此后来又提出了不少解决方案，其中代码页  
    体系(ISO2022)是现在普遍实行的方案，而ISO10646/GB13000/Unicode  
    是今后发展的方向。  
    中国的汉字编码标准GB2312是7bits标准，具体说是双7位字节标准。  
    而ASCII是单7位字节标准,计算机怎么区分呢?一种是在第八位置"1",  
    提示计算机转入双字节编码,这是最常见的一种实现,也叫EUC  
    (Extended Unix Code)编码.另一种是用特殊标记提示计算机转入双  
    字节编码,如HZ编码就是用开始，用结束的块标识双字节编码区.它们  
    都是GB2312的一种实现.对象中国汉字这样的象形文字体系，代码页  
    是根据各个国家，地区或行业标准，按照EUC方式编码。代码页向下  
    兼容ASCII，是一种不等长编码。会带来代码的复杂性，同时还会引  
    起因代码页切换而带来的乱码问题。  
    Unicode是一种多字节等长编码。ISO10646/GB13000/Unicode现已在  
    UCS2上实现一致，也就是已实现双字节编码标准。下面所讨论的  
    ISO10646/GB13000/Unicode，就只是指UCS2这种情况。Unicode对  
    ASCII采取前面加"0"字节的策略实现等长兼容。如"A"的ASCII码为0x41,  
    Unicode码就为0x00,0x41。  
    这里主要从国家标准(GB)系列入手了解Unicode。如果不是看了参考5  
    (英文)，我还不知道国家关于汉字编码的标准如此之多。中国人居然  
    要从英文资料里了解汉字编码标准，实在是很无奈的事情。  
    常用中文编码标准 资料来源:CJK.INF  
    GB2312-1980(GB0)(简体) GB7589-1987(GB2)(简体)  
    GB7590-1987(GB4)(简体) GB13000-1993  
    GB6345.1-1986(GB0修正)  
    GB8565.2-1988(GB8,GB0扩充)  
    GB/T12345-90(GB1)(繁体) GB/T13131-9X(GB3)(繁体)  
    GB/T13132-9X(GB5)(繁体)  
    其中横向表示字符集系列。纵向表示各个系列的发展标准。其中  
    GB2312是基本集，也就是目前最常用的标准。GB7589/GB7590是扩展  
    集，使用时可能不能和GB2312共存，需要切换使用。GB7589/GB7590  
    是按部件(部首)和笔顺(笔画)排列，但具体有什么字，怎么排列，  
    用在什么领域，不清楚。GB2312系列经过两次修正和扩充，已和原  
    始的GB2312-1980标准有些不同(参考5)。因为没有标准文本，不知  
    道正在使用的字体是属于哪个标准。根据最新的Unicode3.0，国家  
    标准最新的是GB16500-95 ，更不知是哪个系列的了。ISO/IEC 10646  
    等同于GB13000-1993/JIS0221-1995/KSC5000-1995这些国家标准。  
    制订的目标是包容各语种的文字，其中以汉字最多(Unicode2.0有  
    20902个汉字)。关于标准的特点可以看参考1，制订过程中的风风  
    雨雨，可以看参考2。总之，这是一个我们国家参与并占主导地位  
    的国际标准。  
    GBK是GB2312向GB13000过渡的一个中间产物。它是GB2312的一次大  
    的扩展，编码向下兼容GB2312的EUC编码，字汇(字符集)和GB13000  
    相同，是GB2312的3倍。所以说GBK也包含BIG5，Shift-JIS，KSC的  
    字汇。注意只是包含字汇，而编码与原始的标准是不同的。在具体  
    应用中，用GBK字体就可以同时显示GB2312，BIG5，Shift-JIS，KSC  
    的字符串。但除了GB2312字符串，其它都要转换(convert)。  
    因为语焉不详，不清楚制订GBK时是谁占主导地位。因为有些英文资  
    料说是Microsoft制订了GBK，而国家方面也没有进行说明。目前从  
    这些参考资料只知道，94年ISO/IEC 10646发布后，Microsoft开发  
    Windows95中文版，要制订中文扩展编码。96年《汉字扩展内码规范》  
    GBK发布(参考1~3)。按标准发布比制定晚一年推算，这是95年的事。  
    Windows95及后续版本中文版支持GBK。  
    GB2312的EUC编码范围是第一字节0xA1~0xFE(实际只用到0xF7)，第  
    二字节0xA1~0xFE。GBK对此进行扩展。第一字节为0x81~0xFE，第二  
    字节分两部分，一是0x40~0x7E，二是0x80~0xFE。其中和GB2312相  
    同的区域，字完全相同。扩展部分大概是按部件(部首)和笔顺(笔画)  
    从GB13000中取出再排列入GBK中。因此GBK并不是GB13000，虽然两者  
    字汇相同，但编码体系不同。一个是ISO2022系列不等长编码，一个  
    是等长编码，并且编码区域也不同。注意到GBK实际上不是国家标准。  
    在此之前有一个GB2312基本集，在它之上是一个技术更先进的GB13000。  
    GBK只是一种过渡和扩展规范。所以在Unicode里有GB2312->Unicode,  
    GB12345->Unicode的转换表格，而没有GBK->Unicode转换表格。只有  
    Microsoft制作的Code Page 936(CP936.TXT)可以算作GBK->Unicode  
    转换表格。但要注意这是一个商业公司制作的文件，而不是国家或  
    国际标准组织制作的，有可能与标准有不一致的地方。最近在方正字  
    体网站发现一些有用的标准文件,有兴趣可以下载看看.但要注意  
    Gbk-big5.tab和Gb-big5.tab这两个文件有点瑕疵.  
    http://www.founderpku.com/fontweb/download/Gbk-big5.tab  
    http://www.founderpku.com/fontweb/download/Gb-big5.tab  
    http://www.founderpku.com/fontweb/gb2312.htm  
    http://www.founderpku.com/fontweb/gbk.htm  
    在使用这些转换表制作其它标准的相互转换表，会和传统的转换表  
    有所不同。如用GBK<=>Unicode<=>BIG5制作GBK<=>BIG5转换表，就  
    会和传统的GB<=>BIG5转换表有所不同。主要是汉字有简体和繁体。  
    前者是GBK(中的繁体字)<=>BIG5(繁体字)，后者是GB(简体)<=>BIG5(繁体)。  
    还有就是对一些制表符选用不同。对汉字繁简转换有兴趣的读者，可以看  
    http://www.basistech.com/articles/c2c.html  
    http://www.cjk.org  
    内码与字体的关系  虽然没有标准文本，但还是可以大致了解常用标准有那些字。TLC4.0的  
    字库带有GB2312，GB12345，BIG5，GBK标准的pcf字体。可以用xfd实用  
    程序查看。在http://www.debian.org/chinese下有一个16点阵的Unicode  
    的pcf字体。如果安装了FreeType，可以使用xmbdfed软件查看TTF字体。  
    如果用MS WORD，可能会更简单些。  
    在日常使用中，我们实际上熟悉的是字码(内码).在中文WIN9X下,我们输  
    入一个双八位字节,就得到一个汉字,就会认为这双八位字节就是对应这  
    样的字形.这是错误的.其实内码对于字库来说,只是查找字形的索引.如  
    果换另一个编码标准的字体，同一个字符串就会呈现不同的字形，也就  
    是乱码。我见过GB2312,BIG5和ISO10646/GB13000的TTF字库.对于操作系  
    统和应用程序来说,最喜欢的自然是ISO10646/GB13000的TTF字库了.因为  
    这时只需提供一套代码和一套字库,修改外部配置文件,就可以用在不同的  
    语种环境.这就是国际化和本地化.其中有个技巧就是ISO10646/GB13000的  
    TTF字库可以在使用时可以通过重映射变成其它标准的字库.这时需要的是  
    GBK->Unicode,Big5->Unicode这些转换表.一个系统要升级支持Unicode3.0,  
    也难也不难.简单的地方是只需修改转换表就行了(如windows
    ls*.*).  
    难的是要升级字库.开发字库是很困难的,可以到方正字库网站看看开发字  
    库的步骤.WIN9X使用的是北京中易公司的TTF字库,MS是不可能开发一套中  
    文字库的.我所见过的ISO10646/GB13000的TTF字库,最新的是99年版,Unicode2.1 
    ,  
    方正字库.要想见到Unicode3.0的所有字形,也只有等这些专业字库开发商  
    做出来才行.如果现在就想看,只有问张轴材了.因为每通过一次新标准,中  
    国方面就要提供所有汉字的48x48高精密字形.使用TTF字体始终是诱人的话  
    题。但现在了解不多，只能简单谈谈从TTF字体生成bdf/pcf字体的问题。  
    因为现在中文pcf字体很少，只有宋体，仿宋，黑体，楷体四种。要想有更  
    多的字体，有个取巧的方法就是使用freetype库。用ttftobdf程序生成bdf  
    字体，再用bdftopcf程序生成pcf字体。但这种方法生成的字体缩放后比较  
    难看，而且不宜控制。这可能是ttf->bdf的转换过程丢失了信息，高宽比  
    也和标准的不一样。机器生成的东西就是机械，是不能和手绘的字体相比  
    的。同时，因为TTF技术已成熟，所以也没有必要继续开发更多的pcf字体。  
    X window将接受和大量使用TTF字体。而pcf字体今后主要用在标准字型  
    （如宋体），小点阵，网上快速下载传输方面。只有实际在X Window下用  
    过Unicode和TTF的字体，才会体会到使用Unicode和TTF，既是一种能力，  
    也是一种负担。因为不论是什么格式的字体文件，最后在使用时都转化为  
    内存里固定点阵字体。如果是16x16点阵，一个汉字就用32字
      

  9.   

    既然你都愿意使用c#的类来完成转换，那为什么不愿意使用vb.net中现成的函数呢？
    不过遗憾的是c#中并无类可解决转换问题。
      

  10.   

    我已经做了一个给这位先生发过去了！
    很easy的事情，搞得那么复杂！！！