从ASCII 到UNICODE 再到UTF8

从ASCII到Unicode再到UTF-8,字符编码经历了多次变革以适应全球语言需求。早期ASCII仅支持英语等少数语言,随后Unicode通过增加编码空间实现了多语言支持。为解决Unicode带来的存储开销问题,提出了UTF-8编码方案,其兼容ASCII且高效存储多语言文本。

 

从ASCII 到UNICODE 再到UTF8

 

字符编码,UTF7,ASCII,UNICODE

从 ASCII 到 UTF-8 : 大话编码
话说当年,老美搞出了ASCII编码,用8个bit表示一个字符,
解决了计算机存储人类语言的问题.

要说当时那帮人真是有点小家子气,只顾解决英语,数字和一些简单符号
的存储问题,压根就没想过中文啊,拉丁文啊,藏文啊啥的怎么存储的问题.

随着计算机越来越普及,这个问题也就越来越尖锐了,总不能让全世界人民
都使用英语吧?于是,有这么两个组织,一个曰ISO,一个曰unicode组织,就开始
想办法了...

unicode想的办法比较简单,不是1个byte不够嘛?咱用两个byte存,大概够了吧?
这就是unicode 1.0 的实现.

要说人家ISO就是大气,也可能决策者们没过过几十K内存的苦日子,
大笔一挥,不就是1个byte不够吗?用4个byte够了吧?再用个几百年也够了吧?
这就是 ucs-4 的雏型.

随着一些稀奇古怪的文字需要并入unicode,unicode的决策者有点冒汗了,
咱有这么多稀奇古怪的字母呢? 要不再加点, 用 2byte + 4 bit 来存吧..
那4bit做为头,这下就又能表示很多奇怪的文字了....
这就是 unicode 2.0 的雏型

现在有了两套风格迥异的编码方式, 到底该用那个呢?
于是 unicode 组织 和 ISO 组织 达成了协议,就是你中有我,我中有你,
ucs-4 尽管有 32 bit 编码空间,只用 20 bit ,和 unicode 保持统一,unicode不作修改
这就是 ucs-4 和 unicode 2.0 了,狼狈为奸的结果 :)

后来在 2000 年 8 月 ,unicode 的工作人员为了显得自己不是吃白食的,
就小小修改了一下 unicode 2.0 的文档,做为unicode 3.0 发布了.没加一个新字符啊!!!!!!
(实际上, 有大约12种当前语言 和 数十种古代语言,如雅玛语,古希腊B类线形文字,
古波斯碶型文字还没有得到支持)


至此,编码方案算是统一了,接下来,咬牙切齿骂街的就变成程序员们了.
程序员的愤怒是有道理的,比如输入一篇100字的英文文章,如果用ASCII
编码,仅需要 100 byte ,而如果出现了哪怕一个古怪的字符而不得不用ucs-4 ,
就需要 400 byte ! 这对早期的程序员来说简直是灾难...就算对带宽有限得今天,
这也是个很重要得问题..

于是IETF推出了 UTF- 8 和 UTF-16 两种解决方案 (utf32用的太少,忽略)

utf 8 实际上是最聪明的编码方式,简单说,规则有三条
(1) ASCII 编码不变, 用 1 个byte 表示
(2) 一个 byte 不够 ,就用两个 byte
(3)两个还不够,就用三个byte,什么?还不够?
不可能,3个byte已经超过unicode 的表示极限了..你是外星人吗?

它带来了如下两大好处:
(1)平台无关性,windows下用UTF-8写的小说,别人在unix下照样能看..
(2)有标记位,一个字读不出来,不影响其他字.

utf 16 则是给笨一点的程序员准备的,简单说,规则有两条
(1) unicode 1.0 中的字符完全照搬 ,用2个byte
(2) unicode 2.0 继续照搬,   需要用 20 bit 表示的字符,用 2byte + 4bit 处理.

这下带来的可不是一点两点的坏处,
(1)由于是变长,且不按计算机字长(8bit)来变长,所以用utf16编码的
东东的解码就和CPU,操作系统的处理方式相关了,不利于交流
(2)一些本来具有特殊意义的字符无法被计算机正常处理
(3)以上两条就可以判它死刑了...其他害处不一一列举,

但是utf16最省空间倒是真的.毕竟是紧凑编码的,没有大段大段的000000000出现....

实际上,IETF比较希望UTF-8成为事实标准(RFC2279),
而UTF-16,也就是卖ISO和unicode个面子,实现一下而已(RFC2781)


而现实中,由于UTF-8的优异性能,得到了广泛的认可和使用.
比如现在大红大紫的XML,在XML1.0第二版规范中明确指出,
当用户没有指定XML文档的 encoding 属性的时候,自动使用UTF8

转自http://www.lupaworld.com/441/viewspace-354.html。

备注:

  今天在用BeautifulSoup+ Mysql的时候.发现了许多问题,BeautifulSoup内部编码为UNICODE,而MYSQL读出的数据是UTF8,字符串在比较的时候,会出错,因此首先要把UTF8的数据DECODE成UNICODE。

  在用MYSQL的escape_string函数时,需要将数据编码为UTF8,所以,为了方便,在整个程序最开始,就指定STR的编码:

reload(sys)

sys.setdefaultencoding("utf8")

这样,所有的字符串就都是UTF8了,不用再担心ASCII了。

 

 

以上内容太转自王河云 博客,存档备用

STM32电机库无感代注释无传感器版本龙贝格观测三电阻双AD采样前馈控制弱磁控制斜坡启动内容概要:本文档为一份关于STM32电机控制的无传感器版本代注释资源,聚焦于龙贝格观测器在永磁同步电机(PMSM)无感控制中的应用。内容涵盖三电阻双通道AD采样技术、前馈控制、弱磁控制及斜坡启动等关键控制策略的实现方法,旨在通过详细的代解析帮助开发者深入理解基于STM32平台的高性能电机控制算法设计与工程实现。文档适用于从事电机控制开发的技术人员,重点解析了无位置传感器控制下的转子初始定位、速度估算与系统稳定性优化等问题。; 适合人群:具备一定嵌入式开发基础,熟悉STM32平台及电机控制原理的工程师或研究人员,尤其适合从事无感FOC开发的中高级技术人员。; 使用场景及目标:①掌握龙贝格观测器在PMSM无感控制中的建模与实现;②理解三电阻采样与双AD同步采集的硬件匹配与软件处理机制;③实现前馈补偿提升动态响应、弱磁扩速控制策略以及平稳斜坡启动过程;④为实际项目中调试和优化无感FOC系统提供代参考和技术支持; 阅读建议:建议结合STM32电机控制硬件平台进行代对照阅读与实验验证,重点关注观测器设计、电流采样校准、PI参数整定及各控制模块之间的协同逻辑,建议配合示波器进行信号观测以加深对控制时序与性能表现的理解。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值