据我了解，UTF-8 是 ASCII 的超集，因此包括不用于表示可打印字符的控制字符。
我的问题是：是否有任何字节（256 个不同的字节）未被 UTF-8 编码使用？
我想知道你是否可以转换/编码UTF-8 文本转二进制。
这是我的思考过程：
我不知道 UTF-8 文本编码是如何工作的，也不知道它如何使用这么多字符（只知道它对非 ASCII (Latin-1??) 中的字符使用多个字节），但我知道 ASCII 文本在 UTF 中是有效的-8 所以控制字符（字节0-30） http://en.wikipedia.org/wiki/UTF-8#Codepage_layoutUTF-8 编码的使用方式没有不同，但它们同时不用于显示字符，对吗？
因此，在 256 个不同字节中，仅使用了约 230 个字节。对于 1000（二进制）长的 Unicode 文本，只有 1000^230 个不同的文本？正确的？
如果这是真的，你可以convert将其转换为小于 1000 字节的二进制数据。
沃尔夫拉姆阿尔法: 1000 字节的 unicode（假设 unicode 只使用 256 个不同字节中的 230 个）--> 496 字节 http://www.wolframalpha.com/input/?i=pow%28pow%281000%2C230%29%2C1%2F256%29
是的，可以设计出比 UTF-8 更节省空间的编码，但您必须权衡利弊。
例如，如果您的主要目标是（例如）ISO-8859-1，您可以将字符代码 0xA0-0xFF 映射到自身，并且仅使用 0x80-0x9F 来选择扩展映射，有点像 UTF-8 使用（几乎）所有 0x80-0xFF 来编码可以表示所有 Unicode > 0x80 的序列。当大部分文本不使用 0x80-0x9F 或 0x0100-0x1EFFFFFFFF 范围内的字符时，您将获得显着的优势，但如果情况并非如此，则会相应地损失。
或者您可能要求用户保留一个状态变量，该变量告诉您当前选择的字符范围，并使流中的每个字节充当该范围的索引。这有很大的缺点，但很久以前就是这样做的（例如 ISO-2022）。
Ken Thompson 和 Rob Pike 著名干预之前的原始 UTF-8 草案可能也比最终规范更节省空间，但他们引入的更改具有一些非常有吸引力的属性，用（我认为）一些空间效率换取了上下文的缺乏歧义。
我强烈建议您阅读关于 UTF-8 的维基百科文章 http://en.wikipedia.org/wiki/UTF-8了解设计需求——尽管您可能需要预留一个小时或更长时间来遵循脚注等，但只需几分钟即可掌握规范。（汤普森轶事目前是脚注#7。）
总而言之，除非您正在从事太空旅行或某些类似的效率密集型应用程序，否则失去 UTF-8 兼容性可能不值得您已经花费的时间，您应该立即停止。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
