【发布时间】:2014-11-02 13:26:47
【问题描述】:
我正在移植一个不支持 Unicode 的应用程序。我选择 UCS4 作为内部表示,以通过重用现有代码库来简化字符串处理,因为我感兴趣的应用程序不执行与字素或可视集群管理相关的任务,并且可能仅在代码点上运行,因此现在可以负担得起。
现有应用程序到处都使用char *,因此在此过程中,我建立了几个类型来替换所有这些情况下使用的char *,并且不再明确使用char *:
-
“纯字节,可能包含零并带有长度”。我将这些描述为
typedef uint8_t byte_t并用作byte_t *foo。它是char *的直接替代品,兼容接受void *和char *的函数。 -
“Unicode 字符串的大部分以 null 结尾的字符” — 这些是
typedef uint32_t ucs4char_t。我通过strnlen_ucs4(const ucs4char_t *s, size_t maxlen)等自己的函数处理此类字符,这些函数重新实现了原始函数的逻辑,但对整个 UCS4 代码点而不是 8 位字符进行操作。 - 最后,“作为 UTF-8 编码字符串一部分的字节,不代表特定字符/代码点,暗示以零结尾,用作不透明缓冲区”——我遇到了麻烦用这个命名。在功能上它与
byte_t相同,但我想强调这些类型有不同的用途,不应该在没有明确翻译的情况下混合使用(尽管在这种特殊情况下翻译是无操作的)。这些单元出现在 Unicode 世界和 OS/network/fs/whatever 之间的“边界”函数中,它们需要将 UCS4 强制转换为 OS 提供的不透明零终止字符串(以getenv()/putenv()为例) .我将 UCS4 编码为 UTF8,因此我可以使用strlen或strncmp,它们不必关心 Unicode 和比较内容的含义。
但是我不知道这么小的单位有没有正式的名字,所以现在我叫它utf8byte_t,感觉用词不当。
那么,有什么名字可以用吗?如果没有,也许有更好的方法来解决我所描述的问题?
【问题讨论】:
-
rfc 3629 只是将其称为八位字节。
-
@nos,这可能是有道理的,但命名为 octet 几乎与 byte 一样通用。但是,Freenode 用户 @ihatehex 建议将它们命名为 tribble,这听起来不错,而且很吸引人:)
-
我只会打电话给前者
char。后者在 UTF-8 的 Plan 9 实现中称为Rune,是原始的。其他操作系统的端口是available under a liberal license。 -
types ending with
"_t"被某些编译器保留 - 可能想要使用不同的方案。 -
您要求为模糊描述的事物提供正式名称,这种方式混淆了一般 Unicode 概念和特定编程语言。官方到底是谁what?此外,因此,整个问题都是题外话,因为它是关于术语的,而不是一个实用的、可回答的程序问题。
标签: c unicode utf-8 naming-conventions naming