编码字符论文（精选4篇）
编码字符论文 篇1
一、ANSI的“Ascii”编码
八位的字节一共可以组合出256 (2的8次方) 种不同的状态。把其中的编号从0开始的32种状态分别规定了特殊的用途, 一但终端、打印机遇上约定好的这些字节被传过来时, 就要做一些约定的动作。遇上0x10, 终端就换行, 遇上0x07, 终端就向人们嘟嘟叫, 例如遇上0x1b, 打印机就打印反白的字, 或者终端就用彩色显示字母, 把这些0x20以下的字节状态称为“控制码”。把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示, 一直编到了第127号, 这样计算机就可以用不同字节来存储英语的文字了, 把这个方案叫做ANSI的“Ascii”编码 (American Standard Code for Information Interchange, 美国信息互换标准代码) 。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
二、扩展字符集
后来, 世界各地的人们都开始使用计算机, 但是很多国家用的不是英文, 他们的字母里有许多是ASCII里没有的, 为了可以在计算机保存他们的文字, 各个国家决定采用127号之后的空位来表示这些新的字母、符号, 还加入了很多画表格时需要用到的横线、竖线、交叉等形状, 一直把序号编到了最后一个状态255。从128到255的字符集被称“扩展字符集”:ISO 8859字符集。下面是ISO 8859现有的15个字符集:
ISO/IEC 8859-1 (Latin-1) -西欧语言
ISO/IEC 8859-2 (Latin-2) -中欧语言
ISO/IEC 8859-3 (Latin-3) -南欧语言
ISO/IEC 8859-4 (Latin-4) -北欧语言
ISO/IEC 8859-5 (Cyrillic) -斯拉夫语言
ISO/IEC 8859-6 (Arabic) -阿拉伯语
ISO/IEC 8859-7 (Greek) -希腊语
ISO/IEC 8859-8 (Hebrew) -希伯来语
ISO/IEC 8859-9 (Latin-5或Turkish) -把Latin-1的冰岛语字母换走, 加入土耳其语字母。
ISO/IEC 8859-10 (Latin-6或Nordic) -北日耳曼语支, 用来代替Latin-4。
ISO/IEC 8859-11 (Thai) -泰语, 从泰国的TIS620标准字集演化而来。
ISO/IEC 8859-13 (Latin-7或Baltic Rim) -波罗的语族
ISO/IEC 8859-14 (Latin-8或Celtic) -凯尔特语族
ISO/IEC 8859-15 (Latin-9) -西欧语言, 加入Latin-1欠缺的芬兰语字母和大写法语重音字母, 以及欧元 (€) 符号。
ISO/IEC 8859-16 (Latin-10) -东南欧语言。主要供罗马尼亚语使用, 并加入欧元符号。
三、汉字字符编码
已经没有可以利用的字节状态来表示汉字, 而且有6000多个常用汉字需要保存。汉字的编码规定把127号之后的奇异符号们直接取消掉, 规定:一个小于127的字符的意义与原来相同, 但两个大于127的字符连在一起时, 就表示一个汉字, 前面的一个字节 (称之为高字节) 从0xA1用到0xF7, 后面一个字节 (低字节) 从0xA1到0xFE, 这样我们就可以组合出大约7000多个简体汉字了。在这些编码里, 还把数学符号、罗马希腊的字母、日文的假名们都编进去了, 连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码, 这就是常说的"全角"字符, 而原来在127号以下的那些就叫"半角"字符了。把这种汉字方案叫做“GB2312”。GB2312是对ASCII的中文扩展。但是中国的汉字太多了, 继续把GB2312没有用到的码位找出来用上。后来还是不够用, 于是干脆不再要求低字节一定是127号之后的编码, 只要第一个字节是大于127就固定表示这是一个汉字的开始, 不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为GBK标准, GBK包括了GB2312的所有内容, 同时又增加了近20000个新的汉字 (包括繁体字) 和符号。再扩展, 又加了几千个新的少数民族的字, GBK扩成了GB18030。这一系列汉字编码的标准通称做“DBCS” (Double Byte Charecter Set双字节字符集) 。在DBCS系列标准里, 最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里, 因此他们写的程序为了支持中文处理, 必须要注意字串里的每一个字节的值, 如果这个值是大于127的, 那么就认为一个双字节字符集里的字符出现了。
四、UTF-16编码
因为当时各个国家都像中国这样搞出一套自己的编码标准, 结果互相之间谁也不懂谁的编码, 谁也不支持别人的编码。ISO (国际标准化组织) 的国际组织决定着手解决这个问题。他们采用的方法很简单:废了所有的地区性编码方案, 重新搞一个包括了地球上所有文化、所有字母和符号的编码“Universal Multiple-Octet Coded Character Set”, 简称UCS, 俗称“UNICODE”, 中文称“通用多八位编码字符集”。
UNICODE开始制订时, 计算机的存储器容量极大地发展了, 空间再也不成为问题了。于是ISO就直接规定必须用两个字节, 也就是16位来统一表示所有的字符, 对于ASCII里的那些“半角”字符, UNICODE保持其原编码不变, 只是将其长度由原来的8位扩展为16位, 而其他文化和语言的字符则全部重新统一编码。由于“半角”英文符号只需要用到低8位, 所以其高8位永远是0, 因此这种方案在保存英文文本时会多浪费一倍的空间。
如前所述, UNICODE是用两个字节来表示为一个字符, 他总共可以组合出65535不同的字符, 这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系, ISO已经准备了UCS-4方案, 说简单了就是四个字节来表示一个字符 (UTF-32) , 这样我们就可以组合出21亿个不同的字符出来!
UNICODE来到时, 一起到来的还有计算机网络的兴起, UNICODE如何在网络上传输也是一个必须考虑的问题, 于是面向传输的众多UTF (UCS Transfer Format) 标准出现了, UTF-16是Unicode最基本的实现。Unicode使用16bit表示一个字符, UTF-16就是直接将字符集的映射搬过来进行传输。
五、UTF-8编码
英文字符, 和ASCII码一样, 占用一个字节。其他语种, 每种语种分配一个模板, 这个模板有16bit, 24bit, 甚至还有32bit的。各个语种根据这个模板, 将自己的语言转化成模板要求的编码 (UTF-8) 。
例如:
中文字:“汉”
中文分到的模板是:1110xxxx 10yyyyyy 10zzzzzz
“汉”字的Unicode编码是:0x6C49, 二进制是 0110 1100 0100 1001
将这个二进制按照模板的x, y, z顺序插入得到:11100110 10110001 10001001
即“汉”字的UTF-8编码为:E6 B1 89
这对中文字符有什么影响吗?原先一个中文使用UTF-16只需要两个字节, 但是使用UTF-8却需要三个字节。
六、字符编码总结
在网络里传递信息时还有一个很重要的问题, 就是对于数据高低位的解读方式 (little-endian binary) 。一些计算机是采用低位先发送的方法, 如我们的PC机所采用的INTEL架构, 而另一些是采用高位先发送的方式, 在网络中交换数据时, 为了核对双方对于高低位的认识是否是一致的, 采用了一种很简便的方法, 就是在文本流的开始时向对方发送一个标志符———如果之后的文本是高位在先, 那就发送"FEFF", 反之, 则发送"FFFE"。
最后是编辑器保存文本时编码的选择与打开文件时编辑器自动编码匹配的问题, 保存文件时, 可以自己选定编码方式, 如:GB2312, UNICODE (UTF-16) , UTF-8, Unicode big endian, ANSI等。
ANSI是什么呢?WINDOWS NT, XP内核是使用UTF-16编写的, 但是页面上展示的语言是根据系统设置的“语言” (开始→控制面板→区域和语言选项→高级) 编码来处理的。ANSI就是windows系统根据你设置的语言环境而进行自动变化的一种编码。比如在中文windows系统下默认ANSI就代表GBK (GB18030简体中文) 编码, 日文操作系统下就代表JIS编码。
在编程及数据库系统中UNICODE的问题, 在数据库里, 有N前缀的字串类型就是UNICODE类型, 这种类型中, 固定用两个字节来表示一个字符, 无论这个字符是汉字还是英文字母, 或是别的什么。如果你要测试“abc汉字”这个串的长度, 在没有N前缀的数据类型里, 这个字串是7个字符的长度, 因为一个汉字相当于两个字符, 而在有N前缀的数据类型里即表示为 (N”abc汉字”) , 同样的测试串长度的函数将会告诉你是5个字符, 因为一个汉字就是一个字符。
摘要：本文对计算机中字符与编码的各种方法, 编码方案的发展, 相关概念进行了分析总结。
关键词：Ascii,扩展字符集,汉字字符编码,UNICODE
参考文献
[1]http://zh.wikipedia.org/wiki/字符编码
[2]RFC3629:UTF-8, a transformation format of ISO10646
[3]http://www.joelonsoftware.com/articles/Unicode.html
编码字符论文 篇2
1.基本ASCII码
用7位二进制数来给字符编码。7位二进制数共有27=128种不同组合，每一种组合可代表一种字符，即作为一种字符的编码。例如：
0110000(48)字符*0;1000001(65)字符A;
011000l(49)字符1;1000010(66)字符B;
0110010(50)：字符2。
2.扩充ASCII码
用8位二进制数来给字符编码。即在基本ASCII码前面增加一个二进制位，共28=256种组合，可给256种字符编码。前128种，最高位为0，仍用于表示基本ASCIlI字符。如01000001(65)仍表示字符A。后128种，最高位为1，用于表示128种特殊符号，如制表符└、┘、├、┬等。
3.汉字编码
汉字编码涉及类型较多，这里仅介绍其中几种。
(1)国标码
国标码的全称是国家标准化信息用汉字编码。国标汉字共6763个，
分为两级，一级汉字为常用汉字，共3755个;二级汉字为非常用汉字，共3008个。每个汉字对应4位十六进制数。如大的国标码为3473(16)，写成二进制为0011010001110011。
(2)输入码
输入码是指将汉字输入到计算机中所用的编码，有几十种之多，且还在不断研究新的输入编码。目前常用的有十几种，如汉语拼音、五笔字型、自然码、区位码等。中文Windows环境下的智能ABC输入法属拼音输入法，初学者使用起来很方便。区位码又称国标区位码，是国标码的一种变型。它将国标汉字分成94个区，每个区又分成94个位置，区码、位码分别用两位十进制数表示，在计算机内部用这两位十进制数的BCD码表示。如大在20区、83位，其区位码为2083，在机内表示为0010000010000011。
(3)汉字内码
汉字内码是计算机系统内部处理、存储汉字所使用的统一代码。内码可由国标码变换而来，即将国标码的每个字节的最高位置1，其他位均不变，即可得到内码。例如，已知大的国标码为3473(16)，写成二进制为0011010001110011，则大的内码为10110100llll00ll，写成十六进制为B4F3。
(4)字型点阵码
Java字符集编码应用探讨 篇3
1 字符集与编码
字符就是具有一定意义的符号,如文字、数字、标点符号、图形符号、技术符号等。字符集是字符的集合,一种字符集一般对应着一种语言所使用的文字和符号。编码是指用一个整数值来代表一个字符,使得字符可以被计算机处理。不同的字符集采用的编码规则和编码空间是不一样的。字符集编码的源头是ASCII码,一种7位编码的英语字符集。随后的发展经历了两个阶段,第一个阶段是本地化编码,不同的国家和地区在ASCII编码的基础上,制定了自己的编码标准,如GB2312、JIS、BIG5、ISCII等,这些编码互相独立、互不兼容,无法同时使用。第二个阶段是Unicode编码,即将世界上所有国家和地区的字符和符号统一编码在一个大字符集里,完全解决字符编码问题。
(1)Unicode编码。编码空间结构上被分为17组,组称作平面,每个平面能编码65536个字符,目前只是用了少数平面,其中0号平面(U+0000-U+FFFF),即基本多文种平面是最主要的平面,包含了世界上大部分常用的字符。UNI-CODE编码在实现时,受使用平台的限制,以及节约空间的考虑,字符实际上是以UTF-8、UTF-16、UTF-32这些Unicode转换格式编码。
(2)GB2312、GBK、GB18030编码。这3种编码是汉字的国家标准编码,属于本地化编码,与Unicode不兼容。其中GBK是国家强制标准。
下面从基本编码、编码探测、IO编码、HTTP编码4个方面探讨在Java语言中怎样解决编码问题。
2 基本编码
Java语言原生支持Unicode,JVM中字符串以UTF-16编码存放,Class文件中字符串以修改过的UTF-8编码保存,最新的JDK7支持Unicode 6.0。JDK中字符集编码处理的包是java.nio.charset,只有5个类(类图如下),采用了编解码的概念,Java字符串(UTF-16编码)转换为其他字符集称作编码,其他字符集转化为Java字符串称作解码。另有java.nio.charset.spi包用于扩展。主要的操作如下:
(1)列出当前JVM支持的全部字符集
public static Sorted Map
(2)字符串编解码
//将GBK编码字节流解码成Java字符串
//将Java字符串编码成GBK字节流
3 编码探测
编码探测是指通过分析文本的特征,判断其采用了何种字符集编码。
(1)基于BOM信息的探测。BOM是byte order mark(字节顺序标记)的缩写,指置于一段Unicode文本首部的若干标志字节,用于说明文本的字节顺序和编码类型。具体如表1所示。
需要注意U+FEFF在早期Unicode标准中被编码为Zero Width No-Break Space(ZWNBSP),从Unicode 3.2起已被废止,专门用于BOM,原有的功能被U+2060?Word Joiner代替。EF BB BF实际是FE FF的UTF-8编码。可以用一个简单的函数判断文本是否有BOM头部。
(2)自动编码探测。常用的Java自动编码探测包有cp Detector、juniversalchardet和ICU等。下面以ICU-Character Set Detection举例。
4 IO编码
Java IO操作基于流(Stream)和通道(Channel)两种模式。流模式中数据被看做流动的字节流或字符流,流本身被看做是与某一具体数据源或目的相关联的设备,可以操作它读出或写入数据流。通道模式引入Buffer类用于管理数据,通道本身则看做一个与远端设备相连的端到端的连接。流和通道处理字符编码的方式不同,具体见例子。
(1)以UTF-8编码读入文件
(2)将数据以UTF-8编码保存
5 HTTP编码
一般认为HTTP字符集编码指的是传输的文本内容的编码,但实际上HTTP编码涉及URL编码、头部编码和内容编码3部分,下面分别论述。
(1)URL编码是指当用户在页面中发起URL请求或在地址栏中输入URL时,浏览器在将该URL发往服务器前,会对其进行编码。首先浏览器会选择一个字符集将URL编码成字节流,随后对该字节流进行%编码,将URL转换成ASCII编码的一个限定子集进行发送。由于字符集选定和%编码的规则没有统一的标准,而是交给浏览器自行决定,从而导致了混乱。下面是使用Wireshark捕获的IE9、Chrome和Firefox页面请求编码,如表2所示。
解决的办法是直接使用Javascript对URL进行编码,发送到服务器,跳过浏览器的编码过程。具体的函数是encode URI()、decode URI()和encode URIComponent()、decode URIComponent()等。Jquery通过封装这几个函数,提供了简便的解决办法,见下例:
var params={"param":"测试"};
$("#id").load("http://abc.com/test/测试",params);
服务器端的解码先用Servlet API中的Http Servlet Request.get Request URL()取出未解码过的URL,Http Servlet Request.get Query String()取出未解码过的请求字符串。然后使用UR-LEncoder和URLDecoder类对URL进行编解码,转换规则如下:
(1)字母数字字符"a"到"z"、"A"到"Z"和"0"到"9"保持不变。
(2)特殊字符"."、"-"、"*"和"_"保持不变。
(3)加号"+"转换为空格字符""。
(4)将把"%xy"格式序列视为一个字节,其中xy为8位的两位十六进制表示形式。然后,所有连续包含一个或多个这些字节序列的子字符串,将被其编码可生成这些连续字节的字符所代替。可以指定对这些字符进行解码的编码机制,如果未指定的话,则使用平台的默认编码机制。
另外,在Tomcat中可以通过在Server.xml中设置
(2)头部编码。早期HTTP规范要求头部字符也必须是ASCII编码,后来随着Content-Disposition的出现,下载文件时需要在头部采用多语言编码。RFC 5987、RFC6266规定HTTP头部多语言编码采用parameter*=charset'lang'value的格式,但是目前只有最新的浏览器支持(Safari>=6,IE>=9Chrome,Firefox,Opera)支持,老版本的浏览器不支持,而且不同浏览器的解码规则也不同,要想完美解决,需要在服务器端做浏览器探测,并根据猜测到的不同浏览器进行响应编码。
(3)内容编码。HTTP使用Content-Type头部标识实体内容的MIME类型,同时支持可选的参数进一步说明文本内容的编码。Servlet中用set Content Type()和response.set Character Encoding()用于设置返回内容的字符集编码。Request set Character Encoding用于设置解码请求实体中文本内容的编码。如下例:
需要注意,set Content Type()优先级比set Character Encoding()要高。
参考文献
[1](美)昊斯特曼.JAVA核心技术卷II:高级特性(原书第8版).叶乃文,邝劲筠,杜永萍,译.机械工业出版社,2008.
[2]成富.深入理解Java7:核心技术与最佳实践.机械工业出版社,2012.
编码字符论文 篇4
关键词：云南规范彝文,形码编码,输入法,字库
经过20多年的发展,我国已经在少数民族语言文字信息交换和处理领域取得了快速发展,其中藏、蒙、维、彝、朝5种民族文字领域更是硕果累累,不仅正式进入国际标准化组织(ISO)统一编码的国际标准,而且在输入法实现方面技术基本成熟。这对于少数民族语言文字信息的保护有着重要的现实意义。
实现一个完整的输入法,最重要的是文字字库的设计和制作,而核心内容便是字符集编码方案的选择和设计。这两项是决定一个输入法性能优良与否的关键。本文以云南规范彝文为研究对象,完成了云南规范彝文字库的设计和制作,并设计一套切实可行的规范彝文字符集的编码方案。
1 云南规范彝文字库的设计
字库是外文字体、中文字体以及相关字符的电子文字字体集合库,被广泛用于计算机、互联网及相关电子产品上。字库的设计是一件复杂庞大的工程,一套完整的字库在面市前要经过多个流程才能完成,其中涉及到诸多知识点,例如字稿的选择、扫描、数字化拟合,以及对字库的修改和整合[1]。
1.1 字库设计及数字化拟合字库
本文使用的是目前比较流行的数字化字形描述技术——TrueType,其中Font Creator Program软件设计并制作有3 751个彝文字的云南规范彝文字库。通过Font Creator Program实现修改字体、写入字体版权信息、控制字体属性等。
前期对手稿的处理十分关键,字库的正确性、美观与否都取决于对手稿的数字化,可以选择扫描的方式将手稿数字化。将手稿图像导入Font Creator Program中,如图1所示。
数字化拟合是利用专门程序按照一定的数学算法,自动将扫描后的点阵图像拟合成尽可能接近原告的数字化信息,即二次B样条曲线及直线。数字化拟合是很重要的一步,如果拟合准确,可以大幅提高修改字体的工作效率。
在导入字模图像的同时要对相应的参数进行设定。需要注意的是,导入的字模图像不能过大,应尽量低于100 kB。因为较大的图片会导致载入字模图片时间延长,降低效率。根据云南规范彝文字形的特征,经过计算在以200×200范围的点阵字模,比较适合彝文字模图像[2],如图2所示。
1.2 修改云南规范彝文字体
虽然计算机拟合效率较高,但数字化拟合只是完成了最初步的工作,若要提高字体质量,使制作的字库中的字体美观实用,还要靠人工修改才能完成。首先修字的工作量非常大,云南规范彝文字库共有3 751个彝文字。修字主要是通过编辑节点对字形进行编辑,保证每一个笔画要用最少的点描述,以尽可能地减少存储信息,提高还原速度。同时不仅要将字体控制在200×200的范围内,还要兼顾云南规范彝文的字形特征,尽量使其美观。
1.3 整合云南规范彝文字库
当编译完全部字符后需要对字体进行验证,可以得到验证报告,如图3所示,然后根据验证报告上的信息对有问题的字符进行相应调整。最后便可得到美观实用的云南规范彝文字库,现截取部分字库文件图片,如图4所示。
2 云南规范彝文字符集编码的设计
2.1 编码标准
我国现已颁布并实施的国际、国家标准有[3]:
(1)《信息交换用彝文编码字符集》(G86032),该标准根据1980年国务院颁布实施的规范彝文制定,共计1 165个彝文字符,主要起草人:沙玛拉毅。
(2)《信息交换用彝文15×16点阵字模集及数据集》,1992年该项标准由国家标准出版社出版、国家技术监督局颁布实施,主要起草人:沙玛拉毅。
(3)《信息交换用彝文24×24点阵字模及数据集》,该项标准于1997年由国家技术监督局发布,主要起草人:沙玛拉毅。
2.2 云南规范彝文编码设计思路
字库的编码是字库组织的依据,是文字处理的基础。现有彝文字库的编码多是采用国际音标形式对彝文字进行编码,但使用该方法进行编码有很大的局限性,即采用这种编码设计方案的输入法所面向的使用对象是熟悉彝文并掌握彝文字标准发音的群体。这也就阻碍了这种编码方式的使用和推广。基于上述原因,本文采用了形码的编码方式,无论是否熟知彝文字,亦或是第一次使用彝文字的用户都可以输出彝文字。
2.3 云南规范彝文字符集外码编码的实现
从信息论的角度对于信源进行编码,可以选择定长编码或者变长编码,虽然变长编码可以提高编码效率,在节省了时间的同时却牺牲了存储空间,存储这些变长码需要大量缓冲设备,如果出现了误码,容易引起错误扩散;定长编码在冗余度压缩编码中比变长编码占有一定优势,而且本文采用的全数字定长编码不仅容易发现手动输入错误,在键盘键入过程中也有利于提高输入效率。
彝文字的符号体系与汉字有明显的区别,尽管文字的使用频率和规范程度远不及汉文,但从彝文字结构本身来说自有其特色。首先,彝文字强调笔画简单,一般3～4画的居多;其次,彝文字的书写程序是强调从上至下、从左至右平向流线型的,文字整体符合书写规律;最后,彝文字的书写强调笔画的流畅,弧线的圆润和优美。因为彝文字具有以上特点,本文采用了一种基于笔画的编码方案。对待处理的文字,进行了外码的编辑。
2.3.1 对彝文字进行拆分
与汉字相似,首先确定该彝文字的结构,一般可分为上下结构、左右结构、包围结构。确定结构类型的标准主要是使拆分后的两部分结构占字面积相似,或是重心平衡。然后确定主要部首,规则是从左到右、从上到下、从外到内。如图5所示。
2.3.2 确定主要部首的组成笔画数
具体方法是将所有的彝文字都看作是直线与弧线组成的集合,每一个独立的直线和圆滑曲线算作为一笔,其他的折线都要拆分成独立的直线跟圆滑曲线来计算笔画数,直线上的交叉点不作为拆分点进行拆分。如图5中的彝文字的主要部首由两条圆滑曲线组成,即为两笔。笔画数则为2。
2.3.3 确定封闭区间的个数
封闭区间可以是由直线、圆滑曲线、折线所构成的独立区间,计算封闭区间个数时,以独立的最小封闭区间为准,即各个封闭区间的关系为相互独立,不存在包含于、相交于的关系。例如,图5所示的彝文字的独立最小封闭区间数为4。
图6中的彝文字为左右结构,其中主要部首由一条圆滑曲线构成,即为1笔,部首的笔画数则为1,封闭区间只有1个,则部首的独立最小封闭区间数为1;剩余部分由3条独立直线构成,即为3笔,画数则为3,没有封闭区间,独立最小封闭区间数则为0。
但整个彝文字体的封闭区间应按最小独立的封闭区间算,右边的剩余部分将左边的部首中的封闭区间划分为了3个小的独立的封闭区间,并和它产生了一个封闭区间,这样该彝文字一共有4个最小封闭区间。
2.3.4 确定结点个数
结点个数即为整个彝文字体中的交叉点的个数,如图4中的彝文字的结点个数为2,图5中的彝文字的结点个数为6。若结点个数为多为两位整数,如18个结点个数,则取这个两位数的个位进行编码,即外码编码即为8。
2.3.5 外码的编码原则
本文设计彝文字的外码由5个码组成,第1位码为主要部首的笔画数,第2位码是主要部首的独立的最小封闭区间的个数,第3位码是除主要部首以外剩余笔画数,第4位是整个彝文字的独立的最小封闭区间的个数,第5位是整个彝文字的结点个数。具体编码如图7,图8所示。
2.4 云南规范彝文字符集码表的制作
考虑到规范彝文字符编码时所占编码区域的大小,以及云南规范彝文输入系统与中英文输入系统、其它彝文输入系统的兼容性,本文采用了国际上的主流Unicode编码技术,它是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。其中E000～F8FF为自行使用区域(Private Use Zone),可存放6 400个字符,本文的云南规范彝文字符可全部存放在该用户自定义编码区域。制作生成的Unicode码表文件如图9所示。
2.5 输入法的实现
本文采用一种Windows系统实现文字输入功能的标准方法Windows IME API 即“IMM-IME”输入法生成器来实现云南规范彝文的输入,因为该IMM-IME结构在Win32平台下所提供的输入环境不仅系统稳定性较高,而且是一种方便、规范的方式[5]。
云南规范彝文输入法安装成功后,在Windows中的Microsoft Word 2003中,输入了传统彝文叙事歌《阿诗玛》的最后一句“说的说来听得听”,并且可与中文兼容共同显示,效果如图10所示。
3 性能分析
国家标准对键盘输入系统的性能评价主要有两个层次,一个是编码层次,一个是软件层次。在编码层次上要求达到定性指标,如易学性;在软件层次上要求达到量化指标,如输入的平均码长和重码键选率。因此易学性、平均码长和重码字键选率是衡量一种输入法性能的3个重要指标[4]。
3.1 易学性
本文所设计的云南规范彝文输入法不仅是针对彝文学者的输入法,而是面向所有有彝文输入要求的使用者,即便是不懂彝文的使用者也可以通过简单的学习使用该输入法完成彝文输入。
3.2 彝文输入的平均码长
输入平均码长是指再输入给定的测试样本时,测得的输入每个彝文字的平均击键次数[6]
平均码长
以云南规范彝文字库中随机抽取的1 000个彝文字为输入测试样本,由于本文中使用的为定长编码,其中测试样本击键次数分布如表1所示。
根据式(1)计算
平均码长
3.3 彝文输入的平均码长
重码字键选率是指在输入给定测试样本过程中,通过重码选择确认的彝文字数与测试样本总字数的百分比[6]
重码字键选率
在输入测试样本时,重码选择确认的彝文字数与测试样本字数分布如表2所示。
根据式(2)计算
重码字键选率
4 结束语
彝文是一种原生的古老文字,它在古老方面与汉文难分伯仲,却不是借用和摹仿汉字的产物。彝文产生于新石器时代到铁器时代之间,它也和其他民族的古老文字一样经历了一个漫长的发展过程和文字发展的必经阶段,彝文发展到今天已有4 000多年的历史。但是,由于彝文所使用的书写材料的易腐蚀性,加之南方潮湿闷热的气候等,都给彝文文献的保存造成了困难。因此在彝文历史文化研究中,需要收集、整理、保存的彝文文献,迫切需要解决的就是彝文字信息化问题。本文设计和制作的云南规范彝文字库及设计的规范彝文字符集的编码方案,为彝文的信息处理另辟蹊径。
参考文献
[1]吕强,史磊,杨季文.TrueType字体文件格式初探[J].计算机研究与发展,1995,32(11):23-31.
[2]陈顺强,张阳,熊剑.四川古彝文字库设计及其字符集的编码[J].西南民族大学学报:自然科学版,2009,35(4):913-918.
[3]沙马拉毅.计算机彝文信息处理[M].成都:四川民族出版社,2000.
[4]沙马拉毅,钱玉趾.规范彝文编码方案[J].中文信息,1990(3):12-13.
[5]胡宇晓,马少平,夏莹.基于MM-ME输入法接口的实现方法[J].计算机工程与应用,2002,38(1):117-120.