如何设计8位编码?

我不会设计8位编码。太蠢了。有超过255个人类字符。

但是,如果我可以对ANSI字符集进行重新制作,我将删除所有现在已经失效的控制字符,而不是从1到31的范围。其余的在我看来都差不多。您还必须考虑字符串的排序方式(比如以下划线开头的字符串应该在以数字字符开头的字符串之前排序)。

也就是说,将0设为字符串结束符的基本原理可能是0表示 false 在一个条件中,您可以通过检查字符是否为非零来遍历字符串,如 if(*string) 而不是 if(*string != 0xFF) .

还有,社区维基。

如果我是白手起家,我会有以下计划:-

x00 -- x10  -- Control characters such as end of file, end of line, end of string.

x10 -- x30  -- Alphabetic characters using the following pattern:-
    x10  -> A Upper case A.
    x11  -> a Lower case A.
    x12  -> a with local accent e.g a acute.
    x13  -> a with second local accent e.g. a grave
    .....................
x40 -- x50  -- Local "extra" characters
    Thing like the Scandanavian AE or Danish /O which are regarded as separate 
    characters with thier own position in the collating scheme.

x50 -- x60 -- Punctuation .,:; etc.
x70 -- x80 -- Other special character {}/\ etc.

xF0 -- xFF -- 0 to 9

这个方案有很多优点(没有一个值得我们付出植入和转换的痛苦!).

首先,isnumeric isalpha等可以用简单的位掩码实现。

其次,排序将自动进入一个自然的序列。

艾尔, 酒精, 可爱的, 坎特格雷夫, 啤酒 Øl

然而,将一个复杂的多元文化世界融入一个8位的方案是不可能的,任何提出的方案都会以某种方式受到损害。真正的解决方案是倾听UNICODE联盟中的优秀人员的意见,他们使用16个机器人(或更多)简单地覆盖了所有的基础.

如果不考虑向后兼容性,则无法实际设计字符集。

若要放弃向后兼容性,必须具有 令人惊叹的 原因,而向后兼容实际上意味着 ASCII兼容性 . 在当今这个相互关联的世界中,这样一个原因将是非常难以表述的,在这个世界中,有这么多字符集(无论是否使用加权)维护它。这将限制您使用高度专用的嵌入式环境。

让我们想象一个这样的环境:微波炉。它必须显示数字和字母,如“爆米花”,“1盎司”,“1.2盎司”(爆米花袋大小),等等。它绝对不会与任何其他设备通信。它不需要任何控制代码(想象一下一个单行LCD显示器:即使换行也没有意义)。我们甚至可以说,你只在讲英语的地区销售这种微波炉,选择不同的用户界面语言是完全没有问题的。

即使如此,保持ASCII兼容也有很好的好处,但缺点也很小。例如,您可以在软件模拟硬件中测试生产代码,并且仍然使用常用的调试器。

扔掉许多你从未使用过的字母,只使用大写(或小写)、数字和最小标点符号(空格、句点)。这样,在最小方案中所需的比特数将少于5位。如果你开始抛出字母表中的单个字母,可能会少一些,但如果只命中4个字母,就很难保持在4位-4位=16和16-10个数字-2个标点符号=4的范围内。

但这并不像你所使用的普通硬件,在今天的现实中,你会注意到40位(8个5位字符)和64位(8个8位字符)之间的区别,这是假设你甚至可以找到 商品五金 你就可以这样刮胡子了。

255不是7位系统上的有效字符值,或者可能位于9位计算机上本机字符集的中间。想象一下本地的“e”是你的字符串终止符。

所以这是历史性的: “能在烤面包机芯片上运行吗” 是C语言的一个基本(如果经过改进的话)设计原则。类型宽度在C语言中定义得很弱,因此实现可以使用“本机”元素——char是“最小的单独可寻址元素”,对于所有机器来说,这不是也不是8位的。0被广泛使用。

剩下的问题是:完全主观的,取决于优化的目的。它只有在非常严格定义的环境中才有意义,这些环境的资源非常少。例如,在德语中,有不同的“电话簿”和“词典”排序规则。你选哪一个?

根据你的例子,我会把数字放在第一位,然后是字母(对于dec/hex字符串更容易)。我会把大小写字母分开-但是,像ascii一样,只差一点点。与其把它塞满有趣的角色,我宁愿留下一些未定义的字符,这样这些技巧的一些工作更好。除非预先定义排序算法,否则优化排序是没有意义的。

你用现有的字符集看到什么问题,你希望用一个新的字符集来解决?

只需要节省效率 c < 52 而不是 c > M && c < N 充其量是边缘的,因为这很少是一个瓶颈。此外,isalpha()和isalnum()是特定于区域设置的,需要处理重音字符,因此在除了为其设计字符集的区域设置之外的其他区域设置中,您根本没有任何节省。

你的第二个想法 aàáâãbcdeèéêëfgh... 根据特定的语言环境对单个字符进行排序很好,但在某些字符与排序等价的语言中,对多字符字符串进行排序没有帮助。例如,在德国词典中,UllaUT对于排序目的被忽略(ABC & lt;bd & lt;abe),因此您仍然不能执行字符值的简单字典顺序。