TimothyQiu's Blog

keep it simple stupid

再见 ShadowSocks

分类:闲扯

再过十几天,就是世界反法西斯战争胜利纪念日了。今天,ShadowSocks 在 GitHub 的相关仓库被勒令删除代码,停止官方维护,V2EX 和知乎上相关的内容也都被删了,可见这是一个同样值得纪念的日子。

阅读剩余部分...

那么 C 语言也可能有类了哟

分类:闲扯

今天看到 C 语言委员会的提案 N1875,顿时有种「卧槽」的感觉,因为它的标题是:Adding classes to C。这要是通过了,那可真就变成名副其实的 C with Classes 了呀~

纵观提案全文,主要从 C++ 中吸收「类」的概念和用法,但是没有虚函数之类的东西。如果算上单独的「访问限制符」、「单一继承」提案,一个 C 语言的类,很可能类似于:

class Car: public Vehicle
{
public:  // 这是单独的另一个提案引入的
    // 构造函数
    initCar() {
        initVehicle();  // 需要显式调用父类构造函数
        countWheels_ = 4;
    }

    // 构造函数
    initCar(int speedMax, int countWheels) {
        initVehicle(speedMax);  // 需要显式调用父类构造函数
        countWheels_ = countWheels;
    }

    // 析构函数
    deleteCar() {
        deleteVehicle();  // 需要显式调用父类析构函数
    }

    int getWheelsCount() const {    // 也有 const 哟
        return this->countWheels_;  // 也有 this 指针
    }

private:
    int countWheels_;
};

使用时,构造写法有点奇怪,也没说构造失败会怎样,析构也需要手动显式调用:

Car car;  // 相当于 initCar()
Car tank.initCar(80, 16);

tank.deleteCar();  // 析构函数需要显式调用
car.deleteCar();

从目前的样子看,这样的「类」更类似于语法糖。当然,这只是个提案而已,会不会最终被批准,还得拭目以待。

以上。

字符串之惑

分类:技术,闲扯

C 语言中的字符串

抽象数据类型

C 语言贴近机器模型,所以并不提供字符串数据类型。但是,字符串却在 C 语言中作为 ADT 存在着:使用字符指针代表字符串,同时提供了 string.h 作为字符串的操作库,而在实际存储时则使用字符数组。

虽说单引号引起的字符是该字符对应的一个整型常量,但是 'A' 和 65 没有任何关系。因为 C 语言并没有要求每个实现都用 ASCII 字符集作为执行字符集。

事实上,C 语言标准要求每个 C 语言实现都要定义两个字符集:代码字符集、执行字符集。每个字符集又都由基础字符和扩展字符构成。扩展字符可有可无,完全由该实现所支持的区域设置决定;基础字符只划定了字符,字符对应的码位留由实现决定。

字符与 char 类型

字符集顾名思义就是字符的集合,字符集除了划定所包含的字符外,还将其所包含的字符按照一定顺序编号,这样的编号称作码位。著名的 ASCII 参照已有电报报文设计,分别用数字 0 到 127 作为英文大小写字母、阿拉伯数字、标点符号等的码位。由于出现早、使用广,后辈字符集、字符编码几乎都与之兼容为荣。

然而 ASCII 本身并不完美,尽管名字叫「美国信息交换标准代码」,但是却连英语中的一些诸如 naïve、café、élite 的外来词都无法表示,欧洲各国那些稀奇古怪的字母就更别提了。所幸,我们很快来到了一个字节 8 位的年代,char 能够容纳 0 到 255 一共 256 个值,于是各国纷纷物尽其用,将一个字节中 ASCII 并没有用到的 128 到 255 对应为自己国家所需要用到字符。这些五花八门的对应规则便是后来的代码页(code page),同样的值可以在不同的代码页中表示不同的字符。

到目前为止,char 类型还算是名副其实的字符类型。然而,东亚文化圈广泛使用的汉字成千上万,少说也需要上千个码位,一个字节所能提供的这区区 256 个码位实在是杯水车薪。

计算机科学里的任何问题都可以通过增加一个中间层来解决。

既然码位不得不超过 255,一个字节放不下,那么将以前的「码位→字节」变成「码位→编码→字节序列」如何?

举个栗子:Unicode 字符集中,字符「汉」的码位是 27721(十六进制 6C49),一个字节显然容不下,我们可以通过 UTF-8 编码将其变成字节序列。

  1. 通过字符集找到对应码位:汉→ U+6C49
  2. 根据 UTF-8 编码规则,介于 U+0800U+FFFF 之间的码位需要按照 1110xxxx 10xxxxxx 10xxxxxx 的形式编码为三个字节;
  3. 6C49 的二进制形式是 0110 1100 0100 1001,代入上面的模板得到 11100110 10110001 10001001
  4. 得到最终的字节序列 E6 B1 89

看上去不错,但这样一来,char 这个「字符」类型就有点名不副实了:一个 char 可能只是一个字符的一部分,只有两个或者更多的 char 拼起来才能够表示一个字符。更为麻烦的是,相关的标准库也变得不再可靠了:类似 strlen() 这种 too simple, sometimes naive 的方法顿时从返回字符串的字符数降级成了返回字符串的字节数。

printf("%zu\n", strlen("\xE6\xB1\x89"));  // 输出 3;但实际上只有一个字:汉

多字节字符串

为了解决 strlen() 的这种尴尬,C 语言中引入了「多字节字符串」(multibyte string)的概念,一个字符可以对应多个字节;而原先的字符串则对应称为「字节字符串」(byte string),一个字符只能对应一个字节。

char const *multibyteString = "Hello 世界";  // 和普通字符串没什么区别

多字节字符串依旧是 char *,所以这两者的区别其实只是抽象概念上的,何况严格来说,字节字符串也是一种特殊的多字节字符串。

不同的编码每个字符占用的字节数可能不同,即便是同一种编码,不同的字符也可能占用不同的字节数。所以多字节字符串面临的主要问题便是「下一个字符到底占几个字节」。C 语言引入了 mblen() 函数来回答这个问题:

int mblen(char const *s, size_t n);

其中 s 是一个多字节字符串,而 n 表示至多检查多少个字节;这个函数会根据当前区域设置(Locale)的 LC_CTYPE 分类中所指定的编码来解析这个多字节字符串,返回该字符串的字一个字符占几个字节。

char const *multibyte= "\xE6\xB1\x89"; // 「汉」的 UTF-8 编码
printf("%d\n", mblen(multibyte , 5));  // 输出 -1;因为默认区域设置为 C,无法识别这样的序列。
setlocale(LC_CTYPE, "en_US.UTF-8");    // 非 Windows 平台用,Windows 平台不支持 UTF-8 的区域设置 
printf("%d\n", mblen(multibyte, 5));   // 输出 3;因为当前区域设置为 UTF-8 编码。

宽字符 wchar_t

多字节字符串的引入终于算是「一定程度上解决了问题」,但这种做法实在繁琐。于是,C 语言同时引入了宽字符类型 wchar_t 和配套支持库 wchar.h,试图一劳永逸地解决这个问题。

wchar_t const *wideString = L"Hello World";  // 使用前缀 L

char 的一个字节不同,wchar_t 类型本身可以占多个字节,保证永远与字符一一对应,省下了编码的步骤。如此就可以通过 wchar.h 中提供的 wcslen() 函数正确计算 wchar_t * 字符串中的字符数了。

多字节字符串和宽字符串的转换

mblen() 类似,C 语言提供了两组共四个函数,根据当前的区域设置进行多字节字符(串)和宽字符(串)的转换。

误区

看到这里,你是否想过这个能够保证与字符一一对应的 wchar_t 类型到底需要占几个字节呢?没错,不一定占多少,但总之至少一个字节就对了!

事实上,关于 wchar_t 的准确要求是:能够容纳下所支持的区域设置中,最大的扩展字符集中的每一个码位。

an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales.

也就是说,如果有一个只支持 ASCII 字符集的奇葩的 C 语言实现存在,那么在这个实现下,wchar_t 完全可以只占 8 位。

如此,我们经常听到的「宽字符和 Unicode 有关」的说法也就不攻自破了。

C11 中引入的定长字符类型

时过境迁,转眼到了 2011 年。正如 C99 中在 stdint.h 中加入了 uint32_t 之类的定长整数类型一样,C11 也引入了两种定长字符类型以满足 Unicode 的需要:

同时,继 string.hwchar.h 后,又进入了 uchar.h 作为这两种字符类型的支持库。

char16_t *utf16String = u"Hello UTF-16";  // 使用前缀 u
char32_t *utf32String = U"Hello UTF-32";  // 使用前缀 U

C++ 中的字符串

C++ 极尽所能兼容 C 语言,陆续支持了和 C 语言相同的那些 charwchar_tchar16_tchar32_t 类型,这里就不再重复了。

至于 std::string,用 C++ 不可能没听说过,它封装了常用的字符串操作。但你是否知道 std::wstring 的存在呢?

如果有心,你会发现 std::string 实际上是对 std::basic_string<T> 模板的特化,形式类似于:

typedef std::basic_string<char>    std::string;
typedef std::basic_string<wchar_t> std::wstring;

至于 C++11 中,由于 char16_tchar32_t 的引入,也对应增加了 std::u16stringstd::u32string 的特化版本。

std::basic_string::data() 在 C++11 中的改变

std::basic_string<T> 其实只是对 T 字符数组的封装,如果需要使用 C 风格的字符串 T *,可以通过 c_str() 方法获取。

而如果说 c_str() 方法表示「获取该类对应的 C 字符串表示」的语义,那么 data() 方法则表示「获取该类实际保存的数据」的语义。

在 C++11 之前,通过 data() 方法获取的 T * 并不保证 NUL 结尾,即仅保证 [data(), data() + size()) 有效。而自 C++11 起,data() 变为保证 NUL 结尾,与 c_str() 的行为完全相同。

Windows API 中的字符串类型

不得不说,Windows 的各种大写的自定义类型实在丑陋得令人发指。经常不由得让人发出「好好起名字会死么?」的感叹。

#define CHAR    char
#define LPSTR   char *
#define LPCSTR  char const *

#define WCHAR   wchar_t
#define LPWSTR  wchar_t *
#define LPCWSTR wchar_t const *

当然,微软如此做法自然有其历史原因,我对所谓的「向前兼容」表示非常无奈。不过话说回来,除了 Windows API 如此大张旗鼓地使用 wchar_t,其余地方真不怎么能见到宽字符的身影。现代 Windows 内部使用 UTF-16,所以 wchar_t 能够保证是 16 位的。

Windows API 中所有与字符串相关的函数、数据结构等,都存在 ANSI 和 Unicode 两个版本,可以通过宏 UNICODE 来切换。比如一个普通的 MessageBox() 函数,实际定义是这样的:

int MessageBoxW(HWND hWnd, LPCWSTR text, LPCWSTR caption, UINT type);  // 宽字符串版本
int MessageBoxA(HWND hWnd, LPCSTR  text, LPCSTR  caption, UINT type);  // 多字节字符串版本

#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

字符类型也是类似,使用 TCHAR 作为一个通用的字符名字。字符常量则使用 TEXT() 宏来定义。

#ifdef UNICODE
#define TCHAR    WCHAR
#define TEXT(s)  L ## s
#else
#define TCHAR    CHAR
#define TEXT(s)  s
#endif

如果你用的是 Visual C++,这个 UNICODE 宏通常并不需要手动设置,而是作为工程属性的一员出现的。

p.s. 不要被这个宏的名字骗了,还记得之前我们说过的 wchar_t 和 Unicode 一点关系都没有吗?可以这么理解:wchar_t 只在 Windows API 中表示 UTF-16 数据。

宽窄字符串的转换

Windows 平台也可以用之前提到的四个函数转换 char 字符串和 wchar_t 字符串。但 Windows 本身提供的 API 似乎更有效率:

再次吐槽 M$ 这蛋疼的命名,命名是转换字符串,起名字起得跟转换单个字符一样。

BSTR

BSTR 可以解释为 Basic String 或者 Binary String,是 Windows 下用于 COM、自动化的字符串类型。定义为:

typedef OLECHAR *BSTR;

OLECHAR 是 Windows 的历史遗留,类似于根据宏 OLE2ANSI 转换的 TCHAR,但 OLE2ANSI 是 16 位时代的产物,于是 Win32 环境下,OLECHAR 永远是 WCHAR,也就是 wchar_t

尽管如此,BSTR 并不能等同于 OLECHAR *,因为它们的内存布局不同:BSTR 在它自身前拥有一个四个字节的前缀、以双 NUL 结尾。其中,前缀用于描述字符串内容所占的字节数,它本身所指向的是字符串内容而非长度。

-4          0           2           4           6           8          10        
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|     6     |     H     |     i     |     !     |    NUL    |    NUL    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            ↑
            bString

这一点,从用于创建 BSTR 的接口 SysAllocString() 便可以看出:

BSTR SysAllocString(OLECHAR const *psz);

倘若 BSTROLECHAR * 相同,那么岂不变成了鸡生蛋、蛋生鸡的问题?

虎头蛇尾

呃……前面讲 C 语言字符串的时候似乎还是觉得挺有说头,足足规划了一个星期之久,但后面似乎越来越不知道该讲什么,留待日后积累到新的东西再完善吧~

以上。

无锡求职有感

分类:闲扯

回到无锡一年了,能让人感觉有归属感的工作始终没有找到。因为这一年间换了两份工作,所以在面试时经常被质疑人品;尽管我也尽力解释,但还是感觉不吐个槽迟早会憋出心理疾病。

阅读剩余部分...

字符编码

分类:技术,闲扯

我们平时所说的「文本」基本上都是在说「电脑屏幕上的字符」,但是小学生都知道「计算机只懂 0101」,那么电脑究竟是怎么处理三千世界中如此纷繁复杂的文字的呢?

阅读剩余部分...