首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

GB2312编码_gb2312是简体中文的编码格式

在区码和位码的基础上,分别加上0XA0的偏移,便是GB2312编码; 我们制作ASCII字库时,一般只做可以显示出来的字符字模,前面命令型的ASCII字符,我们不做字模,即从“空格开始”,ASCII...该空格的区位码是“0101”,所以任意一个汉字的偏移地址公式是,Address= ( (CodeH-0x30-1)*94+(CodeL-0x30-1) )*( 16*16 )/8;CodeH是GB2312...的第一个字节,CodeL是GB2312的第二个字节,减一 是因为区位码是从第一区开始的,而字模数组表是从0开始的; (以上的计算均是按16*16取模时计算的) 当我使用单片机编程工具写程序时,编译的时候...,编译器会根据我们的选择(如MDK)会自动将字符串转换成机内码即GB2312形式进行存储,所以我们可以根据GB2312与区位码的关系进行寻找地址偏移。...uint16 hz ) 可以这样找区位码,CodeH=hz>>8; CodeL=hz&0x00ff; 注意英文和汉字的参数定义类型一个是8位uchar 型的,一个是u16位int16型的,因为GB2312

1.2K20
您找到你想要的搜索结果了吗?
是的
没有找到

一图弄懂ASCII、GB2312、GBK、GB18030编码

兼容性关系是GB18030兼容GBK,GBK兼容GB2312GB2312兼容ASCII。所谓兼容,你可以简单理解为子集、不冲突的关系。...例如GB2312编码的文件中可以出现ASCII字符,GBK编码的文件中可以出现GB2312和ASCII字符,GB18030编码的文件可以出现GBK、GB2312、ASCII字符。...在GB2312中收录了6763个汉字以及682个特殊符号,已经囊括了生活中最常用的所有汉字。 【3】GBK 由于GB2312只有6763个汉字,我汉语博大精深,只有6763个字怎么够?...于是GBK中在保证不和GB2312、ASCII冲突(即兼容GB2312和ASCII)的前提下,也用每个字占据2bytes的方式又编码了许多汉字。...实际生活中,我们用到的99%以上的汉字,其实都在GB2312那一块区域内。至于GB2312每个编码对应的到底是哪个汉字本文不再赘述,可以参考链接(链接地址)查询。

39.3K153

unicode、utf-8、ansi、gbk、gb2312编码详解

unicode、utf-8、ansi、gbk、gb2312编码详解 前言 作为一个开发人员或是测试人员,免不了要与各种各样的编码打交道,而且这些各种编码总是让人头大,现在我们就来揭开他们的庐山真面目 移动还是联通...中国人民看到这样很不错,于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩 展。 但是,你以为这样就够用了吗?...当然不行,gb2312能够表示很多简体汉字,但是繁体怎么办呢?台湾群众很不满啊,于是也自己搞了一套编码,于是big-5诞生了,你以为这样就完了?...gb2312仅仅可以表示6000多个常用汉字你让其它不常用的怎么办?...于是扩展呗,把之前gb2312中没有利用的位好好利用起来,就成了gbk,这又增加了20000多个汉字,但是咱们少数名族也要用电脑啊,于是有了后来的 GB18030 GB2312和GBK都是用两个字节来编码的

3.6K62

我知道你不知道GB2312

另一类是ANSI类,最常见的是GB2312/GBK/GB18030三种,他们能很好支持中文,但是面对其它语言可能出现乱码。...现在让我们回到最初提到的那个“仿宋GB2312”的问题,答案一目了然了。首先要明确的是,的确有两种仿宋字体,一种叫做“仿宋GB2312”,另一种叫做“仿宋”。...其中“仿宋GB2312”顾名思义,遵循的是GB2312标准,发布时间早,收录的字数也少;而“仿宋”遵循的是微软自己的GBK标准,发布时间晚、收录字数多,是Windows以及Office的默认字体。...也就是说,如果你想安装“老古董”“仿宋GB2312”,你还得另外去下载,然鹅—— “ 仿宋GB2312竟然TM是很多政府的公文专用字体!!!...有没有发现“仿宋GB2312”要比“仿宋GBK”的字体粗一些?

1.9K30

实例探究字符编码:unicode,utf-8,default,gb2312 的区别

最近做邮件收发,不同的邮件系统间可能会出现编码问题,迫使我重新回来研究一下字符的编码问题,unicode,utf-8,gb2312这些编码格式都是我们熟知的,default 编码格式是哪一种呢?...").getbytes(str);             printbyte("gb2312:", buffergb2312);     下面是输出结果: utf8:   string length...再仔细看看utf-8对于"china,"这6个字符的编码: 67 104 105 110 97 44  gb2312 和 default 编码结果也是这样; 而unicode的编码是: 67 0 104...所以,utf-8,gb2312等编码都是“变长编码”的,但是对于中文的编码处理上,gb2312所需的字节更少。...而default 编码,则取决于当前系统编码,比如我们的操作系统安装的时候默认选择的都是“简体中文”(gb2312),所以测试中也证实了当前的环境编码格式 gb2312=default     因此,我们在使用国外开源的代码的时候

1.4K100

spring cloud 学习(11) - 用fastson替换jackson及用gb2312码输出

前几天遇到一个需求,因为要兼容旧项目的编码格式,需要spring-cloud的rest接口,输出gb2312编码,本以为是一个很容易的事情,比如下面这样: @RequestMapping(method...= RequestMethod.POST, value = "syncPaymentList", consumes = {"application/json; charset=gb2312..."}, produces = {"application/json; charset=gb2312"}) public GatewayDataResult<DcbOrderListResponse...,内容本身并没有变化(即:浏览器设置成简体中文,显示乱码) 有一个很简单粗暴的办法,到是可以(参考下面的),但是对原来代码改变太大: @RequestMapping(method = RequestMethod.GET...} 另外网有一些办法,比如修改application.yml spring: http: encoding: enabled: true charset: GB2312

1.2K10

asp.net 解码gb2312下urlencode后的字符串

公司网站前期的网页用了gb2312保存用户数据,而我负责的部分用的是utf8,今天恰好要获取前期录入的数据于是毫无悬念地出现乱码问题,经过一番网上的搜索还是找不到完整解决方法,折腾好一段时间终于通过下面的例子推出了问题的所在...: 这样的一个业务,客服用gb2312编码后 提交服务器,服务器接收时出现乱码,用System.Web.HttpUtility.UrlDecode();解码 ,还是出现乱码,困老了我好长时间,终于在google...解决方案: HttpUtility.ParseQueryString(Request.Url.Query, System.Text.Encoding.GetEncoding("GB2312"))["message...于是了解到UrlEncode是基于页面的编码方式,那么前期保存到的数据时基于gb2312来UrlEncode的,所以在utf8页面解码时要指定用gb2312的方式来解码。...具体做法: System.Web.HttpUtility.UrlDecode("需解码的GB2312编码字符串",Encoding.GetEncoding("gb2312"));

1.2K50
领券