当前位置:Linux教程 - Linux - Linux,内核汉化大揭秘

Linux,内核汉化大揭秘

在阐述“基于Linux核心的汉字显示”的技术细节之前,有必要介绍一下原有Linux的工作机制。这里主要涉及到两部分的知识,这是Linux下终端和帧缓冲的实现。






控制台(console)


通常我们在Linux下看到的控制台(console)是由几个设备构成的。分别是/dev/ttyN(其中tty0就是/dev/console,tty1、tty2就是不同的虚拟终端(virtual console))。通常使用热键Alt+Fn来在这些虚拟终端之间进行切换。这些tty设备对应于linux/drivers/char/console.c和lvt.c。其中console.c负责绘制屏幕上的字符,vt.c负责管理不同的虚拟终端,并且负责提供console.c需要绘制的内容。Vt.c把不同虚拟终端下的需要交给console.c绘制的内容,放到不同的缓存中去。Vt.c管理者这样一个缓冲区的数组,并且负责在这些缓存之间切换,并指定哪一个缓冲区是被激活的。你所看到的虚拟终端就对应着被激活的缓冲区。Console.c同时也负责接收终端的输入,然后把接收到的输入的信息放到缓冲区。






帧缓冲(framebuffer)


Framebuffer是把显存抽象后的一个种设备,可以通过这个设备的读写直接对显存进行操作。这种操作是抽象的、统一的。用户不必关心物理显存的位置、换页机制等等具体细节,这些都是由Framebuffer设备驱动程序来完成的。


Framebuffer对应的源文件在linux/drivers/video/目录下。总的抽象设备文作为fbcon.c,在这个目录下还有与各种显卡驱动程序相关的源文件。


在使用帧缓冲时,Linux是将显卡置于图形模式下的。


我们以一个简单的例子来说明字符显示的过程。我们假设是在虚拟终端1(/dev/tty1)下迁行如下的简单程序:


main ()


{


puts(”hello,world.

”);


}


pputs函数向缺省输出文件(/dev/tty)发出“写”的系统调用write(2)。系统调用到Linux核心对应的核心函数->——console.c中的con_write( ), con_write( )最终会调用do_con_write(),在do_con_write()中负责把”hello,world.

”这个字符串放到tty1对应的缓冲区中去。


Do_con_write()还负责处理控制字符和光标的位置。让我们来看一下do_con-write()这个函数的声明:


Static int do_con_write(struct


Tty_struct * tty, int


from_user, const unsigned


char *buf, int count )


其中tty是指向tty_struct结构的指针,这个结构里存放着关于这个tty的所有信息(请参照linux/include/linux/tty.h)。tty_srtuct结构中定义了?p> 用(或高层)tty的属性(例如宽度和高度等)。


在do_con_write()函数中用到了tty_struct结构中的driver_data变量。Driver_data是一个vt_vt_stuct指针。在vt_struct结构中包含这个tty的序列号(我们正使用tty1,所以这个序号为1)。Vt_struct结构中有一个vc结构的数组vc_cons,这个数组就是各虚拟终端的私有数据。


Static int do_write(struct


Tty_struct * tty, int


From_user,const unsigned char


*buf, int conut)


{


struct vt_struct *vt = (struct


vt_struct *)tty_>driver_data;


//我们用到了driver_data变量


…………


currcons = vt->_num;


//在这里的vc_nums就是1


…………


}


要访问虚拟终端的私有数据,需使用vc_cons[currcons].d指针。这个指针指向的结构含有当前虚拟终端上光标的位置,缓冲区的起始地址、缓冲区大小等信息。


“hello,world.

”中的每一个字符都要经过conv_uni_to_pc()这个函数转换成8位的显示字符。这样做的主要目的是使不同语言的国家能把16位的Unicode码映射到8位的显示字符集里,目前主要还是针对欧洲国家的语言,映射结果为8位,不包含双字节(double byte)的范围。


这种从Unicode到显示字符的映射表上,会把中文的字符映射到其他的字符上,这是我们不希望看到也是不需要的,所以我们有两种选择:


1) 不进行conv_uni_to_pc()的转换


2) 加载符合双字节处理的映射关系,即对蜚 控制字符进行一对一的不变映射,我们自己定制的符合这种映射关系的Unicode码表是direct.uni。


要想看/装载当前系统的Unicode映射表,可使用外部命令loadunimap。


经过conv_uni_to_pc()转换之后,”hello, world.

”中的字符被一个一个地填写到tty的缓冲区中,然后do_con_write()调用底层的驱动程序,把缓冲区中的内容输出到显示器上(也就相当于把缓冲区的内容拷贝到VGA显存中去)


sw->con putcs(vc_cons[currcons].d,


(u16 *)draw_from, (u16 *)draw_to_


(u16 *)draw_rwom, Y, draw_x);


之所以要调用底层驱动程序,是因为存在不同的显示设备,其对应VGA显存的存取方式也不一样。


上面的Sw->con_putcs()就会调用fbcon.c中的fbcon_putcs()函数(con_putcs是一个函数的指针,在 Framebuffer模式)下指向fbcon_putcs()函数,也就是说,在do_con_write()函数中是直接调用了fbcon_putcs()函数来进行字符的绘制,比如说在256色模式下,真正负责输出的函数是:void fbcon_cfb8_putcs(struct vc_d

ta *conp,struct display *p, const unsignde short *s, int count, int YY, int xx )


显示中文


比如说我们试输出一句中文:putcs(你好

”)(“你好”的内码为0xc4.0xe3.0ba.0xc3)。这时候会怎么样呢?有一点可以肯定,“你好”肯定不会出现在屏幕上,原因是:


1、核心中没有汉字字库,中文显示就是无米之炊了。


2、在负责字符显示的void fbcon_cfb8_putcs()函数中,原有操作如下:


对于每个要显示的字符,依次从虚拟终端缓冲区中以WORD为单位读取(低位字节是ASCII码,高8位是字符的属性)。由于汉字是双字节编码方式,所以这种操作是不可能显示出汉字的,只能显示出xxxx_putcs()输出的是一个一个的VGA字符。


因此,要解决的问题:确保在调用do_con_write()时进行uni_pc转换不会改变原有编码,一个很直接的实现方式就是加载一个我们自己定制的Unicode映射表,loadunimap dirdct.uni,或者进接把direct.uni设置为核心的缺省映射表。


针对以上问题,我们要做的第一个尝试方案如下:


首先需要在核心中加载汉字字库,然后修改fbcon_cfb8_putcs()函数,在fbcon_cfb8_putcs()中一次读两个WORD,检查这两个WORD的低位字节是否能拼成一个汉字,如果发现能拼成一个汉字,就算出这个汉字在汉字字库的的偏移,然后把它当成个16×16的VGA字符来显示。


试验的结果表明:


1、能够输出汉字,但仍有许多不理想的地方,比如说,输出以半个汉字开始的一串汉字,则这半个汉字后面的汉字都会是乱码,这是“半个汉字”的问题。


2、光标移动会破坏汉字的显示,表现为,光标移动过的汉字会变成乱码,这是因为光标的更新是通过xxxx_putc()函数来完成的。


xxxx_putc()函数与xxxx_putcs()函数实现的功能够类似,但是xxxx_()函数只刷新一个字符而不是一个字符串,因而xxxx_putc()的输入参数是一个整数,而不是一个字符串的地址,xxxx_putc()函数的声明如下:


void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int YY, int xx)


下一个尝试方案就是同时修改xxxx_putc()函数和xxxx_putc()函数为了解决半个汉字的问题,每一次输出之前,都从屏幕当前行的起始位置开始打措,以确定要输出的字符是否落在半个汉字的位置上,如果是在半个汉字的位置上,如果是在半个汉字的位置,则进行相应的调整,即从向前移动一个字节的位置开始输出。


这个方案有一个困难,即xxxx_putc()函数不用缓冲区的地址,而是用一个整数作为参数,所以xxx

_putc()无法直接利用相邻的字符来判别该字符是否是汉字。


解决方案是,利用xxxx_putc()的光标们置参数(yy,xx),可以逆推出该字符在缓冲区中的位置,但仍一些小麻烦,在Linux的虚拟终端下,用户可能会上卷该屏幕(Shift+Pageup),导致光标的y座标和相应字符在缓冲区的行数不一致,相应的解决方案是,在逆推的过程中,考虑在屏的参量。


这样一来,我们就又进了一步,得到了一个相对更好的版本。但仍有问题没有解决,敲入turbonetcfg,会发现菜单的边框字符也被当成汉字显示,这是因为,这种边框字符是扩展字符,也使用了字符的低8位,因而被当成汉字显示,这是因为,这种边框字符是扩展字符,也使用了字符的低8位,因而被当作汉字来赤示。例如,单线“—”的制表符内码为0xC4,当连成一条长线时就是由一连串0xC4组成的,而0Xc4c4正是汉字“哪”,于是水平的制表符被一连串的“哪”字替代了,因为制表符的种类比较多,而且垂直制表符与其后面字符的组合形式又多种多样,因而很难判断出相应位置的字符是不是制表符,从理论上说,无论采取什么样的排除算法,都必然存在误判的情况,因为总存在二义性,没有充足的条件来推断出当前字符究竟是制表符还是汉字。


我们一方面寻找更好的排除组合算法,一方面试图寻找其他的解决方案,要想从根本上解决这个问题,必须利用其他的辅助信息,仅仅利用缓冲区的字符来判断是不够的。


经过一番努力,我们发现,在UNIX中使用扩展字符时,都要先输出字符转义序列(Escape sepuence)来切换当前字符集。字符转义序列是以控制字符Ecs为首的控制命令,在UNIX的虚拟终端中完成终端控制命令,这种命令包括移动光标座标、卷屏、删除、切换字符集等等。也就是说,在输出代表制表的字符串之前,通常是要先输出特定的字符转义序列,在console.c里,有根据字符转义序列命令来记录字符状态的变量,结合该变量提供的信息,就可以非常准确地把制表符与汉字区别开来。


在如上思路的指引下,我们又产生了新的解决方案,经过改动得到了另一版本。


在这个新的版本上,turbonetcfg在初次绘制的时候,制表符与汉字被清晰地区分开,但还有问题:turbonetcfg在重绘的时候(如切换虚拟终端或是移动鼠标光标的),制表符还是变成了汉字,因为重绘完全领带于缓冲区,而这时用来记录字符集状态的变量并不反映当前字符集状态。问题还是没有最终解决,我们又回到了起点。


看来问题的最终解决手段必须是把字符集的状态伴随着每一个字符在

撼迩校梦颐抢囱芯恳幌禄撼迩慕峁埂?


每一个字符占用16位的缓冲区,低6、8位是ASCII值,完全被利用,高8位饮食前量颜色和背景颜色的属性,也没有多余的空间可以利用,因而只能另外开辟新的缓冲区。为了保持一致性,我们决定在原来的缓冲区后面添加相同大小的缓冲区,用来存放是否汉字的信息。


也许有读者会问,只需要为每个字符添加一位信息来标志是否是汉字就足够了,为什么还要开辟与原缓冲区大小相同的双倍缓冲区,这是不是太浪费呢?


我们先放下这个问题,稍后再作回答。


其实,如果再添加一位来标志当前字符是汉字的左半边还是历半边的话,就会省去扫描屏幕上当前整行字符串的工作,这样一来,编程会更简单,但是有读者会问,即使是这样,使用8位总够用了吧?为什么还要使用16位呢?


我们的做法是:用低8位来存放汉字另外一半的内码,用高8位中的2位来存放上面所讲的辅助信息,高8位的剩余6位可以用来存放汉字或其他编码方式(如BIG5或日文、韩文)的信息,从而使我们可以实现同屏显示多种双字节语言的字符而不会相互干扰。另外,在编程时,双倍缓冲也比较容易计算。这样我们就回答了如上的两个问题。


迄今为止,我们有了一套彻底解决汉字和制表符相互干扰,半个汉字的刷新、重绘等问题的方案。剩下的就是具体编程来实现的问题了。


但是,由于Framebuffer的驱动程序很多,修改每一个驱动程序的xxxx_putc()函数和xxxx_putcs()函数会是一项不小的工作,而且,改动驱动程序后,每种驱动程序的测试也是很麻烦的,尤其是对于有硬件加速的显卡,修改和测试会更不容易。


那么,是否存在一种不需要修改显卡驱动程序的方法呢?经过一番努力,我们发现,可以调用xxxx_putcs()或xxxx_putc()函数输出汉字之前,修改VGA字库指针使其指向所需显示的汉字在汉字字库中的位置,即把一个汉字当成两个VGA ASCII字符输出。也就是说,在内核中存在两个字库,一个是原有的VGA字符字库,另一个是汉字字库,当我们需要输出汉字的时候,就把VGA字库的指针指向汉字字库的相应位置,汉字输出完之后,再把该指针指向VGA字库的原有位置。


这样一来,我们就只需要修改fbcon..c和console.c,其中console.c负责维护双倍缓冲区,把每一个字符的信息存入附加的缓冲区中;而fbcon.c负责利用双倍缓冲区中的附加的信息,调理 VGA字库的指针,调用底层的显示驱动程序。


这里还有几个需要注意的地方:


1、由于屏幕重绘等原因,调用底层xxxx_putc()和xxxx_putc

()的地方有多处,我们做了两个函数分别馐这两上调用,完成替换字库、调用xxxx_putcs()或xxxx_putc()、恢复字库等功能。


2、为了实现向上滚屏时也能看到汉字,我们需要作另外的修改。Linux在设计虚拟终端的时候,提供了回顾被滚出屏幕以外的信息的功能,这就是用热键来向上滚屏(Shift+Pageup)。当前被使用的虎虚拟终端的时候,公共缓冲区的内容会被清除而被新的虚拟终端使用,向上滚屏的时候,显示的是公共缓冲区中的内容。因此,如果我们想在向上滚屏的时候看到汉字,则公共缓冲区也必须加倍,以确保没有信息丢失。当滚出屏幕的住处向公共缓冲区填写的时候,必须把盯应的附加信息也填写进公共缓冲区的附加区域中,这就要求fbcon.c必须懂得利用公共缓冲区的附加信息。当然,另外有一处偷懒的方法,那就是不允许用户向上滚屏,从而避免对公区缓冲区的处理。


3、把不同的编码方式(GB、BIG5、日文和韩文)写成不同的模块,以实现动态加载,从而使得扩展新的编码方式不需要重新编译核心。


小结


通过这次针对inux核心的探索,我们发现,目前Linux的核心设计中,完全没有考虑到双字节编码字符的显示,我们在这种情况下摸索出一套解决核心汉字显示的方法,并编码实现了该方案。遵循核心的GPL版权声明,我们同时公布了实现这一技术的源代码,当然,这些改动仍然是GPL的。如果能对研究核心的朋友有所帮助,养活一些大家对核心的神秘感,将是我们最大的收获。


但是对核心和中文化来说,这仅仅是一种尝试,远不是终点。这种改动多少带有一些黑客的色彩,不太可能融合进权威的核心里去。我们仍在积极探索圆满解决这一问题的方法,当然这一目标必然需要通过国内外Linux群体的共同努力才能实现。我们也非常欢迎大家和我们共同讨论这一问题






来源:Linux技术支持网站







——基于Linux核心的汉字显示




利启 孙喜明






在阐述“基于Linux核心的汉字显示”的技术细节之前,有必要介绍一下原有Linux的工作机制。这里主要涉及到两部分的知识,这是Linux下终端和帧缓冲的实现。






控制台(console)


通常我们在Linux下看到的控制台(console)是由几个设备构成的。分别是/dev/ttyN(其中tty0就是/dev/console,tty1、tty2就是不同的虚拟终端(virtual console))。通常使用热键Alt+Fn来在这些虚拟终端之间进行切换。这些tty设备对应于linux/drivers/char/console.c和lvt.c。其中console.c负责绘制屏幕上的字符,vt.c负责管理不同的虚拟终端,并且负责提供console.c需要绘制的内容。Vt.c把不同虚拟终端下的需要交给console.c绘制的内容,放到不同的缓存中去。Vt.c管理者这样一个缓冲区的数组,并且负责在这些缓存之间切换,并指定哪一个缓冲区是被激活的。你所看到的虚拟终端就对应着被激活的缓冲区。Console.c同时也负责接收终端的输入,然后把接收到的输入的信息放到缓冲区。






帧缓冲(framebuffer)


Framebuffer是把显存抽象后的一个种设备,可以通过这个设备的读写直接对显存进行操作。这种操作是抽象的、统一的。用户不必关心物理显存的位置、换页机制等等具体细节,这些都是由Framebuffer设备驱动程序来完成的。


Framebuffer对应的源文件在linux/drivers/video/目录下。总的抽象设备文作为fbcon.c,在这个目录下还有与各种显卡驱动程序相关的源文件。


在使用帧缓冲时,Linux是将显卡置于图形模式下的。


我们以一个简单的例子来说明字符显示的过程。我们假设是在虚拟终端1(/dev/tty1)下迁行如下的简单程序:


main ()


{


puts(”hello,world.

”);


}


pputs函数向缺省输出文件(/dev/tty)发出“写”的系统调用write(2)。系统调用到Linux核心对应的核心函数->——console.c中的con_write( ), con_write( )最终会调用do_con_write(),在do_con_write()中负责把”hello,world.

”这个字符串放到tty1对应的缓冲区中去。


Do_con_write()还负责处理控制字符和光标的位置。让我们来看一下do_con-write()这个函数的声明:


Static int do_con_write(struct


Tty_struct * tty, int


from_user, const unsigned


char *buf, int count )


其中tty是指向tty_struct结构的指针,这个结构里存放着关于这个tty的所有信息(请参照linux/include/linux/tty.h)。tty_srtuct结构中定义了?p> 用(或高层)tty的属性(例如宽度和高度等)。


在do_con_write()函数中用到了tty_struct结构中的driver_data变量。Driver_data是一个vt_vt_stuct指针。在vt_struct结构中包含这个tty的序列号(我们正使用tty1,所以这个序号为1)。Vt_struct结构中有一个vc结构的数组vc_cons,这个数组就是各虚拟终端的私有数据。


Static int do_write(struct


Tty_struct * tty, int


From_user,const unsigned char


*buf, int conut)


{


struct vt_struct *vt = (struct


vt_struct *)tty_>driver_data;


//我们用到了driver_data变量


…………


currcons = vt->_num;


//在这里的vc_nums就是1


…………


}


要访问虚拟终端的私有数据,需使用vc_cons[currcons].d指针。这个指针指向的结构含有当前虚拟终端上光标的位置,缓冲区的起始地址、缓冲区大小等信息。


“hello,world.

”中的每一个字符都要经过conv_uni_to_pc()这个函数转换成8位的显示字符。这样做的主要目的是使不同语言的国家能把16位的Unicode码映射到8位的显示字符集里,目前主要还是针对欧洲国家的语言,映射结果为8位,不包含双字节(double byte)的范围。


这种从Unicode到显示字符的映射表上,会把中文的字符映射到其他的字符上,这是我们不希望看到也是不需要的,所以我们有两种选择:


1) 不进行conv_uni_to_pc()的转换


2) 加载符合双字节处理的映射关系,即对蜚 控制字符进行一对一的不变映射,我们自己定制的符合这种映射关系的Unicode码表是direct.uni。


要想看/装载当前系统的Unicode映射表,可使用外部命令loadunimap。


经过conv_uni_to_pc()转换之后,”hello, world.

”中的字符被一个一个地填写到tty的缓冲区中,然后do_con_write()调用底层的驱动程序,把缓冲区中的内容输出到显示器上(也就相当于把缓冲区的内容拷贝到VGA显存中去)


sw->con putcs(vc_cons[currcons].d,


(u16 *)draw_from, (u16 *)draw_to_


(u16 *)draw_rwom, Y, draw_x);


之所以要调用底层驱动程序,是因为存在不同的显示设备,其对应VGA显存的存取方式也不一样。


上面的Sw->con_putcs()就会调用fbcon.c中的fbcon_putcs()函数(con_putcs是一个函数的指针,在 Framebuffer模式)下指向fbcon_putcs()函数,也就是说,在do_con_write()函数中是直接调用了fbcon_putcs()函数来进行址幕嬷疲热缢翟?56色模式下,真正负责输出的函数是:void fbcon_cfb8_putcs(struct vc_d

ta *conp,struct display *p, const unsignde short *s, int count, int YY, int xx )


显示中文


比如说我们试输出一句中文:putcs(你好

”)(“你好”的内码为0xc4.0xe3.0ba.0xc3)。这时候会怎么样呢?有一点可以肯定,“你好”肯定不会出现在屏幕上,原因是:


1、核心中没有汉字字库,中文显示就是无米之炊了。


2、在负责字符显示的void fbcon_cfb8_putcs()函数中,原有操作如下:


对于每个要显示的字符,依次从虚拟终端缓冲区中以WORD为单位读取(低位字节是ASCII码,高8位是字符的属性)。由于汉字是双字节编码方式,所以这种操作是不可能显示出汉字的,只能显示出xxxx_putcs()输出的是一个一个的VGA字符。


因此,要解决的问题:确保在调用do_con_write()时进行uni_pc转换不会改变原有编码,一个很直接的实现方式就是加载一个我们自己定制的Unicode映射表,loadunimap dirdct.uni,或者进接把direct.uni设置为核心的缺省映射表。


针对以上问题,我们要做的第一个尝试方案如下:


首先需要在核心中加载汉字字库,然后修改fbcon_cfb8_putcs()函数,在fbcon_cfb8_putcs()中一次读两个WORD,检查这两个WORD的低位字节是否能拼成一个汉字,如果发现能拼成一个汉字,就算出这个汉字在汉字字库的的偏移,然后把它当成个16×16的VGA字符来显示。


试验的结果表明:


1、能够输出汉字,但仍有许多不理想的地方,比如说,输出以半个汉字开始的一串汉字,则这半个汉字后面的汉字都会是乱码,这是“半个汉字”的问题。


2、光标移动会破坏汉字的显示,表现为,光标移动过的汉字会变成乱码,这是因为光标的更新是通过xxxx_putc()函数来完成的。


xxxx_putc()函数与xxxx_putcs()函数实现的功能够类似,但是xxxx_()函数只刷新一个字符而不是一个字符串,因而xxxx_putc()的输入参数是一个整数,而不是一个字符串的地址,xxxx_putc()函数的声明如下:


void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int YY, int xx)


下一个尝试方案就是同时修改xxxx_putc()函数和xxxx_putc()函数为了解决半个汉字的问题,每一次输出之前,都从屏幕当前行的起始位置开始打措,以确定要输出的字符是否落在半个汉字的位置上,如果是在半个汉字的位置上,如果是在半个汉字的位置,则进行相应的调整,即从向前移动一个字节的位置开始输出。


这个方案有一个困难,即xxxx_putc()函数不用缓冲区的地址,而是用一个整数作为参数,所以xxx

_putc()无法直接利用相邻的字符来判别该字符是否是汉字。


解决方案是,利用xxxx_putc()的光标们置参数(yy,xx),可以逆推出该字符在缓冲区中的位置,但仍一些小麻烦,在Linux的虚拟终端下,用户可能会上卷该屏幕(Shift+Pageup),导致光标的y座标和相应字符在缓冲区的行数不一致,相应的解决方案是,在逆推的过程中,考虑在屏的参量。


这样一来,我们就又进了一步,得到了一个相对更好的版本。但仍有问题没有解决,敲入turbonetcfg,会发现菜单的边框字符也被当成汉字显示,这是因为,这种边框字符是扩展字符,也使用了字符的低8位,因而被当成汉字显示,这是因为,这种边框字符是扩展字符,也使用了字符的低8位,因而被当作汉字来赤示。例如,单线“—”的制表符内码为0xC4,当连成一条长线时就是由一连串0xC4组成的,而0Xc4c4正是汉字“哪”,于是水平的制表符被一连串的“哪”字替代了,因为制表符的种类比较多,而且垂直制表符与其后面字符的组合形式又多种多样,因而很难判断出相应位置的字符是不是制表符,从理论上说,无论采取什么样的排除算法,都必然存在误判的情况,因为总存在二义性,没有充足的条件来推断出当前字符究竟是制表符还是汉字。


我们一方面寻找更好的排除组合算法,一方面试图寻找其他的解决方案,要想从根本上解决这个问题,必须利用其他的辅助信息,仅仅利用缓冲区的字符来判断是不够的。


经过一番努力,我们发现,在UNIX中使用扩展字符时,都要先输出字符转义序列(Escape sepuence)来切换当前字符集。字符转义序列是以控制字符Ecs为首的控制命令,在UNIX的虚拟终端中完成终端控制命令,这种命令包括移动光标座标、卷屏、删除、切换字符集等等。也就是说,在输出代表制表的字符串之前,通常是要先输出特定的字符转义序列,在console.c里,有根据字符转义序列命令来记录字符状态的变量,结合该变量提供的信息,就可以非常准确地把制表符与汉字区别开来。


在如上思路的指引下,我们又产生了新的解决方案,经过改动得到了另一版本。


在这个新的版本上,turbonetcfg在初次绘制的时候,制表符与汉字被清晰地区分开,但还有问题:turbonetcfg在重绘的时候(如切换虚拟终端或是移动鼠标光标的),制表符还是变成了汉字,因为重绘完全领带于缓冲区,而这时用来记录字符集状态的变量并不反映当前字符集状态。问题还是没有最终解决,我们又回到了起点。


看来问题的最终解决手段必须是把字符集的状态伴随着每一个字符在

撼迩校梦颐抢囱芯恳幌禄撼迩慕峁埂?


每一个字符占用16位的缓冲区,低6、8位是ASCII值,完全被利用,高8位饮食前量颜色和背景颜色的属性,也没有多余的空间可以利用,因而只能另外开辟新的缓冲区。为了保持一致性,我们决定在原来的缓冲区后面添加相同大小的缓冲区,用来存放是否汉字的信息。


也许有读者会问,只需要为每个字符添加一位信息来标志是否是汉字就足够了,为什么还要开辟与原缓冲区大小相同的双倍缓冲区,这是不是太浪费呢?


我们先放下这个问题,稍后再作回答。


其实,如果再添加一位来标志当前字符是汉字的左半边还是历半边的话,就会省去扫描屏幕上当前整行字符串的工作,这样一来,编程会更简单,但是有读者会问,即使是这样,使用8位总够用了吧?为什么还要使用16位呢?


我们的做法是:用低8位来存放汉字另外一半的内码,用高8位中的2位来存放上面所讲的辅助信息,高8位的剩余6位可以用来存放汉字或其他编码方式(如BIG5或日文、韩文)的信息,从而使我们可以实现同屏显示多种双字节语言的字符而不会相互干扰。另外,在编程时,双倍缓冲也比较容易计算。这样我们就回答了如上的两个问题。


迄今为止,我们有了一套彻底解决汉字和制表符相互干扰,半个汉字的刷新、重绘等问题的方案。剩下的就是具体编程来实现的问题了。


但是,由于Framebuffer的驱动程序很多,修改每一个驱动程序的xxxx_putc()函数和xxxx_putcs()函数会是一项不小的工作,而且,改动驱动程序后,每种驱动程序的测试也是很麻烦的,尤其是对于有硬件加速的显卡,修改和测试会更不容易。


那么,是否存在一种不需要修改显卡驱动程序的方法呢?经过一番努力,我们发现,可以调用xxxx_putcs()或xxxx_putc()函数输出汉字之前,修改VGA字库指针使其指向所需显示的汉字在汉字字库中的位置,即把一个汉字当成两个VGA ASCII字符输出。也就是说,在内核中存在两个字库,一个是原有的VGA字符字库,另一个是汉字字库,当我们需要输出汉字的时候,就把VGA字库的指针指向汉字字库的相应位置,汉字输出完之后,再把该指针指向VGA字库的原有位置。


这样一来,我们就只需要修改fbcon..c和console.c,其中console.c负责维护双倍缓冲区,把每一个字符的信息存入附加的缓冲区中;而fbcon.c负责利用双倍缓冲区中的附加的信息,调理 VGA字库的指针,调用底层的显示驱动程序。


这里还有几个需要注意的地方:


1、由于屏幕重绘等原因,调用底层xxxx_putc()和xxxx_putc

()的地方有多处,我们做了两个函数分别馐这两上调用,完成替换字库、调用xxxx_putcs()或xxxx_putc()、恢复字库等功能。


2、为了实现向上滚屏时也能看到汉字,我们需要作另外的修改。Linux在设计虚拟终端的时候,提供了回顾被滚出屏幕以外的信息的功能,这就是用热键来向上滚屏(Shift+Pageup)。当前被使用的虎虚拟终端的时候,公共缓冲区的内容会被清除而被新的虚拟终端使用,向上滚屏的时候,显示的是公共缓冲区中的内容。因此,如果我们想在向上滚屏的时候看到汉字,则公共缓冲区也必须加倍,以确保没有信息丢失。当滚出屏幕的住处向公共缓冲区填写的时候,必须把盯应的附加信息也填写进公共缓冲区的附加区域中,这就要求fbcon.c必须懂得利用公共缓冲区的附加信息。当然,另外有一处偷懒的方法,那就是不允许用户向上滚屏,从而避免对公区缓冲区的处理。


3、把不同的编码方式(GB、BIG5、日文和韩文)写成不同的模块,以实现动态加载,从而使得扩展新的编码方式不需要重新编译核心。


小结


通过这次针对inux核心的探索,我们发现,目前Linux的核心设计中,完全没有考虑到双字节编码字符的显示,我们在这种情况下摸索出一套解决核心汉字显示的方法,并编码实现了该方案。遵循核心的GPL版权声明,我们同时公布了实现这一技术的源代码,当然,这些改动仍然是GPL的。如果能对研究核心的朋友有所帮助,养活一些大家对核心的神秘感,将是我们最大的收获。


但是对核心和中文化来说,这仅仅是一种尝试,远不是终点。这种改动多少带有一些黑客的色彩,不太可能融合进权威的核心里去。我们仍在积极探索圆满解决这一问题的方法,当然这一目标必然需要通过国内外Linux群体的共同努力才能实现。我们也非常欢迎大家和我们共同讨论这一问题