[组件代码分享]中文简体/中文繁体/BIG5互转,支持VB/ASP
以前发过的,现在兑现承诺,把代码公布
我其实也只是把一些代码组织了一下而已
中文文字转换组件 1.0
***************************************************************
版本历史：
***************************************************************
2004年12月10日 V1.0
基本功能：
支持VB/ASP编程，免费，没有任何限制
支持以下转换:
1.简体转繁体 //方法：GB2FT
2.简体转BIG5 //方法：GB2BIG5
3.繁体转简体 //方法：FT2GB
4.BIG5转换简体 //方法：BIG52GB
输入参数：要转换的字符串
返回值：转换完成的结果
具体使用方法请参见示例文件
使用前先用
Regsvr32 组件路径/BABYT_CNCODE.Dll进行注册
***************************************************************
作者
***************************************************************
CSDN-Babyt(阿泰)
www.facesun.cn
http://blog.csdn.net/babyt
20041210
代码下载地址:
http://www.facesun.cn/portal/download/CncodedllRelease.rar
包含完整的代码和VB/ASP示例
其他两个代码有需要的也看一下,准备结贴了
纯ASP代码之公历转农历实现(含属相)
http://community.csdn.net/Expert/topic/3792/3792980.xml?temp=.5458643
[组件代码共享]可逆加密,支持中文,支持密钥,支持ASP,加密后的密文每次都不同,且可随意改变算法
http://community.csdn.net/Expert/topic/3796/3796525.xml?temp=.5696985
另外2000高分求水晶报表的部署方案,希望大家帮顶一下 ^_^
http://community.csdn.net/Expert/topic/3799/3799097.xml?temp=1.272219E-02
问题点数：20、回复次数：18Top
1 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-22 22:32:23 得分 8
问问：
你的GB是指那个GB？
GB2312-1980？！
GB2312-1980在1993就淘汰了
1993年出了一个GB13000的汉字标准
收录2万多字
是GB2312和Big5的超集
现在最新的汉字标准是GB18030-2000
2000出来的
允许4字节编码
编码空间多了260万
其实从Windows95中文版开始
Windows系统就提供了简繁转换功能
LCMapString
The LCMapString function maps one character string to another, performing a specified locale-dependent transformation. The function can also be used to generate a sort key for the input string.
int LCMapString(
LCID Locale, // locale identifier
DWORD dwMapFlags, // mapping transformation type
LPCTSTR lpSrcStr, // address of source string
int cchSrc, // number of characters in source string
LPTSTR lpDestStr, // address of destination buffer
int cchDest // size of destination buffer
);
Parameters
Locale
Specifies a locale identifier. The locale provides a context for the string mapping or sort key generation. An application can use the MAKELCID macro to create a locale identifier.
dwMapFlags
A set of flags that indicate the type of transformation to be used during string mapping or sort key generation. An application can specify more than one of these options on a single transformation, although some combinations are invalid. The following mapping options are defined; restrictions are noted following the table: Option Meaning
LCMAP_BYTEREV Windows NT: Use byte reversal. For example, if you pass in 0x3450 0x4822 the result is 0x5034 0x2248.
LCMAP_FULLWIDTH Wide characters (where applicable).
LCMAP_HALFWIDTH Narrow characters (where applicable).
LCMAP_HIRAGANA Hiragana.
LCMAP_KATAKANA Katakana.
LCMAP_LINGUISTIC_CASING Use linguistic rules for casing, rather than file system rules (the default). Valid with LCMAP_LOWERCASE or LCMAP_UPPERCASE only.
LCMAP_LOWERCASE Use lowercase.
LCMAP_SIMPLIFIED_CHINESE Map simplified Chinese characters to traditional Chinese characters.
LCMAP_SORTKEY Produce a normalized wide-character sort key.
LCMAP_TRADITIONAL_CHINESE Map traditional Chinese characters to simplified Chinese characters.
LCMAP_UPPERCASE Use uppercase.
NORM_IGNORECASE Ignore case.
NORM_IGNOREKANATYPE Do not differentiate between Hiragana and Katakana characters. Corresponding Hiragana and Katakana will compare as equal.
NORM_IGNORENONSPACE Ignore nonspacing. This flag also removes Japanese accent characters.
NORM_IGNORESYMBOLS Ignore symbols.
NORM_IGNOREWIDTH Do not differentiate between a single-byte character and the same character as a double-byte character.
SORT_STRINGSORT Treat punctuation the same as symbols.
If the LCMAP_SORTKEY flag is not specified, the LCMapString function performs string mapping. In this case the following restrictions apply:
LCMAP_LOWERCASE and LCMAP_UPPERCASE are mutually exclusive.
LCMAP_HIRAGANA and LCMAP_KATAKANA are mutually exclusive.
LCMAP_HALFWIDTH and LCMAP_FULLWIDTH are mutually exclusive.
SORT_STRINGSORT, NORM_IGNOREKANATYPE, NORM_IGNOREWIDTH, and NORM_IGNORECASE are not valid.
LCMAP_TRADITIONAL_CHINESE and LCMAP_SIMPLIFIED_CHINESE are mutually exclusive.
LCMAP_LOWERCASE and LCMAP_UPPERCASE are not valid in combination with any of the following flags: LCMAP_HIRAGANA, LCMAP_KATAKANA, LCMAP_HALFWIDTH, and LCMAP_FULLWIDTH.
When the LCMAP_SORTKEY flag is specified, the LCMapString function generates a sort key. In this case the following restriction applies:
LCMAP_SORTKEY is mutually exclusive with all other LCMAP_* flags, with the sole exception of LCMAP_BYTEREV.
lpSrcStr
Pointer to a source string that the function maps or uses for sort key generation.
cchSrc
Specifies the number of bytes (ANSI version) or characters (Unicode version) in the string pointed to by the lpSrcStr parameter.
This count can include the NULL terminator, or not include it. If the NULL terminator is included in the character count, it does not greatly affect the mapping behavior. That is because NULL is considered to be unsortable, and always maps to itself.
A cchSrc value of –1 specifies that the string pointed to by lpSrcStr is null-terminated. If this is the case, and LCMapString is being used in its string-mapping mode, the function calculates the string's length itself, and null-terminates the mapped string stored into *lpDestStr.
lpDestStr
Pointer to a buffer into which the function stores the mapped string or sort key.
If LCMAP_SORTKEY is specified, LCMapString stores a sort key into the buffer. The sort key is stored as an array of byte values in the following format:
[all Unicode sort weights] 0x01 [all Diacritic weights] 0x01 [all Case weights] 0x01 [all Special weights] 0x00
Note that the sort key is null-terminated. This is true regardless of the value of cchSrc. Also note that, even if some of the sort weights are absent from the sort key, due to the presence of one or more ignore flags in dwMapFlags, the 0x01 separators and the 0x00 terminator are still present.
cchDest
Specifies the size in bytes (ANSI version) or characters (Unicode version) of the buffer pointed to by lpDestStr.
If the function is being used for string mapping, the size is a character count. If space for a NULL terminator is included in cchSrc, then cchDest must also include space for a NULL terminator.
If the function is being used to generate a sort key, the size is a byte count. This byte count must include space for the sort key 0x00 terminator.
If cchDest is zero, the function's return value is the number of characters, or bytes if LCMAP_SORTKEY is specified, required to hold the mapped string or sort key. In this case, the buffer pointed to by lpDestStr is not used.
Return Values
If the function succeeds, and the value of cchDest is nonzero, the return value is the number of characters, or bytes if LCMAP_SORTKEY is specified, written to the buffer. This count includes room for a NULL terminator.
If the function succeeds, and the value of cchDest is zero, the return value is the size of the buffer in characters, or bytes if LCMAP_SORTKEY is specified, required to receive the translated string or sort key. This size includes room for a NULL terminator.
If the function fails, the return value is 0. To get extended error information, call GetLastError. GetLastError may return one of the following error codes:
ERROR_INSUFFICIENT_BUFFER
ERROR_INVALID_FLAGS
ERROR_INVALID_PARAMETER
QuickInfo
Windows NT: Requires version 3.1 or later.
Windows: Requires Windows 95 or later.
Windows CE: Requires version 1.0 or later.
Header: Declared in winnls.h.
Import Library: Use kernel32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT.
Top
2 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-22 22:36:06 得分 0
Big5也早就淘汰了
现在最新标准是CNS11643
http://www.clyrics.com/stonec/hanzi/twhzcode.htm
CNS11643国家标准中文交换码
GB13000标准：
http://dbsvr.ynst.net.cn:6006/jsjpdf/GB13000.1-1993.pdf
GB18030标准：
http://dbsvr.ynst.net.cn:6006/jsjpdf/GB18030-2000.pdf
Top
3 楼babyt（阿泰）回复于 2005-02-22 22:45:08 得分 0
呵呵,很多东西都被淘汰了.
有人开奔驰宝马,有人仍在走路
要看实际情况和环境Top
4 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-22 23:19:15 得分 0
现在还有人用DOS+UCDOS码？
我喜欢用Win98别人都嫌我土
其实楼主还是很有上进心的
但是没深刻感受到编程行业的发展速度
我是从DOS时代过来的
历经32位Windows环境带来的冲击
马上就要进入64位时代了
现有的Win32位编程资料很快就要过时了
学会了GB2312是一个进步
但是还是离前沿太远了
要学的东西太多了
Top
5 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-22 23:28:06 得分 0
其实我很早以前就有一个想法：
想编一个能在DOS下看GB18030、CNS11643编码的文件的文本阅读器
但现在看起来是不可能了Top
6 楼babyt（阿泰）回复于 2005-02-22 23:34:14 得分 0
刚才看了 zyl910(910：分儿，我又来了！) 的几个连接,长了不少见识
我其实就是把一些代码整理了一下,说到研究,我就差远了
做程序员都能感受到行业的发展和形势的严峻,
不过话说回来,64位的软件的大规模应用,其实还挺远的,还要那么好几年Top
7 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-22 23:56:38 得分 0
Java与.Net之争只是附加效果
Microsoft推出.Net主要是为了向64位系统过渡
因为64位Windows肯定要跨IA32、IA64、AMD64三大平台
本机编译的代码只有1/3能运行的几率
这时候只有依赖虚拟机技术来跨平台
.Net平台是2002年出的
说明Microsoft在2002年以前就考虑64位问题了
Top
8 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-23 00:06:51 得分 0
我是在去年（2004）醒悟的
那天看了关于Microsoft下一代操作系统Longhorn的介绍
发现它的体系结构在很多方面与Win32不同
而且据说Longhorn将在2005年推出
再配合Microsoft曾经宣布2008年放弃VB6的技术支持
估计2008年左右，64位会成为主流
当年1995年Windows95推出时
有多少人怀疑它
甚至许多游戏开发者坚决反对Windows
可到1998年时
还有几个人用DOS
十年就是一代啊！
? ~ 1985年：Alpha的时代
1985 ~ 1995：DOS的时代
1995 ~ 2005：32位Windows的时代
2005 ~ ?：64位时代
Top
9 楼zyl910（编程的乐趣在于编程控制硬件，与用图形学实现绚丽效果）回复于 2005-02-23 00:08:45 得分 0
搞图像处理搞惯了
Apple随手写成Alpha了
? ~ 1985年：Apple的时代Top
10 楼babyt（阿泰）回复于 2005-02-23 00:11:25 得分 0
Longhorn的架构思想是毋庸置疑的,
但是它的问题出在对系统要求比较高,这个原因可能会导致他的整个推进过程
10年就是1代,,这是潮流,但是从实际应用来说,还能推个3到5年Top
11 楼wxlys（）回复于 2005-02-23 12:36:28 得分 2
好，有用，学习中。Top
12 楼VBDN（ PowerBASIC.CN ）回复于 2005-02-25 17:05:29 得分 2
经典话题!Top
13 楼eglic（圪圪) (理由永远是谎言，信仰永远是自慰）回复于 2005-02-28 18:59:35 得分 2
学无止境啊Top
14 楼quanyi（长生天）回复于 2005-03-01 14:31:09 得分 2
学习啊，学习啊。Top
15 楼unsigned（僵哥(发站内消息，请附上链接或问题说明，否则不予回复)）回复于 2005-03-01 15:02:12 得分 2
markTop
16 楼daisy8675（莫依 沉迷）回复于 2005-03-01 15:13:33 得分 2
有过繁简互换的人都应该用过office.
office2003和officexp转码的方式是不一样的，相当麻烦
zyl去做驱动，周薪都上W，做OA的只能干羡慕。Top
17 楼babyt（阿泰）回复于 2005-03-02 16:09:51 得分 0
zyl收入还没上w吗？ ^_^Top
18 楼crodling（十方）回复于 2005-03-08 13:38:09 得分 0
markTop
