热门搜索词：
龙破九天城主战玩法
　 &龙破九天城主战是帮派之间的玩法之一，城主战怎么玩呢，一起来看看吧。　　城主战：　　每周一、三和五20：00-20：45，玩家等级达到38级，加入帮派，通过帮派管理员，进入城主战活动场景，抢夺王城，进入活动场景，参与活动可获得丰厚的经验。　　玩法说明：　　1)帮主进入城中间占领神石并且守住15分钟可获胜，初始占领有3分钟保护;　　2)护城将军争夺会在城主争夺战结束之后立即开启(城主战结束，城主帮派帮主会立即传出活动场景);　　3)护城将军争夺模式和城主争夺模式想通，但护城将军争夺只需要守旗8分钟可获胜，争夺目标是东、西将军旗;　　4)城主争夺战和护城将军争夺，都只有帮主才有资格采集神石和军旗。温馨提示：以上内容仅供参考，请以游戏内实际为准。51：51网页游戏：
&&诚意推荐：十载传奇梦，铁血兄弟情！铁血皇城：热血不灭再战十年，100%传奇玩法！传奇霸业：杨幂代言，陪你主宰大千世界！我是大主宰：小骨与尊上虐心师徒恋，玩同名游戏！花千骨：***************************************************************魔剑士觉醒，奇迹再现！大天使之剑：正版授权，与您约战新传奇！七杀官网：邀您寻昔日兄弟，战热血沙城！传奇盛世：谁说男人才能称帝？张馨予带你战天下！皇图：除魔天地间，仗剑诛妖邪！轩辕剑之天之痕：
51游戏盒子字体在计算机及嵌入式系统中是如何处理的？
单片机&嵌入式
单片机应用
嵌入式操作系统
学习工具&教程
学习和开发单片机的必备工具
(有问必答)
(带你轻松入门)
电子元件&电路模块
当前位置： >>
>> 浏览文章
字体在计算机及嵌入式系统中是如何处理的？
在我们进行嵌入式开发中，会碰到人机界面中液晶屏的应用问题，对于没有字库的液晶屏（比如现在大量应用的TFT），需要自己设计字库，也就是利用软件提取字符或汉字的点阵数据，这就会在程序中涉及到字符的点阵数据的寻址问题。以便程序中你想显示的字符，可以在字库中找到对应的代码。那么在当你在程序中输入汉字字符或字母、符号时，程序会如何对他们进行处理呢？懂了这个处理过程，也就理解了程序如何找到对应的字符库。摘录了别人的一个贴子进行理论上的学习。然后再编写一小段程序来验证和查看字符所对应的数据。
如果你用放大镜看一下，可以看出屏幕上的字是由一个一个的像素点组成的，每一个字符用一组像素点拼接出来，这些像素点组成一幅图像，变成了我们的文字，计算&机又是如何将我们的文字保存起来的呢？是用一个个的点组成的图像将文字保存起来的吗？当然不是，让我们从英文开始，由于英文是拼音文字，实际上所有的英文&字符和符号加起来也不超过100个，在我们的文字中存在着如此大量的重复符号，这就意味着保存每个字符的图像会有大量的重复，比如&e&就是出现最多的符号等等。所以在计算机中，实际上不会保存字符的图像。&
&什么是字符编码？
&由于我们的文字中存在着大量的重复字符，而计算机天生就是用来处理数字的,为&了减少我们需要保存的信息量，我们可以使用一个数字编码来表示每一个字符，通过对每一个字符规定一个唯一的数字代号，然后，对应每一个代号，建立其相对应&的图形，这样，在每一个文件中，我们只需要保存每一个字符的编码就相当于保存了文字，在需要显示出来的时候，先取得保存起来的编码，然后通过编码表，我们&可以查到字符对应的图形，然后将这个图形显示出来，这样我们就可以看到文字了，这些用来规定每一个字符所使用的代码的表格，就称为编码表。编码就是对我们&日常使用字符的一种数字编号。&
第一个编码表&ASCII
在最初的时候，美国人制定了第一张编码表&《美国标准信息交换码》，简称&ASCII，它总共规定了&128&个符号所对应的数字代号，使用了&7&位二进制的位来表示这些数字。其中包含了英文的大小写字母、数字、标点符号等常用的字符，数字代号从&0&至&127，ASCII&的表示内容如下：
0&&&31&&&&&&&&&控制符号
32&&&&&&&&&&&&&&空格
33-47&&&&&&&&&&&常用符号
48-57&&&&&&&&&&&数字
58-64&&&&&&&&&&&符号
65-90&&&&&&&&&&&大写字母
91-96&&&&&&&&&&&符号
97-127&&&&&&&&&&小写字母
注意，32&表示空格，虽然我们再纸上写字时，只要手腕动一下，就可以流出一个空格，但是，在计算机上，空格与普通得字符一样也需要用一个编码来表示，33-127&共95个编码用来表示符号，数字和英文的大写和小写字母。比如数字&1&所对应的数字代号为&49，大写字母&A&对应的代号为&65,&小写字母&a&对应的代号为&97。所以，我们所写的代码&hello,&world&保存在文件中时，实际上是保存了一组数字&104&101&108&108&111&44&32&119&111&114&108&100。我们再程序中比较英文字符串的大小时，实际上也是比较字符对应的&ASCII&的编码大小。
由于&ASCII&出现最早，因此各种编码实际上都受到了它的影响，并尽量与其相兼容。&
扩展&ASCII&编码&ISO8859
&&&&美国人顺利解决了字符的问题，可是欧洲的各个国家还没有，比如法语中就有许多英语中没有的字符，因此&ASCII&不能帮助欧洲人解决编码问题。
为了解决这个问题，人们借鉴&ASCII&的设计思想，创造了许多使用&8&位二进制数来表示字符的扩充字符集，这样我们就可以使用256种数字代号了，表示更多的字符了。在这些字符集中，从&0&-&127&的代码与&ASCII&保持兼容，从&128&到&255&用于其它的字符和符号，由于有很多的语言，有着各自不同的字符，于是人们为不同的语言制定了大量不同的编码表，在这些码表中，从&128&-&255&表示各自不同的字符，其中，国际标准化组织的&ISO8859&标准得到了广泛的使用。
在&ISO8859&的编码表中，编号&0&&&127&与&ASCII&保持兼容，编号128&&&159&共32个编码保留给扩充定义的&32&个扩充控制码，160&为空格，&161&-255&的&95&个数字用于新增加的字符代码。编码的布局与&ASCII&的设计思想如出一辙，由于在一张码表中只能增加&95&种字符的代码，所以&ISO8859&实际上不是一张码表，而是一系列标准，包括&14&个字符码表。例如，西欧的常用字符就包含在&ISO8859-1字符表中。在&ISO8859-7种则包含了&ASCII&和现代希腊语字符。
问题出现了！
&&&&ISO&的 8859标准解决了大量的字符编码问题，但也带来了新的问题，比如说，没有办法在一篇文章中同时使用&ISO8859-1&和&ISO8859-7，也就是说，在同一篇文章中不能同时出现希腊文和法文，因为他们的编码范围是重合的。例如：在&ISO8859-1&中&217号编码表示字符&U&，而在&ISO8859-7中则表示希腊字符&O，这样一篇使用&ISO8859-1&保存的文件，在使用&ISO8859-7编码的计算机上打开时，将看到错误的内容。为了同时处理一种以上的文字，甚至还出现了一些同时包含原来不属于同一张码表的字符的新码表。
大字符集的烦恼
&&&&不管如何，欧洲的拼音文字都还可以用一个字节来保存，一个字节由8个二进制的位组成，用来表示无符号的整数的话，范围正好是&0&&&255。
但是，更严重的问题出现在东方，中国，朝鲜和日本的文字包含大量的符号。例如，中国的文字不是拼音文字，汉字的个数有数万之多，远远超过区区&256&个字符，因此&ISO&的&8859&标准实际上不能处理中文的字符。
通过借鉴&ISO8859&的编码思想，中国的专家灵巧的解决了中文的编码问题。
既然一个字节的&256&种字符不能表示中文，那么，我们就使用两个字节来表示一个中文，在每个字符的&256&种可能中，低于&128&的为了与&ASCII&保持兼容，我们不使用，借鉴&ISO8859的设计方案，只使用从&160&以后的&96&个数字，两个字节分成高位和低位，高位的取值范围从&176-247&共72个，低位从&161&&&254共94这样，两个字节就有&72&*&94&=&6768种可能，也就是可以表示&6768&种汉字，这个标准我们称为&GB2312-80。
6768&个汉字显然不能表示全部的汉字，但是这个标准是在1980年制定的，那时候，计算机的处理能力，存储能力都还很有限，所以在制定这个标准的时候，实际上只包含了常用的汉字，这些汉字是通过对日常生活中的报纸，电视，电影等使用的汉字进行统计得出的，大概占常用汉字的&99%。因此，我们时常会碰到一些名字中的特殊汉字无法输入到计算机中的问题，就是由于这些生僻的汉字不在&GB2312&的常用汉字之中的缘故。
由于&GB2312&规定的字符编码实际上与&ISO8859&是冲突的，所以，当我们在中文环境下看一些西文的文章，使用一些西文的软件的时候，时常就会发现许多古怪的汉字出现在屏幕上，实际上就是因为西文中使用了与汉字编码冲突的字符，被我们的系统生硬的翻译成中文造成的。
不过，GB2312&统一了中文字符编码的使用，我们现在所使用的各种电子产品实际上都是基于&GB2312&来处理中文的。
GB2312-80&仅收汉字6763个，这大大少于现有汉字，随着时间推移及汉字文化的不断延伸推广，有些原来很少用的字，现在变成了常用字，例如：朱镕基的&镕&字，未收入 GB2312-80，现在大陆的报业出刊只得使用（金+容）、（金容）、（左金右容）等来表示，形式不一而同，这使得表示、存储、输入、处理都非常不方便，而且这种表示没有统一标准。
为了解决这些问题，全国信息技术化技术委员会于日《汉字内码扩展规范》。GBK向下与GB2312完全兼容，向上支持ISO&10646 国际标准，在前者向后者过渡过程中起到的承上启下的作用。GBK&亦采用双字节表示，总体编码范围为8140-FEFE之间，高字节在81-FE之间，低字节在40-FE之间，不包括7F。在&GBK&1.0&中共收录了&21886个符号，汉字有21003个。
GBK&共收入21886个汉字和图形符号，包括：
*&GB2312&中的全部汉字、非汉字符号。
*&BIG5&中的全部汉字。
*&与ISO&10646相应的国家标准GB13000中的其它CJK汉字，以上合计20902个汉字。
*&其它汉字、部首、符号，共计984个。
微软公司自Windows&95&简体中文版开始支持GBK代码，但目前的许多软件都不能很好地支持GBK汉字。
GBK&编码区分三部分：
*&汉字区　包括
GBK/2&：OXBOA1-F7FE,&收录GB2312汉字6763个，按原序排列；
GBK/3&：OX8140-AOFE，收录CJK汉字6080个；
GBK/4&：OXAA40-FEAO，收录CJK汉字和增补的汉字8160个。
*&图形符号区　包括
GBK/1&：OXA&1A1-A9FE，除GB2312的符号外，还增补了其它符号
GBK/5&：OXA840-A9AO，扩除非汉字区。
*&用户自定义区
即GBK区域中的空白区，用户可以自己定义字符。
GB18030&是最新的汉字编码字符集国家标准,&向下兼容&GBK&和&GB2312&标准。&GB18030&编码是一二四字节变长编码。&一字节部分从&0x0~0x7F与&ASCII&编码兼容。二字节部分,&首字节从&0x81~0xFE,&尾字节从&0x40~0x7E&以及&0x80~0xFE,&与&GBK标准基本兼容。&四字节部分,&第一字节从&0x81~0xFE,&第二字节从&0x30~0x39,&第三和第四字节的范围和前两个字节分别相同。
&不一样的中文
&中文的问题好像也解决了，且慢，新的问题又来了。
中国的台湾省也在使用中文，但是由于历史的原因，那里没有使用大陆的简体中文，还在使用着繁体的中文，并且他们自己也制定了一套表示繁体中文的字符编码，称为&BIG5,不幸的是，虽然他们的也使用两个字节来表示一个汉字，但他们没有象我们兼容&ASCII&一样兼容大陆的简体中文，他们使用了大致相同的编码范围来表示繁体的汉字。天哪!&ISO8859&的悲剧又出现在同样使用汉字的中国人身上了，同样的编码在大陆和台湾的编码中实际上表示不同的字符，大陆的玩家在玩台湾的游戏时，经常会遇到乱码的问题，问题根源就在于，大陆的计算机默认字符的编码就是&GB2312,&当碰到台湾使用&BIG5&编码的文字时，就会作出错误的转换。
&由于历史和文化的原因，日文和韩文中也包含许多的汉字，象汉字一样拥有大量的字符，不幸的是，他们的字符编码也同样与中文编码有着冲突，日文的游戏在大陆上&一样也会出现无法理解的乱码。《中文之星》，《南极星》，《四通利方》就是用于在这些编码中进行识别和转换的专用软件。
互联的时代
&在二十世纪八十年代后期，互联网出现了，一夜之间，地球村上的人们可以直接访问远在天边的服务器，电子文件在全世界传播，在一切都在数字化的今天，文件中的数字到底代表什么字？这可真是一个问题。
实际上问题的根源在于我们有太多的编码表。
如果整个地球村都使用一张统一的编码表，那么每一个编码就会有一个确定的含义，就不会有乱码的问题出现了。
实际上，在80年代就有了一个称为&UNICODE&的组织，这个组织制定了一个能够覆盖几乎任何语言的编码表，在&Unicode3.0.1中就包含了&49194&个字符，将来，Unicode&中还会增加更多的字符。Unicode&的全称是&Universal&Multiple- Octet&Coded&Character&Set&，简称为&UCS。
由于要表示的字符如此之多，所以一开始的&Unicode1.0编码就使用连续的两个字节也就是一个WORD&来表示编码，比如&汉&的UCS&编码就是&6C49。这样在&Unicode&的编码中就可以表示&256*256&=&65536&种符号了。
直接使用一个WORD&相当于两个字节来保存编码可能是最为自然的&Unicode&编码的方式，这种方式被称为&UCS-2，也被称为&ISO&10646，，在这种编码中，每一个字符使用两个字节来进行表示，例如，&中&&使用&11598&来编码，而大写字母&A&仍然使用&65&表示，但它占用了两个字节，高位用&0&来进行补齐。
&由于每个WORD&表示一个字符，但是在不同的计算机上，实际上对&WORD&有两种不同的处理方式，高字节在前，或者低字节在前，为了在UCS-2编码的文档中，能够区分到底是高字节在前，还是低字节在前，使用&UCS-2&的文档使用了一组不可能在UCS-2种出现的组合来进行区分，通常情况下，低字节在前，高字节在后，通过在文档的开头增加&FFFE&来进行表示。高字节在前，低字节在后，称为大头在前，即Big&Endian，使用&FFFE&来进行表示。这样，程序可以通过文档的前两个字节，立即判断出该文档是否高字节在前。
&Endian&这个词出自&《格列佛游记》，小人国的内战就源于吃鸡蛋时要先吃大头&big&endian&还是小头&little-endian，并由此发生了内战。
&理想与现实
&UCS-2&虽然理论上可以统一编码，但仍然面临着现实的困难。
首先，UCS-2&不能与现有的所有编码兼容，现有的文档和软件必须针对&Unicode&进行转换才能使用。即使是英文也面临着单字节到双字节的转换问题。
其次，许多国家和地区已经以法律的形式规定了其所使用的编码，更换为一种新的编码不现实。比如在中国大陆，就规定&GB2312&是大陆软件、硬件编码的基础。
第三，现在还有使用中的大量的软件和硬件是基于单字节的编码实现的，UCS-2&的双字节表示的字符不能可靠的在其上工作。
&新希望&UTF-8
&为了尽可能与现有的软件和硬件相适应，美国人又制定了一系列用于传输和保存Unicode&的编码标准&UTF，这些编码称为UCS&传输格式码，也就是将&UCS&的编码通过一定的转换，来达到使用的目的。常见的有&UTF-7，UTF-8，UTF-16等。
其中&UTF-8&编码得到了广泛的应用，UTF-8&的全名是UCS&Transformation&Format&8,&即&UCS&编码的8位传输格式，就是使用单字节的方式对&UCS&进行编码，使&Unicode&编码能够在单字节的设备上正常进行处理。
UTF-8&编码是变长的编码，对不同的&Unicode&可能编成不同的长度
&UCS-2&&&&&&&&&&&&&&&&&&&&&&&&&&&UTF-8
F&&&&0-&&127&&&&&&&&&&&&0xxxxxxx
0080-07FF&&128-&2047&&&&&&&&&&&&110xxxxx&10xxxxxx
&&&&0800-FFFF&&&&&&&&&&&&&1110xxxx&10xxxxxx&10xxxxxx
&&例如&1&的Unicode&编码是&31&00,在&0-127之间，所以转换后即为&31，而&中&字的UTF-8&Unicode&编码为&11598，转换成&UTF-8则为&e4&b8&ad。
实际上，ASCII&字符用&UTF-8&来表示后，与&ASCII&是完全一样的，美国人又近水楼台的把自己的问题解决了。但其他的编码就没有这么幸运了。
突破障碍&-&Unicode&与&本地编码的转换
&UTF-8&编码解决了字符的编码问题，又可以在现有的设备上通行，因此，得到了广泛的使用，&
&&&&XML&中的问题
&&&&XML&的设计目标是实现跨网络，跨国界的信息表示，所以，在XML&设计之初，就规定&XML&文件的默认编码格式就是&UTF-8，也就是说，如果没有特殊的说明，XML文件将被视为　UTF-8&编码。
然而，大部分的中文编辑软件，是根据操作系统来决定编码的方式的，所以，在写字板中直接输入并保存的文件，将被保存为&GB2312&编码，所以，在读出&XML文件内容时，往往就会出现文件错误的提示了。这种情况会出现在文件中有中文出现的时候，如果没有中文，只有英文信息，就不会出现问题。原因很简单，有中文时，因为中文的编码并不是UTF-8&编码，所以会造成冲突，没有中文时，英文的编码在GB2312&中与ASCII是兼容的，而 ASCII&与UTF-8&是完全一致的，所以不会出现问题。这种情况也包括&UltraEdit&软件。
但时，专业的&XML编辑软件会自动将内容保存为　UTF-8&编码，不会有问题。
在通过DOM或XSLT保存&XML&文件时也有着同样的问题。
默认情况下，XML&的处理程序一般会将内容作为&UTF-8&编码进行处理，所以保存下来的&XML&文件必须要用可以识别&UTF-8&的软件来进行查看，如Windows&的记事本。
&&Java&的处理
Java&的设计目标是一次编写，到处运行，所以在　Java&的内部对字符的处理采用了&UCS&来处理，因此&Java&的字符类型不再是&C++&中的一个字节，而使用两个字节来保存一个字符。
但是，我们会发现，在&Java&的文件流中保存为文件后，我们可以直接使用记事本或&UltraEdit&打开察看。
在这里，Java&采用了一个灵巧的默认转换机制，当需要将内容中的字符保存到文件中时，Java&会自动的查看一下系统的本地编码，系统的本地编码可以在控制面板中查到，然后，自动将&UCS&编码的字符转换为本地编码，并进行保存。当需要从系统的文件系统中读入一个文件时，Java&通过查看系统的本地编码来决定如何识别文件的内容。这样，Java&就可以在内部使用&UCS，&但用户可以直接使用本地编码的文件了。
Java&在相应的方法中，提供了额外的参数，可以让用户自己来指定文件的编码。
&&.Net&的处理
&&&&在微软的&.Net&内部，同样使用&UCS&编码，但是，在对文件进行处理的时候，与Java&有一些区别，.Net&不查询系统的本地编码，而是直接使用磨人的&UTF-8&编码进行文件的处理，所以，你保存的中文内容，在&UltraEdit&中可能就是乱码，但是，如果你使用记事本打开的话，就不会有问题，因为&Windows&的记事本可以识别&UTF-8&的编码。
.Net&软件的配置文件使用&XML&格式，默认的编码一样是&UTF-8&，所以，必须使用可以识别&UTF-8&的软件进行处理，如：vs.net，记事本等。
在&.Net&中，网页默认处理编码就是&UTF-8。
&&Web&中的问题
网页的编码问题主要有两点，一是网页是如何编码的，二是如何告诉浏览器如何编码的。
第一个问题，又可以分成静态页面和动态页面两个问题。
对静态页面，网页的编码要看你保存文件时的编码选项，多数的网页编辑软件可以让你选择编码的类型，默认为本地编码，为了使网页减少编码的问题，最好保存为&UTF-8&编码格式。
对动态页面，如&Servlet&生成的页面，在&HttpServletResponse&类中有一个方法&setContentType，可以通过参数来指定生成的页面的类型和编码，例如：response.setContentType(&text/&charset=utf-8&);来指定生成的页面的编码类型。
对&jsp&页面可以通过&&%@&page&contentType=&text/charset=gb2312&&%&&来指定生成的页面的编码及类型。
第二个问题，如何通知浏览器网页的编码类型。
浏览器收到只是一个字节流，它并不知道页面是如何编码的，因此，需要一个机制来告诉浏览器页面的编码类型，标准的机制是使用&&meta&http- equiv=&Content-Type&&content=&text/&charset=utf-8&&&来指定页面的编码，当浏览器读取页面遇到这样的指示时，将使用这里制定的编码方式重新加载页面。
否则的话，浏览器将会试图猜出页面的编码类型。
&&Tomcat&中的中文问题
&在&Tomcat&中，经常遇到取回客户端提交的信息是乱码的问题。
当提交表单的时候，HTML页面的Form标签会使情况变得更为复杂。浏览器的编码方式取决于当前页面的编码设定，对Form标签也照此处理。这意味着如果 ASCII格式的HTML页面用ISO-8859-1编码，那么用户在此页面中将不能提交中文字符。所以，如果你的页面使用的是&utf-8，那么&POST&的时候，也将使用&utf-8&。
由于&Tomcat&是美国人设计的，Tomcat&默认使用ISO8859-1&编码队客户端返回的内容进行解码，由于编码与内容不一致，就会出现乱码的&???&出现，根据以上的分析，在服务器端读取客户端回送的内容时，需要首先设定回送内容的编码，然后再进行信息的读取，通过使用&HttpServletRequest&的方法&setCharacterEncoding(&utf-8&)先行设定信息的编码类型。然后，就可以正确读取内容了。
&编码问题是信息处理的基本问题，但是由于历史和政治的问题，事实上存在着大量不统一的编码方式，造成在信息处理过程中的信息丢失，转换错误等问题，UCS&为问题的解决提供了一个很好的方向，但是，在现在的软件环境中，还没有达到全面地使用。在实际中工作中应尽量采用统一的编码格式，减少编码问题的发生。
总之：美国佬用7位（127）就解决了自己的问题，欧洲人又扩展了一个1位用8位（256）解决了自己的问题，都在一个字节内。咱中国人的象形字虽不太好处理，但凭国人的智慧用两个字节把自己的问题也解决了。
下面咱就看看在单片机中，一个字符，转变成了什么样的了？
当然编译工作是在计算机上完成的，这个汉字的转化工作也是计算机完成的。程序下载到单片机后，假如我们想要知道，汉字转化后的数据是多少怎么办呢？可惜本人不是计算机开发人员，只能在KEIL环境中用个笨办法来实现。查看转化后的数据。
编写下面的一段程序：
/********************************************&
&*&&copyright&(c)&2014,曲阜XXX
&*&&all&rights&reserved.
&*name&&:&查看汉字，字母，符号的存储代码&
&*description:&输入一个汉字，字母，符号，通过模拟运行，查看它们被存放的数&&&&&&&&据，汉字一般两个字节即可，程序中设置了4个字节。
&*version:&1.1
&*author:&xiangzhi&K
&*data:&&&
&***************************************************/
#include&STC15F2K.H&&&&//头文件
&unsigned&char&&cma[4]=&孔&;//定义一个四个元素的数组用来存放字符代码
/*******串行口的初始化函数*****************/
void&UartInit(void)//9600bps@11.0592MHz
SCON&=&0x50;//8位数据,可变波特率
AUXR&|=&0x40;//定时器1时钟为Fosc,即1T
AUXR&&=&0xFE;//串口1选择定时器1为波特率发生器
TMOD&&=&0x0F;//设定定时器1为16位自动重装方式
TL1&=&0xE0;//设定定时初值
TH1&=&0xFE;//设定定时初值
ET1&=&0;//禁止定时器1中断
TR1&=&1;//启动定时器1
/********串行口发送数据函数****************/
void&senddata(unsigned&char&dat)
&SBUF=//数据送入串口寄存器发送
/**********主函数**********************/
void&main()
&unsigned&char&i=0;//定义一个局部变量i
&UartInit();//调用串口初始化函数
&for(i=0;i&4;i++)&&//循环4次输出4个字节的数组数据
&&&senddata(cma[i]);//串行口输出依次输出数组中的数据
将上面的程序，进行编译，点击debug&&&start/stop&debug&session&打开&运行&界面，
点击peripherals&&&serial&&serial&0&打开串口0的界面，
点击&watch1&&在name下的对话框中双击，然后输入i，以便观察局部变量i的值的变化。
点击&step&或点击F11键，开始单步运行，注意观察&串行口0的界面&中的SBUF0框中的值，你就可以看到如下顺序值：0xBF，0XD7，0X00,0X00.
也就是说&孔&这个汉字，经过处理，变成了一个两字节的数字，0XBF,0XD7.
你可以将unsigned&char&&cma[4]=&孔&;中的孔改成其他的文字，比如
unsigned&char&&cma[4]=&度&;就会得到0XB6,0XC8；
假如把中文换成字母，结果会是什么呢？
比如unsigned&char&&cma[4]=&a&;呵呵，是不是得到了&0X61,0X00,0X00,0X00.那么你在对照一下ASCII码表，这个小写的a的十六进制值是不是就是61呢。
说这么多目的是，为了理解程序是如何处理字符的。以便将来自己建立字符库时，明白字符如何在字符库中找到自己对应的库的。
至于如何建立字符库，以及不同的字符找到对应的显示代码的程序编写方法。下一次再作说明。
【】【】【】【】
上一篇:下一篇:
CopyRight @
单片机教程网
, All Rights Reserved最新加入会员
会员金币排行
认为本站还应该怎么做才好?
多增加不同栏目
增强上传功能
提供更多的打包下载
增加相应的音频
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
基督教歌谱网() & 2014 版权所有 All Rights Reserved.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}