易语言编码转换支持库原理及实现

章鱼C

这篇教程呢.我不知道放哪里好.放到C++区域.又不太谈得上技术性,而且研究的是易语言支持库.放到易语言区域吧.代码大多又是C++的.

好吧.不扯淡了.我这段时间一直在封装模块.底层用C++写成DLL.然后用模块去调用DLL.再在模块中.对DLL命令进行二次封装.简化命令.让新手更容易使用.同时提供多参数版本.这样也不会受到限制

在windows开发中.编码格式的转换.是非常头疼的一件事.不过幸好,我们经常处理的编码格式只有三种.

1.         ASCII

2.         UTF-8

3.         GBK(GB2312)

也就是说.只要会写这三种转码.基本上就没什么问题了.至于URL这些.转换起来并困难

但是我大linux上就不一样了.linux上的转换相当简单.其实windows也提供了类似的函数.只不过封装的没有linux上那么好.

于是.本着写出一个最牛逼.支持编码格式最多模块的想法.我找到了libiconv支持库.一个linux支持库

先看看GNU介绍吧

“GNU是“GNU is Not Unix”的递归缩写。Stallman宣布GNU应当发音为Guh-NOO以避免与new这个单词混淆（注：Gnu在英文中原意为非洲牛羚，发音与new相同）。UNIX是一种广泛使用的商业操作系统的名称。由于GNU将要实现UNIX系统的接口标准，因此GNU计划可以分别开发不同的操作系统部件。GNU计划采用了部分当时已经可自由使用的软件，例如TeX排版系统和X Window视窗系统等。不过GNU计划也开发了大批其他的自由软件。”

这个支持库.在linux上相当好用.ASCII.UTF-8.GBK往往仅仅是3句代码的是

值得庆祝的是.libiconv在04年的时候.居然提供了windows版本.其中包含一个DLL和lib静态库.版本号为1.91(我进行了测试.在11年发布的1.14版本.仍然可以在windows下编译运行!)

于是.我开始动起了libiconv的主意

我下载libiconv支持库.导入VS.然后进行编译.测试.一切都很正常.完全没有问题.不过,在我调试的时候.我需要一些UTF-8的字符.用来测试我的模块是否正常运行.于是,我调用了编码转换支持库.

可是,我越往下翻,我发现.怎么易语言支持的编码格式这么多!???

我再看提示.卧槽!!!

支持库名称及版本：编码转换支持库 （2.0#0版）

    所支持语言：中文(大陆)

    本支持库在转换编码时使用 GNU libiconv 1.9.1版，支持现有绝大多数编码和字符集。

    本库为一般支持库，需要易系统3.7版本的支持，需要系统核心支持库3.7版本的支持，提供了4种命令，提供了116个库定义常量。

    操作系统需求： Windows、Linux

这尼玛…吴涛早在10年就已经把这玩意提取到了易语言上!?

草.好吧,我这些工作都白做了.我本想着做出一款最全面的编码转换模块.可惜被好多年前的吴涛抢先一步.不过没事.这篇教程,就是告诉各位.易语言的编码格式转换支持库原理.

首先.看看吴涛支持库写了什么

一共4个命令

编码转换

编码转换_打开

编码转换_转换

编码转换_关闭

这4个命令先放这里.我们先看看libiconv都提供了什么函数

iconv_ticonv_open (const char* tocode, constchar* fromcode);

size_t iconv (iconv_t cd,              const char* * inbuf, size_t * inbytesleft,              char* * outbuf, size_t * outbytesleft);int iconv_close (iconv_t cd);

        卧槽,吴涛是原封不动的把libiconv的函数给放了出来…

连传参都一样!好吧略有不同

只不过.吴涛似乎更喜欢用易语言的”字符集”传值

好吧.还算不错.至少在原有支持库的情况下.又提供了一层封装

不过这条命令写起来非常麻烦.得这样写

到文本 (编码转换 (到字节集 (“正在安装”), #编码_GBK, #编码_UTF_8, ))

所以.我们自己动手.也来封装一下编码转换支持库

首先.下载libiconv支持库: http://ftp.gnu.org/pub/gnu/libiconv/

导入include.和lib文件

设置延迟加载DLL(如果不这么做.你就非得把DLL放到system32下才行.对我来说,这种行为简直就是逗逼.用一个模块还得把一个不是你写的DLL放到system32下?)

封装代码如下

其中outbuf用了100W的数组.也就是1M的内存大小

这里其实可以取inbuf的大小.然后+1

只不过为了测试简便.先这样写好了

随后.编译DLL.开始写模块.先申明DLL函数

A为要转换的文本

B为转换后的编码

C为转换前的编码

这里我直接用文本型传输.不用字节集.因为不喜欢…

在吴涛写的系统支持库和很多其他支持库中.都喜欢用字符集

这样到字符集到文本的非常麻烦

接下来.就是调用的时候了

第一条命令.从GBK转到UTF-8

第二天命令.则反过来.从UTF-8转GBK

(据我所知.易语言IDE应该是用的GB2312编码!)

然后.调试输出内容如下

OK.这样,我们自制的编码转换模块就完成了

如果吴涛是自己手写的编码转换支持库.那么我这个一定是支持格式最多的了

PS:最后.我不是很会开视频讲.因为会说到一半不知道该说什么.所以我还是用文字教程吧.我最近也在学windows编程.目前还在从内核编程往驱动设计方向学习.我会不定时更新模块.以及放出一些教程.但是我不会做初级教程.因为往往越基础的东西.越难讲.我的教程.更适合易语言进阶者学习!模块进行打包.上传

例程和模块.zip (651.31 KB, 下载次数: 21)

2016-10-20 22:29 上传

点击文件名下载附件

附录一份libiconv目前已经支持的编码格式

European languages

ASCII, ISO-8859-{1,2,3,4,5,7,9,10,13,14,15,16}, KOI8-R, KOI8-U,KOI8-RU, CP{1250,1251,1252,1253,1254,1257}, CP{850,866,1131},Mac{Roman,CentralEurope,Iceland,Croatian,Romania},Mac{Cyrillic,Ukraine,Greek,Turkish}, Macintosh

Semitic languages

ISO-8859-{6,8}, CP{1255,1256}, CP862, Mac{Hebrew,Arabic}

Japanese

EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2,ISO-2022-JP-1

Chinese

EUC-CN, HZ, GBK, CP936, GB18030, EUC-TW, BIG5, CP950,BIG5-HKSCS, BIG5-HKSCS:2004, BIG5-HKSCS:2001, BIG5-HKSCS:1999, ISO-2022-CN,ISO-2022-CN-EXT

Korean

EUC-KR, CP949, ISO-2022-KR, JOHAB

Armenian

ARMSCII-8

Georgian

Georgian-Academy, Georgian-PS

Tajik

KOI8-T

Kazakh

PT154, RK1048

Thai

ISO-8859-11, TIS-620, CP874, MacThai

Laotian

MuleLao-1, CP1133

Vietnamese

VISCII, TCVN, CP1258

Platform specifics

HP-ROMAN8, NEXTSTEP

Full Unicode

UTF-8
UCS-2, UCS-2BE, UCS-2LE
UCS-4, UCS-4BE, UCS-4LE
UTF-16, UTF-16BE, UTF-16LE
UTF-32, UTF-32BE, UTF-32LE
UTF-7
C99, JAVA

Full Unicode, in terms of uint16_t or uint32_t (with machine dependent endianness andalignment)

UCS-2-INTERNAL, UCS-4-INTERNAL

Locale dependent, in terms of `char' or`wchar_t' (with machine dependent endianness and alignment, and with OS and localedependent semantics)

char, wchar_t

smouren

好文章一定要帮顶

wo3320

太棒了，感谢楼主，Mrak一下