这是一个创建于 2590 天前的主题，其中的信息可能已经有所发展或是发生改变。
unicode 有 17 个 code plane，总共规划了 1,114,112 个 code point，而 UTF-24 可以表示 16,777,216 个 code point，可以定长编码，每个文字三字节，还比 UTF-32 的编码少了一字节的存储空间，但是为什么没听说过这种编码
 |
1
thekll 2017-10-22 00:49:26 +08:00
也没有 3 个字长的地址阿
|
 |
2
asiufasd OP @thekll 3 字节不是 24 位么，另外 UTF-8 是变长编码，落在 U+0800 ~ U+FFFF 区间的文字也是会表示为三个字节的编码吧，还是我理解或者说的不对？
|
 |
3
hjc4869 2017-10-22 01:34:08 +08:00
因为 UTF-16 更实用
|
|
4
hjc4869 2017-10-22 01:39:23 +08:00  1
为什么不用 UTF-24 ？
https://stackoverflow.com/questions/10143836/why-is-there-no-utf-24 为什么如今 UTF-16 被大规模使用？ http://unicode.org/notes/tn12/ |
 |
5
jlsk 2017-10-22 01:48:08 +08:00 3
非常不利于计算机处理，RGB24 就有过教训了
所有寄存器都是 2 的 n 次方大小 读取 3 个字节只能读 4 个再把多的那个置 0 慢了一倍不止 还有内存对齐问题，非 4n 地址会额外消耗时间片 |
 |
6
noli 2017-10-22 01:55:29 +08:00
|
|
7
thekll 2017-10-22 02:20:33 +08:00
我上面的回答有点答非所问。
首先，unicode 是一整套的字符编码规范，按现有 codespace 定义，已经可以容纳足够多的字符，目前看来还没有必要再扩展。 其次不要把 UTF 和 unicode 搞混了，UTF-8,UTF-16,UTF-32 是 unicode 的具体编码实现。并不直接表示 codepoint。UTF-8 编码可以是 1 ～ 4 字节，UTF-16 是 2 或者 4 字节，UTF-32 则是 4 字节。 你说的 UTF-24 大概是想增加码空间，正如上面所说没必要，实际好多空间都还没用。 |
|
8
jlsk 2017-10-22 02:26:45 +08:00 1
@noli 不懂就不要乱说，你光传输和存储永远也不显示？
显示的话不就是要处理吗？ 什么“处理前几乎都是转成 4 字节”，谁处理呀？你拿手处理啊！ 不 TM 都是 CPU 去处理？ 你懂汇编吗？寄存器是啥你知道吗？ 一切计算的前提就是寄存器，不存在转完了再进寄存器那一说 多上点学不要信口开河！ |
|
10
noli 2017-10-22 03:12:00 +08:00
@jlsk 太久没人怼我以至于我都快忘了怎么怼不懂装懂的人才能获得最大快感了。
我说的尽寄存器是指，你在某编程语言里面操作字符串中的某字符。 而不是你瞎喷什么转码不使用寄存器。 况且，转码还真的可以不使用通用寄存器，用 AVX 之类的直接就可以大量直接转。 你说你装什么懂行呢？ 显示根本就跟寄存器无关。 多读书吧。 拉黑不谢。 |
|
11
jlsk 2017-10-22 03:37:03 +08:00
@noli
各位看客你们说现在的傻逼是不是太多了点？ 一个明显不懂底层原理的人，被打脸后死鸭子嘴硬 没兴趣回复它了，爱咋咋地吧 你 Block 我没有任何意义，辩论是给其他人看的，谁有理谁有舆论支持 谁先 Block 等于谁先露怯 我看看看客们支持谁，支持我的请打 call |
 |
12
msg7086 2017-10-22 05:32:59 +08:00
|
|
13
msg7086 2017-10-22 05:35:33 +08:00
@noli 顺便提一句，AVX 2 从内存中载入也是要边界对齐的，否则影响性能。
虽然实际并不会有多大的数据量导致这么显著的性能差异就是了。 |
 |
15
wwqgtxx 2017-10-22 08:53:18 +08:00
@noli 从内部实现来说，就算你存在一条指令可以不用显示的把数据拷贝到寄存器，他内部是实现依然是要把数据从内存拷贝过去，只不过 CPU 内部帮你完成了这个操作没给你展现出来而已，所以再怎么地，寄存器这个地方你都绕不过去
另外就是内存对齐的问题，你看看 gcc\llvm 之内的编译的代码，很多 class/struct 的内容就算不是 4 或者 8 的倍数他也会强行填充到这个大小，难道人家写编译器的人都是智障么 |
 |
16
zhidian 2017-10-22 09:46:24 +08:00
power of 2
|
|
17
noli 2017-10-22 12:02:49 +08:00
@wwqgtxx
“转码还真的可以不使用通用寄存器，用 AVX 之类的直接就可以大量直接转” 你是没看到我说什么，还是没看懂什么叫通用寄存器？还是不知道 AVX 指令使用的是非通用寄存器？ gcc\llvm 要处理的数据都是要放到通用寄存器里面的，当然转成内存对齐的咯。 |
|
18
noli 2017-10-22 12:05:46 +08:00
@dishonest 那要不我回你一句“多事”“没有帮助”，然后再和你说，你敢把我拉黑就是小孩子气？
“最烦那些劝我大度的人，你知道我经历了什么，你死不死”——郭德纲 走好不送，同拉黑，最烦那些没什么料还劝人大度的。 |
|
19
noli 2017-10-22 12:24:09 +08:00
@msg7086
用 AVX 处理字符编码其实我还真没做过，甚至都没见过。 仔细想想的话，对于变长编码类型来说，什么 AVX 乃至并行算法其实都是不可行的。 因为这些编码格式本来就只考虑流式处理，而不是并行处理。 字符流和用于快速地把数据 copy 到显存、什么的图像编码流，并不一样。 不过即使是图像领域，不也还有 JPEG、PNG 等等的压缩格式嘛，显然其数据单元就不是内存对齐的。 离题了。 我最初的出发点只是想说，设计用于传输和存储的编码格式，是不需要考虑寄存器大小的。 让我意外的是，显然有很多人并不知道什么场合才需要考虑内存对齐。 |
 |
20
pagxir 2017-10-22 13:36:42 +08:00 via Android
从你们的回复，就能感知到你们水平的排行了。
|
|
21
hjc4869 2017-10-22 13:47:25 +08:00
@noli 并非不可行，UTF-8 和 UTF-16 互转现在大家都是 SIMD 了，随便 Google 一下就能查得到实现。
|
|
22
msg7086 2017-10-22 14:25:51 +08:00
@noli UTF-8 最初是为了向后兼容 7-bit，可以在单字节文字的世界里无缝切换，方便推广。
就说 Windows 上强推 UTF-16 来着，结果搞得各种兼容性问题，宽字符窄字符要死要活的。 而且 UTF-8 本身可扩展，以前最长可以用到 6 字节，不像 UTF-16 这样定长然后不够用了就 GG。 流式处理还是怎么处理倒不是最主要的。 毕竟这玩意不想做视频做图像，动不动就上亿的数据量。 文字，撑死也就那么点数据，性能并不重要。 |
|
23
noli 2017-10-22 14:37:32 +08:00 via iPhone
@hjc4869 我粗略看了一下 AVX 的指令集的一些指令功能，感觉做不出来，不知道怎么做，想不到居然真有实现了的，长见识了。有没有关键字提供一下？
|
|
24
hjc4869 2017-10-22 15:00:37 +08:00 1
@noli https://woboq.com/blog/utf-8-processing-using-simd.html 这个也不是什么新鲜事了。
|
 |
26
pinews 2017-10-22 20:50:30 +08:00
如果计算机发源于中国，编码优先考虑汉字的话，楼主说的情况极有可能发生的，说不定还能成为全球唯一编码呢。。
|
 |
29
jetyang 2017-10-23 09:23:07 +08:00
我觉得大家关注点偏了。unicode7.0 标准里 17 个面现在用了多少？是不是要大规模的去扩充 codepoint 空间？变长编码和定长编码相比有什么好处？
UTF-8 的编码思路并非只用在字符编码上，一些压缩算法也是一样的思路，楼主加油 |
 |
30
iceheart 2017-10-23 19:29:08 +08:00 via Android
UTF-8 （ 8-bit Unicode Transformation Format ）
UTF-16 （ 16-bit Unicode Transformation Format ） 先把概念搞清楚再讨论问题。 当然，这个问题的概念搞清楚了，问题也就没必要讨论了。 |
Select Language