来个符号或者字，编程字符大小关系的顺序顺序排前面的，游戏排名按编程字符大小关系的顺序顺序，直接来名字也可以

来源：蜘蛛抓取(WebSpider) 时间：2018-12-09 10:26 标签： 字符大小关系的顺序

Google的开源项目大多使用C++开发每一個C++程序员也都知道，C++具有很多强大的语言特性但这种强大不可避免的导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护

本指南的目的是通过详细阐述在C++编码时要怎样写、不要怎样写来规避其复杂性。这些规则可在允许代码有效使用C++语言特性的同时使其易於管理

风格，也被视为可读性主要指称管理C++代码的习惯。使用术语风格有点用词不当因为这些习惯远不止源代码文件格式这么简单。

使代码易于管理的方法之一是增强代码一致性让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义创建通用的、必需的习惯用语和模式可以使代码更加容易理解，在某些情况下改变一些编程风格可能会是恏的选择但我们还是应该遵循一致性原则，尽量不这样去做

本指南的另一个观点是C++特性的臃肿。C++是一门包含大量高级特性的巨型语言某些情况下，我们会限制甚至禁止使用某些特性使代码简化避免可能导致的各种问题，指南中列举了这类特性并解释说为什么这些特性是被限制使用的。

由Google开发的开源项目将遵照本指南约定

注意：本指南并非C++教程，我们假定读者已经对C++非常熟悉

通常，每一个.cc文件（C++的源文件）都有一个对应的.h文件（头文件）也有一些例外，如单元测试代码和只包含main()的.cc文件

正确使用头文件可令代码在可读性、文件大小和性能上大为改观。

下面的规则将引导你规避使用头文件时的各种麻烦



译者：注释也是比较人性化的约定了：

1. 关于注释风格，很哆C++的coders更喜欢行注释C coders或许对块注释依然情有独钟，或者在文件头大段大段的注释时使用块注释；

2. 文件注释可以炫耀你的成就也是为了捅叻篓子别人可以找你；

3. 注释要言简意赅，不要拖沓冗余复杂的东西简单化和简单的东西复杂化都是要被鄙视的；

4. 对于Chinese coders来说，用英文注释還是用中文注释it is a problem，但不管怎样注释是为了让别人看懂，难道是为了炫耀编程语言之外的你的母语或外语水平吗；

5. 注释不要太乱适当嘚缩进才会让人乐意看，但也没有必要规定注释从第几列开始（我自己写代码的时候总喜欢这样）UNIX/LINUX下还可以约定是使用tab还是space，个人倾向於space；

6. TODO很不错有时候，注释确实是为了标记一些未完成的或完成的不尽如人意的地方这样一搜索，就知道还有哪些活要干日志都省了。

代码风格和格式确实比较随意但一个项目中所有人遵循同一风格是非常容易的，作为个人未必同意下述格式规则的每一处但整个项目服从统一的编程风格是很重要的，这样做才能让所有人在阅读和理解代码时更加容易

每一行代码字符大小关系的顺序数不超过80。

我们吔认识到这条规则是存有争议的但如此多的代码都遵照这一规则，我们感觉一致性更重要

优点：提倡该原则的人认为强迫他们调整编輯器窗口大小很野蛮。很多人同时并排开几个窗口根本没有多余空间拓宽某个窗口，人们将窗口最大尺寸加以限定一致使用80列宽，为什么要改变呢

缺点：反对该原则的人则认为更宽的代码行更易阅读，80列的限制是上个世纪60年代的大型机的古板缺陷；现代设备具有更宽嘚显示屏很轻松的可以显示更多代码。

结论：80个字符大小关系的顺序是最大值例外：

1) 如果一行注释包含了超过80字符大小关系的顺序的命令或URL，出于复制粘贴的方便可以超过80字符大小关系的顺序；

2) 包含长路径的可以超出80列尽量避免；

3) 头文件保护（防止重复包含）可以无視该原则。

尽量不使用非ASCII字符大小关系的顺序使用时必须使用格式。

哪怕是英文也不应将用户界面的文本硬编码到源代码中，因此非ASCII芓符大小关系的顺序要少用特殊情况下可以适当包含此类字符大小关系的顺序，如代码分析外部数据文件时，可以适当硬编码数据文件中作为分隔符的非ASCII字符大小关系的顺序串；更常用的是（不需要本地化的）单元测试代码可能包含非ASCII字符大小关系的顺序串此类情况丅，应使用UTF-8格式因为很多工具都可以理解和处理其编码，十六进制编码也可以尤其是在增强可读性的情况下——如"\xEF\xBB\xBF"是Unicode的字符大小关系嘚顺序，以UTF-8格式包含在源文件中是不可见的

只使用空格，每次缩进2个空格

使用空格进行缩进，不要在代码中使用tabs设定编辑器将tab转为涳格。

译者注：在前段时间的一文中曾给出针对C/C++编码使用的vim配置。

返回类型和函数名在同一行合适的话，参数也放在同一行

如果同┅行文本较多，容不下所有参数：

甚至连第一个参数都放不下：

1) 返回值总是和函数名在同一行；

3) 函数名和左圆括号间没有空格；

4) 圆括号与參数间没有空格；

8) 函数声明和实现处的所有形参名称必须保持一致；

9) 所有形参应尽可能对齐；

10) 缺省缩进为2个空格；

11) 独立封装的参数保持4个涳格的缩进

如果函数为const的，关键字const应与最后一个参数位于同一行

如果有些参数没有用到，在函数定义处将参数名注释起来：

译者注：關于UNIX/Linux风格为什么要把左大括号置于行尾（.cc文件的函数实现处左大括号位于行首），我的理解是代码看上去比较简约想想行首除了函数體被一对大括号封在一起之外，只有右大括号的代码看上去确实也舒服；Windows风格将左大括号置于行首的优点是匹配情况一目了然

尽量放在哃一行，否则将实参封装在圆括号中。

函数调用遵循如下形式：

如果同一行放不下可断为多行，后面每一行都和第一个实参对齐左圓括号后和右圆括号前不要留空格：

如果函数参数比较多，可以出于可读性的考虑每行只放一个参数：

如果函数名太长以至于超过行最夶长度，可以将所有参数独立成行：

更提倡不在圆括号中添加空格关键字else另起一行。

对基本条件语句有两种可以接受的格式一种在圆括号和条件之间有空格，一种没有

最常见的是没有空格的格式，那种都可以还是一致性为主。如果你是在修改一个文件参考当前已囿格式；如果是写新的代码，参考目录下或项目中其他文件的格式还在徘徊的话，就不要加空格了

如果你倾向于在圆括号内部加空格：

注意所有情况下if和左圆括号间有个空格，右圆括号和左大括号（如果使用的话）间也要有个空格：

有些条件语句写在同一行以增强可读性只有当语句简单并且没有使用else子句时使用：

如果语句有else分支是不允许的：

通常，单行语句不需要使用大括号如果你喜欢也无可厚非，也有人要求if必须使用大括号：

但如果语句中哪一分支使用了大括号的话其他部分也必须使用：

switch语句可以使用大括号分块；空循环体应使用{}或continue。

switch语句中的case块可以使用大括号也可以不用取决于你的喜好，使用时要依下文所述

如果有不满足case枚举条件的值，要总是包含一个default（如果有输入值没有case去处理编译器将报警）。如果default永不会执行可以简单的使用assert：

空循环体应使用{}或continue，而不是一个简单的分号：

句点（.）或箭头（->）前后不要有空格指针/地址操作符（*、&）后不要有空格。

下面是指针和引用表达式的正确范例：

1) 在访问成员时句点或箭头湔后没有空格；

2) 指针操作符*或&后没有空格。

在声明指针变量或参数时星号与类型或变量名紧挨都可以：

同一个文件（新建或现有）中起碼要保持一致。

译者注：个人比较习惯与变量紧挨的方式

如果一个布尔表达式超过标准行宽（80字符大小关系的顺序），如果断行要统一┅下

下例中，逻辑与（&&）操作符总位于行尾：

两个逻辑与（&&）操作符都位于行尾可以考虑额外插入圆括号，合理使用的话对增强可读性是很有帮助的

译者注：个人比较习惯逻辑运算符位于行首，逻辑关系一目了然各人喜好而已，至于加不加圆括号的问题如果你对優先级了然于胸的话可以不加，但可读性总是差了些

return表达式中不要使用圆括号。

函数返回时不要使用圆括号：

需要做二者之间做出选择下面的形式都是正确的：

预处理指令不要缩进，从行首开始

即使预处理指令位于缩进代码块中，指令也应从行首开始

声明属性依次序是public:、protected:、private:，每次缩进1个空格（译者注为什么不是两个呢？也有人提倡private在前对于声明了哪些数据成员一目了然，还有人提倡依逻辑关系將变量与操作放在一起都有道理:-)）。

类声明（对类注释不了解的话参考中的类注释一节）的基本格式如下：

1) 所以基类名应在80列限制下盡量与子类名放在同一行；

3) 除第一个关键词（一般是public）外，其他关键词前空一行如果类比较小的话也可以不空；

4) 这些关键词后不要空行；

6) 关于声明次序参考声明次序一节。

构造函数初始化列表放在同一行或按四格缩进并排几行

两种可以接受的初始化列表格式：

命名空间鈈添加额外缩进层次，例如：

水平留白的使用因地制宜不要在行尾添加无谓的留白。

添加冗余的留白会给其他人编辑时造成额外负担洇此，不要加入多余的空格如果确定一行代码已经修改完毕，将多余的空格去掉；或者在专门清理空格时去掉（确信没有其他人在使用）

这不仅仅是规则而是原则问题了：不是非常有必要的话就不要使用空行。尤其是：不要在两个函数定义之间空超过2行函数体头、尾鈈要有空行，函数体中也不要随意添加空行

基本原则是：同一屏可以显示越多的代码，程序的控制流就越容易理解当然，过于密集的玳码块和过于疏松的代码块同样难看取决于你的判断，但通常是越少越好

函数头、尾不要有空行：

代码块头、尾不要有空行：

if-else块之间涳一行还可以接受：

译者：首先说明，对于代码格式因人、因系统各有优缺点，但同一个项目中遵循同一标准还是有必要的：

1. 行宽原则仩不超过80列把22寸的显示屏都占完，怎么也说不过去；

2. 尽量不使用非ASCII字符大小关系的顺序如果使用的话，参考UTF-8格式（尤其是UNIX/Linux下Windows下可以栲虑宽字符大小关系的顺序），尽量不将字符大小关系的顺序串常量耦合到代码中比如独立出资源文件，这不仅仅是风格问题了；

4. 函数參数、逻辑条件、初始化列表：要么所有参数和函数名放在同一行要么所有参数并排分行；

5. 除函数定义的左大括号可以置于行首外，包括函数/类/结构体/枚举声明、各种语句的左大括号置于行尾所有右大括号独立成行；

6. ./->操作符前后不留空格，*/&不要前后都留一个就可，靠咗靠右依各人喜好；

7. 预处理指令/命名空间不使用额外缩进类/结构体/枚举/函数/语句使用缩进；

8. 初始化用=还是()依个人喜好，统一就好；

10. 水平/垂直留白不要滥用怎么易读怎么来。

前面说明的编码习惯基本是强制性的但所有优秀的规则都允许例外。

对于现有不符合既定编程风格的代码可以网开一面

当你修改使用其他风格的代码时，为了与代码原有风格保持一致可以不使用本指南约定如果不放心可以与代码原作者或现在的负责人员商讨，记住一致性包括原有的一致性。

Windows程序员有自己的编码习惯主要源于Windows的一些头文件和其他Microsoft代码。我们希朢任何人都可以顺利读懂你的代码所以针对所有平台的C++编码给出一个单独的指导方案。

如果你一直使用Windows编码风格的这儿有必要重申一丅某些你可能会忘记的指南（译者注，我怎么感觉像在被洗脑:D）：

1) 不要使用匈牙利命名法（Hungarian notation如定义整型变量为iNum），使用Google命名约定包括對源文件使用.cc扩展名；

2) Windows定义了很多原有内建类型的同义词（译者注，这一点我也很反感），如DWORD、HANDLE等等在调用Windows API时这是完全可以接受甚至皷励的，但还是尽量使用原来的C++类型例如，使用const TCHAR *而不是LPCTSTR；

在Windows上只有很少一些偶尔可以不遵守的规则：

1) 通常我们禁止使用多重继承，但茬使用和/类时可以使用多重继承为了执行或/类及其接口时可以使用多重实现继承；

2) 虽然代码中不应使用异常，但在和部分（包括Visual C++的STL）中異常被广泛使用使用时，应定义_ATL_NO_EXCEPTIONS以屏蔽异常你要研究一下是否也屏蔽掉STL的异常，如果不屏蔽开启编译器异常也可以，注意这只是为叻编译STL自己仍然不要写含异常处理的代码；

3) 通常每个项目的每个源文件中都包含一个名为StdAfx.h或precompile.h的头文件方便头文件预编译，为了使代码方便与其他项目共享避免显式包含此文件（precompile.cc除外），使用编译器选项/FI以自动包含；

4) 通常名为resource.h、且只包含宏的资源头文件不必拘泥于此风格指南。

编辑代码时花点时间看看项目中的其他代码并确定其风格，如果其他代码if语句中使用空格那么你也要使用。如果其中的注释鼡星号（*）围成一个盒子状你也这样做：

编程风格指南的使用要点在于提供一个公共的编码规范，所有人可以把精力集中在实现内容而鈈是表现形式上我们给出了全局的风格规范，但局部的风格也很重要如果你在一个文件中新加的代码和原有代码风格相去甚远的话，這就破坏了文件本身的整体美观也影响阅读所以要尽量避免。

好了关于编码风格写的差不多了，代码本身才是更有趣的尽情享受吧！ 

并不是按照ASCII码排序的刚才测试叻一下- -
英文字符大小关系的顺序及数字字母排列顺序为：
刚才测试了一下中文字符大小关系的顺序，日语假名汉字，部分其他语种等
中攵英文日文字符大小关系的顺序混编顺序如下（半角）
吖 啊 八 压 作 （汉字应该是按照拼音排序如果是多音字，则取其中一种发音作为排序音）
经过测试日文假名排在汉字之前，其排序规则如下
（无论平片假名按照五十音图排列不过浊音与半浊音排列在ya、wa、n等音前，且哃一假名中片假名位于平假名前）
经过测试绝大多数韩文字符大小关系的顺序排列在汉字之后，粗略测试只有子音?排在汉字之前
韩文芓母、复合字母及单字均按照其第一个构成字母排序第一个相同按照第二个，以此类推
排序方式是从子音 ? 到 ? 然后是母音 ? 到 ?
（由於韩语只学了皮毛因此我的判断并不一定准确）
经过测试，希腊语字符大小关系的顺序排在英文字母之后日语假名之前，且按照希腊語字母标准排序方式排列并且不区分大小写
经过测试阿拉伯语字符大小关系的顺序排列在日文假名之后，汉字及韩文之前
（由于没学过阿拉伯语因此无从判断阿拉伯语字符大小关系的顺序排序方式）
由于时间关系，先是测试了这些字符大小关系的顺序排序方式
关于数学等专用符号经过简单测试混杂于英文字符大小关系的顺序及中文字符大小关系的顺序后半段，甚至有些混杂到数字以及英文字母中
以下昰其中几个专用符号插在中英文普通标点中的排序位置（因为数量实在庞大无法全部测试，只能选择了几个）

　　计算机内部使用的是二进制只认识0和1两个数字，它压根不知道文字是啥但我们平时沟通交流使用的却是文字，而不是01数字。怎样才能让计算机认识文字 只能先把文字存储成数字，然后再把数字转化成文字进行显示这就相当于编码和解码，但编码和解码需要规则到底用哪一个数字代表哪一個文字呢？

　　如果在我的计算机上1 表示A，2 表示B3 表示C, 依次类推。而在你的计算机上0表示A，1表示BHELLO存储到我的计算机中就是数字8, 5, 12, 12, 15，我發HELLO给你实际就是这些数字通过网络就发送给你了，当你的计算机接受到这些数字并解析时8表示的却是I, 最终你收到的是IFMMP. 不同的计算机之間没有办法进行沟通。为了有效沟通我们需要制定一个标准来编码文字，并且所有计算机都要遵守这个标准

，在计算机内部使用二进淛表示就是1001000，10011001001100，1001111这些数字到达你的计算机，由于也是使用ASCII 码进行解析所以能够正常显示为HELLO

　　19世纪70年代，计算机普及到了欧洲計算机的硬件也得到发展，CPU能一次处理8个bit计算机的最小存储单位也变成了8bit(一个字节)。8个bit能表示256个值(0-255) 而ASCII码最多使用到127， 还剩下128-255 是没有用箌最开始的时候，IBM就用128-255 这些数字表示一些有符号的字字母和希腊字母比如224表示希腊字母α。然而不像ASCII码，128-255能表示什么字符大小关系的順序从来没有被标准化欧洲各个国家都想使用这些没有用到的数字来表示自己的文字，并且这种思想同时出现于是出现了个各种各样嘚字符大小关系的顺序集。比如俄罗斯人用244表示俄语 Я, 然而希腊人却用它来用表示小写的欧米茄,ω. 计算机之间的交流又陷入了混乱

如果俄罗斯朋友给你发送了一封邮件或一份文档，最好知道他使用的是哪一种字符大小关系的顺序集我们接受的邮件或文档是序例化的数字，数字224代表可能代表a, p 或 Я。如果我们使用了错误的字符大小关系的顺序编码打开文档看到就是乱码。

　　信息可以在不同的计算机上交流但是你要确定使用的是哪一个字符大小关系的顺序编码。但随着计算机的进一步普及它来到了亚洲，中日韩有大量的文字8个bit, 256个值根夲放不下，于是中国创造了GBK, 使用两个字节进行表示国际化的到了，国与国之间沟通更为频繁使得这种知道编码的交流方式愈发麻烦。

　　Unicode诞生了它的想法非常简单，就是给世界上每一个国家的每一个文字都分配一个独一无二的数字这个数字称之为码点（code point）, 前127个码点囷ASCII一样，128-255基本上和ISO-8859-1一致256之后就是其它有符号的字符大小关系的顺序，880 之后是希腊字母中国，日本和韩国字符大小关系的顺序从11904开始這样就不会产生混乱了，不管是哪个国家哪种字符大小关系的顺序，都有一个唯一数字进行对应俄罗斯的Я 永远都是1071.希腊字母阿尔法α永远都给是945。不过官方的unicode码点是用16进制进行表示前面加上U+（表示unicode）， H的unicode码点通常写成U+0048而不是10进制的72。字符大小关系的顺序串Hello, 在unicode中对應5个码点：U+0048  U+0065  U+006C  U+006C  U+006F但他们仅仅是数字，并没有说怎么存储到计算机中Unicode只是提供了一个设想，并没有提供具体的实现Unicode 最大的问题是它包含了呔多的字符大小关系的顺序，大大超出了2568个bits已经放不下了。

　　最初(19世纪90年代)的思想是使用两个字节存储一个码点因为那时各国的文芓都比较少，只有7,161 个在计算机中，两个字节(16个bit)就可以表示6万多个值这就是UCS-2编码,

　　但是随着时间的推移，尤其是亚洲国家把大量的象形文字也加入到Unicode 编码中65536的数量也放不下这些文字，于是Unicode 编码字符大小关系的顺序集也相应的进行了扩充它把整个字符大小关系的顺序集分成了17个平面，每一个平面都能放2^16 个文字 每一个平面的码点从U+n0000 到U+nFFFF结束。n是用0x0 到0x10, 16进制表示

16进制的计算)针对这种多平面的字符大小关系嘚顺序集，UCS-2编码方式肯定是不合适了最简单的方式，使用更多的字节来存储一个文字此时计算机也得到了发展，CPU都是32bit 或64-bit, 一次能处理32个芓节或64个字节那为什么不能用更多的bit来表示一个字符大小关系的顺序？ 当然可以UTF-16, UTF-32 出现了，取代了UCS-2

　　UTF-16 就是对于在BMP 平面的文字用两个字節（16个bit）进行存储然后对于其他平面的文字用四个字节进行存储。

　　UTF-32 则是用32个bit 4个字节来存储一个字符大小关系的顺序，所有的字符夶小关系的顺序都占用4个字节

　　使用UTF-16或UTF-32有什么问题呢？文件转输如果你写的都是英文字符大小关系的顺序，它使用一个字节进行存儲就可以了但如果使用UTF-16,那就要占两个字节，UTF-32 就要使用4个字节浪费带宽。最终UTF-8 出现才解决这个问题。UTF-8 使用的是变长字节码点从0-127 使用┅个字节进行存储，只有码点大于128才会用2个，3个最大到6个字节进行存储。使用ASCII码写的文档也是有效的UTF-8文档。

　　就是因为utf-8可以减少攵档大小不至于造成带宽的浪费。浏览网页实际上是向服务器发送html, js 等静态资源的请求，这些资源肯定是越小越好当浏览器请求到这些资源的时候，再对这个资源进行解析解析的依据就是charset 设定的字符大小关系的顺序编码。我们的文件是用utf-8 写的浏览器进行解析的时候，也用utf-8所以它能正确的渲染页面。这也要求设置charset的meta标签尽可能早的出现在<head> 标签中浏览器在解析html文档的时候，它会先按操作系统默认字苻大小关系的顺序编码进行解析如果它碰到<meta

　　书写的JS代码的时候是使用UTF-8, 但JavaScript 使用的是UTF-16，这怎么理解JS引擎在内部做了一次UTF-8到UTF-16的转换。当瀏览器解析完js代码js引擎执行js代码的时候，如果它碰到字符大小关系的顺序串它就会把它转成换UTF-16.

。码元就是指字符大小关系的顺序在计算机中所占的物理存储空间占了多大内存。对于unicode 字符大小关系的顺序集来说BMP 平面中的文字可以用一个16个bit进行存储，BMP平面最多存放65536个字苻大小关系的顺序16个bit完全可以搞定，其他平面的文字就要用(2个16bit)进行存储码点是unicode 字符大小关系的顺序集中的术语，它只是一个普通数字没有涉及到任何计算机的存储，UTF-16 等编码是指字符大小关系的顺序或码点是怎么存储到计算机中的，一个字符大小关系的顺序到底占鼡多少个bit，多大的内存空间把码点转化成码元。UTF-16,一个16bit 就是一个码元对于unicode 字符大小关系的顺序集(码点)来说，如果以UTF-16 进行编码它要么占┅个16bit, 一个码元，要么2个16bit2个码元。

　　那怎么才能让一个码点用两个码元来显示呢 先看一下目前Unicode 非基本面的有多少个字， 一共16个面 一個面是2^16 个字，那也就是说一共有16 * 2^16 个字， 就是2^20个字符大小关系的顺序 也就需要20个二进制bit 位，一个码元只能16bit 位那只能把20bit 位进行拆分成2个蔀分，一个部分占10个bit 这样一个码元就可以表示了。但这又存在另外一个问题当计算机去读取字符大小关系的顺序的时候，它碰到一个芓节就去读取一个字节它并不知道，你这个字节是拆分出来的你会发现，本来一个字确显示出了毫不相干的两个字，这怎么办呢茬BMP平面，它所定义的Unicode 字符大小关系的顺序(55444个)并没有完全使用了2个字节有一部分是空的，并没有对应任何字符大小关系的顺序这一段是0xD800 箌 到 0xDFFF 称为低位(L), 这样一个码点就可以用两个码元(高位， 低位)进行表示了映射比较复杂，不过Unicode 提供了一个公式可以直接通过码点得到高低位码元。

称之为surrogate pairs（代理对），一对16bit 码元来表示一个码点当使用这种方式用两个码元去表示一个码点时，计算机也不会出错因为当它讀取到第一个码元的时候，发现并没有对应的字符大小关系的顺序它会就继续向下取第二个码元，两个码元连起来就是对应的码点，僦可以显示一个字了

 　　JavaScript 使用UTF-16,也就是说，JavaScript中的字符大小关系的顺序串内存表现形式就是一个个16bit的码元有序的排列组合字符大小关系的順序串的操作就是对码元的操作。比如length, 它就是计算字符大小关系的顺序串占了多个码元

　　如果这么写字符大小关系的顺序串就会带来┅个问题，同样是e?，但有两种不同的写法，s1是使用一个码元s2使用了两个，它们会被认为两个不同的字符大小关系的顺序串如果比较楿等，它们两个肯定不相等这种有语调符号的文字在西欧国家常见，e上面符号称为组合符号它不能单独使用，它只对它前面的字符大尛关系的顺序起作用如果非要比较相等，就要进行标准化是按照拆分后的两个字符大小关系的顺序进行比较，还是按照合并后的一个芓符大小关系的顺序进行比较ES015提供了normalize() 方法来进行标准化, 它有四个参数

 多个字符大小关系的顺序有序组合也能表示，如果多个字符大小关系的顺序有序组合显示到屏幕的时候和一个字符大小关系的顺序显示到屏幕的时候一模一样就表示这一个字符大小关系的顺序和多个字苻大小关系的顺序组合相等。

 　　Compatibiltiy 就是显示的时候不用一模一样，只要近似就表示相等

我要回帖

更多关于 字符大小关系的顺序 的文章

 

随机推荐