如果发生外星人入侵,我们被迫在我们所有现有的计算机系统中支持他们的语言,那么UTF-8的设计是否允许它们可能包含大量字符?

(当然,我们不知道外星人是否真的有语言,他们是否或如何交流,但是为了争辩,请想象他们确实如此。)

例如,如果他们的语言包括数百万个新发现的字形,符号和/或组合字符,从理论上讲,UTF-8能否以不间断的方式扩展以包括这些新字形并仍支持所有现有软件?

感兴趣的是,字形是否远远超过了当前的大小限制,并且需要更多字节来表示单个字形。如果无法扩展UTF-8,是否证明相对于UTF-32的唯一优势仅仅是小写字符的大小?

评论

“支持他们的语言”(我的重点)...多少?我们确定语言可以细分为字符吗?语言可能基于空间关系。 -参见蒋泰德的《您的人生故事》,《您的人生故事》及其他。充其量,这只是一个X字节最大问题(脱题)。最坏的情况是投机胡说。 (不清楚您要问的内容)

@ScantRoger接受的答案可以很好地按预期回答问题。

公认的答案可以很好地告诉我们UTF-8,UTF-16和UTF-32的事实。您只需在Wikipedia上查找即可。至于“外星人入侵”,我根本看不出答案如何解决。

相关(关于堆栈溢出):对于所有通用语言,UTF-8是否足够?

Unicode不支持语言,它支持字符-用于表示书面形式含义的字形。许多人类语言没有脚本,因此Unicode无法支持。更不用说许多动物交流,但是没有书面语言。由于图示符的集合不是有限的,因此无法通过unicode支持通过插图或无文字漫画进行的交流。根据定义,我们不知道外星人如何交流,因此您的问题无法回答。如果您只是想知道unicode可以支持多少个不同的字符,您应该澄清一下:)

#1 楼

Unicode标准有很多可用空间。 Unicode代码点以“平面”和“块”组织。在17架飞机中,目前有11架尚未分配。每架飞机可容纳65,536个字符,因此实际上有50万个代码点可用于保留外语(除非我们在首次接触之前将所有表情符号都填满了更多的表情符号)。截至Unicode 8.0为止,总共仅分配了120,737个代码点(大约占总容量的10%),未分配的数量大致相同,但保留给专用,专用于应用程序的用途。总共未分配974,530个代码点。

UTF-8是Unicode的一种特定编码,目前每个代码点限制为四个八位字节(字节),这与UTF-16的限制相匹配。特别是,UTF-16仅支持17架飞机。以前,UTF-8每个代码点支持6个八位位组,并且旨在支持32768个平面。原则上可以取消此4字节的限制,但这将破坏Unicode的当前组织结构,并要求逐步淘汰UTF-16-考虑到在某些操作系统和编程中的地位,这不太可能在近期发生语言。

UTF-16仍然普遍使用的唯一原因是它是对有缺陷的UCS-2编码的扩展,该编码仅支持单个Unicode平面。否则,它会从UTF-8(非固定宽度)和UTF-32(非ASCII兼容,浪费公共数据的空间)两者中继承不受欢迎的属性,并且需要字节顺序标记来声明字节序。尽管存在这些问题,但UTF-16仍然很流行,我不太乐观这很快就会改变。希望我们的新外国人霸主会看到他们统治的障碍,并以他们的智慧将UTF-16从地球上清除。

评论


实际上,为了与UTF-16匹配,UTF-8仅限于4字节限制的一部分。具体来说,达到17/32,略大于一半。

–重复数据删除器
2015年11月24日15:19



在Windows之外,我不知道有其他操作系统在其中或该操作系统上的大多数程序都使用UTF16。 OSX程序通常为UTF8,Android程序通常为UTF8,Linux程序通常为UTF8。因此,我们所需要的只是让Windows消亡(它已经在移动空间中消失了)

–slebetman
2015年11月25日,下午3:14

除非我们在第一次接触之前就用更多表情符号填充所有内容,否则一切都将存在。表情符号是与外星人和平互动的最大威胁。我们完蛋了。

–rickster
2015年11月25日下午6:03

@slebetman不是。任何基于JVM的都使用UTF-16(Android,也不确定为什么不这么说),JavaScript使用UTF-16,并且考虑到Java和JavaScript是最受欢迎的语言,UTF-16不会随时随地不久。

–马尔科姆
15年11月25日在8:34

@Kaiserludi“大多数linux代码都将utf32用于unicode”,是的,没有。说真的,你从哪儿得到这个主意的?甚至没有wfopen syscall或其他任何东西,完全是UTF8。甚至是地狱的Python和Java(由于历史原因都将字符串定义为UTF-16),除非有必要,否则都不会将字符串存储为UTF-16。.大内存优势和性能不受影响(尽管有额外的代码来处理转换-内存昂贵,CPU便宜)。 Android也是如此-NDK的JString是UTF8,主要是因为Google工程师并不疯狂。

– Voo
15年11月25日在22:19

#2 楼

如果实际上要扩展UTF-8,我们应该查看它可以代表的绝对最大值。 UTF-8的结构如下:

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx


(从RFC中无耻地复制。)我们看到,第一个字节始终控制着组成字节的后续字节。当前字符。

如果将其扩展为允许最多8个字节,则会得到其他非Unicode表示形式。

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx


计算最大可能值这种技术允许我们使用的表示法

或以10为底:
最大表示量为4,468,982,745,216。

因此,如果这40亿个字符(或您所希望的兆数)足以表示外语,那么我很肯定我们可以用最少的精力,扩展当前的UTF-8以取悦我们的新外星霸主;-)

评论


当前,UTF-8仅限于0x10FFFF之前的代码点-但这仅是为了与UTF-16兼容。如果需要扩展它,则毫无疑问如何使用代码点扩展它直到0x7FFFFFFF(即2³¹-1)。但除此之外,我看到了相互矛盾的定义。我看到的一个定义是111111xx作为可能的第一个字节,后跟五个扩展字节,最多2³²码点。但这仅与您提到的前2³¹个代码点的定义兼容。

–卡巴斯德
15年11月24日在16:49

是的,Wikipedia说了一些有关UTF-16的信息,实际上它们的意思是Unicode或ISO 10646(取决于上下文)。实际上,从RFC 3629开始,除了U + 10FFFF(或UTF-8字节中的F4 8F BF BF)之外,未定义UTF-8。因此,我在此提及的所有内容都是纯粹的推测。当然,有人可能会想到其他扩展,其中第一个高字节指示后续的其他结构(并希望不会破坏进程中的自同步)。不过,我尝试完成字节方案,使其尽可能接近真实的UTF-8。

– Boldewyn
15年11月24日在19:47

那是4万亿,而不是4千万。

– ypnypn
2015年11月25日,0:56

紧接着的字节数不必总是比第一个字节的前导字节数小1。 Perl实际上支持(自2000年以来)UTF-8的内部变体,其中5、6和7字节形式与此答案相同,但是FF引入了一个13字节代码单元,能够存储72位。任何超过2 ^ 36的东西都统一非常昂贵,但是它允许先编码64位int,然后再编码一些。

–霍布斯
2015年11月25日17:37

#3 楼

RFC3629将UTF-8限制为每个字符最多四个字节,最大值为0x10FFFF,最多允许1,112,064个代码点。显然,可以删除此限制并扩展标准,但这将证明对达到该限制的现有代码进行了重大更改。

从数据文件的角度来看,这并不是一个重大更改,因为该标准的工作原理是,如果设置了每个字节的最高有效位(MSB),则下一个字节是编码的一部分。即使在RFC3629之前,该标准也被限制为31位,而未设置第四个字节的MSB。

将标准扩展到0x10FFFF以后将破坏UTF-8与UTF-16的部分数据兼容性。

评论


因此,从理论上讲,数据将向后兼容,但是代码与标准的修改本身不是兼容的吗?

– Qix-蒙尼卡(MS)被盗
15年11月24日在12:28

@Qix,这是一个正确的观点。任何现有的UTF-8文件自然都可以与(例如)最多6个字节兼容,以容纳数百万个代码点,但是许多旨在处理UTF-8的现有库可能不会处理该扩展名。

– David Arno
15年11月24日在12:30

UTF-16会致命地损坏。它本身只能支持不超过0x10FFFF的代码点。

– gnasher729
15年11月24日在15:06

@ gnasher729:并不是您想的那么大的问题。 Pre-Unicode通过移位值(日语为Shift JIS)解决了这一问题。他们只是将保留/未使用的字符(0xFFFD?)标记为“移位字符”,从而将编码转换为更扩展的形式。大概是UTF32。

–鸭鸭
2015年11月25日17:45



#4 楼

实际上,如果2个Unicode代码点代码将字符组合在一起,它们就代表无限多个字形。例如,比较Unicode编码韩文韩文字母的两种方式:Hangul音节和Hangul。尊宝Hangul Syllabels中的字符is是单个代码点C6C3,而Hangul Jamo中的字符is是三个代码点110B(ㅇ)116E(ㅜ)11B9(ㅅ)。显然,使用组合字符占用的代码点少得多,但编写效率却较低,因为编写每个字符需要更多的字节。目前可以使用UTF-8或UTF-16编码的代码点的数量。世俗的语言。如果他们不介意,例如用100k个字符组合来表示数百万个字符中的每个字符,那就没有问题;另一方面,如果被迫使用比地球更多的字节,使他们感觉像是二等公民,那么我们可能会遇到一些冲突(与我们对UTF-8的观察一样)。

评论


仅当外语中的字符实际上由一组更有限的字素组成时,才是这种情况。事实并非如此。

–雅克B
15年11月25日在12:57

据我所知,并没有要求组合字符需要与单个字素相关。 Unicode FAQ对此没有提及,但我的印象是,对于布局引擎来说,支持不是字素序列的梳理序列并不困难,因为无论哪种情况都将需要预先组合的字形。

–欧文
2015年11月25日14:33



这些外星人可以活多久?在童年时期可以学习多少个不可分解为字素的字符?甚至在gzip之后,预先分解的Hangul是否仍保留其优于分解的Hangul的字节优势?

–达米安·耶里克(Damian Yerrick)
16年6月30日在15:28

#5 楼

编辑:问题现在说“成千上万的新字符”。这样很容易回答:

不。 Utf-8是Unicode编码。 Unicode具有一个代码空间,该代码空间允许1,114,112个不同的代码点,并且当前未分配的代码点不到一百万个。因此,不可能在Unicode中支持数百万个新字符。根据定义,没有Unicode编码可以支持比Unicode定义更多的字符。 (当然,您可以通过进一步编码级别来作弊-毕竟,任何类型的数据都只能用两个字符表示。)


回答原始问题:

Unicode不支持此类语言,它支持字符-用于以书面形式表示语言的符号。

并非所有人类语言都有书面表示形式,因此并非所有人类语言都可以支持Unicode。此外,许多动物交流但没有书面语言。例如,鲸鱼的交流形式足够复杂,可以调用一种语言,但没有任何书面形式(也不能被现有的语音符号捕获)。因此,即使不是世界上所有语言也都可以使用Unicode。

更糟的是像蜜蜂的语言。它不仅没有书面形式,而且不能以书面形式有意义地表示。语言是一种舞蹈,基本上指向一个方向,但依赖于太阳的当前位置。因此,舞蹈仅在执行特定地点和时间具有信息价值。符号或文本表示形式必须包含蜜蜂语言当前无法表达的信息(位置,太阳的位置)。

甚至书面或符号形式的交流也可能无法用Unicode表示。例如,插图或无字漫画不受Unicode支持,因为字形的集合不是有限的。您会注意到在国际环境中(例如机场)有很多图片交流,因此,太空旅行的外星人种族已经演变成使用图片语言是不可想象的。

即使外星人种族如果使用的语言的书写系统具有有限的符号集,则该系统可能无法支持Unicode。 Unicode期望书写是符号的线性序列。音乐符号是不能完全用Unicode表示的书写系统的一个示例,因为含义是在符号选择以及垂直和水平位置中编码的。 (Unicode确实支持单个音乐符号,但不能对乐谱进行编码。)使用复音音乐(不罕见)或具有类似复杂性的交流渠道进行交流的外星人种族,其书写系统可能看起来像管弦乐乐谱,并且Unicode不支持此功能。

但是为了便于讨论,我们假设所有语言,甚至是外来语言,都可以表示为从有限集合中选择的线性符号序列。 Unicode足够大以应对外来入侵吗? Unicode当前有不到一百万个未分配的代码点。根据最全面的中文词典,中文包含十万个字符(Unicode目前不支持所有字符作为不同的字符)。因此,只有十种中文复杂的语言会用完所有Unicode。在地球上,我们有数百种不同的书写系统,但是幸运的是,大多数书写系统都是字母的而不是表意的,因此包含少量字符。如果所有书面语言都使用像中国一样的表意文字,那么Unicode甚至还不够大。字母表的使用源自语音,语音仅使用有限数量的音素,但对于人类生理学而言尤其如此。因此,即使只有一个只有十二个表意文字书写系统的外星球,也可能超出Unicode可以支持的范围。现在考虑该外星人是否已经入侵地球之前的其他行星,并将其书写系统包含在必须支持的字符集中。

当前编码的扩展或修改或引入新的编码将无法解决此问题,因为限制是Unicode支持的代码点数量。很可能不是。

评论


你缺乏想象力。舞蹈编舞者具有丰富的语言和术语,可以用来描述和教导舞台演员要表演的舞蹈。如果我们要了解蜜蜂正在交流的内容,那么我们绝对可以为它设计一个书面术语。毕竟,我们今天的大多数书面语言都是声音的编码。编码运动与编码声音没有什么不同。

–whatsisname
15年11月24日在19:43

这个答案的某些部分很好,但是说“不仅没有书面形式,而且不可能以书面形式表示”,这是完全错误的。传达信息的任何事物都可以简化为比特,而分解为比特的任何内容都可以转换为几乎任何您喜欢的字符流。

–机器人机器人
2015年11月24日在21:17



@StevenBurnap是的,但是Unicode不仅仅是一系列位。这是解释这些位的一种方法,相当严格。是的,可以将Unicode字符集扩展为代表从图像到CNC指令的任何内容,但这将是一个非常不同的生物。

–欧文
15年11月24日在21:23

请记住,unicode符号描述的(在大多数语言中)是气压变化中的模式,而对于大多数语言而言,它实际上在匹配这些模式方面做得相当差。

–机器人机器人
15年11月24日在21:28

因此,您的意思是“不可能在向左15度的角度飞行45秒,然后在向右10度的角度飞行10秒”这句话?当然,这需要将当时的太阳位置作为背景。

–机器人机器人
2015年11月25日,下午3:26