细说一个汉字等于几个字符,以及汉字,字符,字节,位之间的关系

细说一个汉字等于几个字符,以及汉字,字符,字节,位之间的关系细说一个汉字等于几个字符 以及汉字 字符 字节 位之间的关系全文主旨总结 一 1 个汉字 1 个字 1 个字符二 1 个字符 1 个字节 8bit ACSII 码下 三 1 个字符 2 个字节 16bit Unicode 码下 四 自我认识 在处理汉字时 会默认

—————-

字符编码简介
       先从ASCII说起。ASCII是用来表示英文字符的一种编码规范,每个ASCII字符占用1个字节(8bits)。因此,ASCII编码可以表示的最大字符数是256,其实英文字符并没有那么多,一般只用前128个(最高位为0),其中包括了控制字符、数字、大小写字母和其他一些符号。而最高位为1的另128个字符被成为“扩展ASCII”,一般用来存放英文的制表符、部分音标字符等等的一些其他符号。这种字符编码规范显然用来处理英文没有什么问题。(实际上也可以用来处理法文、德文等一些其他的西欧字符,但是不能和英文通用),但是面对中文、阿拉伯文之类复杂的文字,255个字符显然不够用,于是,各个国家纷纷制定了自己的文字编码规范,其中中文的文字编码规范叫做“GB2312-80”,它是和 ASCII兼容的一种编码规范,其实就是利用扩展ASCII没有真正标准化这一点,把一个中文字符用两个扩展ASCII字符来表示。但是这个方法有问题,最大的问题就是,中文文字没有真正属于自己的编码,因为扩展ASCII码虽然没有真正的标准化,但是PC里的ASCII码还是有一个事实标准的(存放着英文制表符),所以很多软件利用这些符号来画表格。这样的软件用到中文系统中,这些表格符就会被误认作中文字,破坏版面。而且,统计中英文混合字符串中的字数,也是比较复杂的,我们必须判断一个ASCII码是否扩展,以及它的下一个ASCII是否扩展,然后才“猜”那可能是一个中文字。
       总之当时处理中文是很痛苦的。而更痛苦的是GB2312是国家标准台湾当时有一个Big5编码标准,很多编码和GB是相同的,所以……,嘿嘿。这时候,我们就知道,要真正解决中文问题,不能从扩展ASCII的角度入手,也不能仅靠中国一家来解决。而必须有一个全新的编码系统,这个系统要可以将中文、英文、法文、德文……等等所有的文字统一起来考虑,为每个文字都分配一个单独的编码,这样才不会有上面那种现象出现。于是,Unicode诞生了。

       Unicode 有两套标准,一套叫UCS-2(Unicode-16),用2个字节为字符编码,另一套叫UCS-4(Unicode-32),用4个字节为字符编码。以目前常用的UCS-2为例,它可以表示的字符数为2^16=65535,基本上可以容纳所有的欧美字符和绝大部分的亚洲字符。UTF-8的问题后面会提到。在Unicode里,所有的字符被一视同仁。汉字不再使用“两个扩展ASCII”,而是使用“1个Unicode”,注意,现在的汉字是“一个字符”了,于是,拆字、统计字数这些问题也就自然而然的解决了。但是,这个世界不是理想的,不可能在一夜之间所有的系统都使用 Unicode来处理字符,所以Unicode在诞生之日,就必须考虑一个严峻的问题:和ASCII字符集之间的不兼容问题。我们知道,ASCII字符是单个字节的,比如“A”的ASCII是65。而Unicode是双字节的,比如“A”的Unicode是 0065,这就造成了一个非常大的问题:以前处理ASCII的那套机制不能被用来处理Unicode了。另一个更加严重的问题是,C语言使用’\0’作为字符串结尾,而Unicode里恰恰有很多字符都有一个字节为0,这样一来,C语言的字符串函数将无法正常处理Unicode,除非把世界上所有用C写的程序以及他们所用的函数库全部换掉。于是,比Unicode更伟大的东东诞生了,之所以说它更伟大是因为它让Unicode不再存在于纸上,而是真实的存在于我们大家的电脑中。那就是:UTF。UTF = UCS Transformation Format UCS转换格式。它是将Unicode编码规则和计算机的实际编码对应起来的一个规则。现在流行的UTF有2种:UTF-8和UTF-16。其中UTF-16和上面提到的Unicode本身的编码规范是一致的,这里不多说了。而UTF-8不同,它定义了一种“区间规则”,这种规则可以和ASCII编码保持最大程度的兼容。UTF-8有点类似于Haffman编码,它将Unicode编码为00000000-0000007F的字符,用单个字节来表示;00000080-000007FF的字符用两个字节表示 00000800-0000FFFF的字符用3字节表示。因为目前为止Unicode-16规范没有指定FFFF以上的字符,所以UTF-8最多是使用3 个字节来表示一个字符。但理论上来说,UTF-8最多需要用6字节表示一个字符。在UTF-8里,英文字符仍然跟ASCII编码一样,因此原先的函数库可以继续使用。而中文的编码范围是在0080-07FF之间,因此是2个字节表示(但这两个字节和GB编码的两个字节是不同的),用专门的Unicode处理类可以对UTF编码进行处理。
      下面说说中文的问题。由于历史的原因,在Unicode之前,一共存在过3套中文编码标准。GB2312-80,是中国大陆使用的国家标准,其中一共编码了6763个常用简体汉字。Big5,是台湾使用的编码标准,编码了台湾使用的繁体汉字,大概有8千多个。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/207822.html原文链接:https://javaforall.net

(0)
上一篇 2026年3月19日 下午1:01
下一篇 2026年3月19日 下午1:01


相关推荐

  • vue创建项目的步骤

    vue创建项目的步骤1 由于 vue 项目依赖 node jsnpm 需要先安装 若没有请先安装 检查是否有 node jsnpmvueWind R 输入 cmd 输入 node v 回车会出现 node js 的版本输入 npm V V 大写 回车会出现 npm 的版本如果没有安装 vue 输入 npminstall gvue cli

    2026年3月17日
    2
  • django 自定义user_tb程序化交易模型源码

    django 自定义user_tb程序化交易模型源码前言Django为我们提供了内置的User模型,不需要我们再额外定义用户模型,建立用户体系了。它的完整的路径是在django.contrib.auth.models.User。User模型源码分析

    2022年7月30日
    5
  • 图书管理系统课设报告(含用例图、通信图、顺序图、状态图、活动图)

    图书管理系统课设报告(含用例图、通信图、顺序图、状态图、活动图)面向对象的系统分析与设计课程实验报告 1 研究背景及意义学校图书馆希望设计一个图书管理系统 管理读者的登记 图书的购入 借出 归还以及注销等 管理人员还可以查询某位读者 某本图书的当前借阅情况 历史借阅记录 并可按照读者角度 图书角度 借阅角度分别进行统计 给出统计报表 以全面掌握图书的流通情况 目前图书馆为手工管理 读者办理借阅等手续麻烦 而且管理员工作量打 开发这个系统最主要是方便管理 读者可以咋计算机上查询 预订图书 不须到图书馆直接去查找 这样节省了很多时间 管理员也可以再计算机

    2026年3月17日
    2
  • 求解逆矩阵的常用三种方法_阿桑的专栏_逆矩阵怎么求最快

    求解逆矩阵的常用三种方法_阿桑的专栏_逆矩阵怎么求最快1.待定系数法矩阵A=1,2-1,-3假设所求的逆矩阵为a,bc,d则从而可以得出方程组a+2c=1b+2d=0-a-3c=0-b-3d=1解得a=3;b=2;c=-1;d=-12.伴随矩阵求逆矩阵伴随矩阵是矩阵元素所对应的代数余子式,所构成的矩阵,转置后得到的新矩阵。我们先求出伴随矩阵A*=-3,-21,1接下来…

    2022年4月19日
    144
  • Winform屏幕截图保存C#代码

    代码如下:已在项目中实现:http://hovertree.com/h/bjaf/76q5yeli.htm

    2021年12月21日
    41
  • linux0.11_linux vim安装

    linux0.11_linux vim安装前言所有的UnixLike系统都会内建vi文书编辑器,其他的文书编辑器则不一定会存在。但是目前我们使用比较多的是vim编辑器。vim具有程序编辑的能力,可以主动的以字体颜色辨别语法的

    2022年7月30日
    5

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号