Torch-RNN运行过程中的坑 [2]（Lua的string sub函数，读取中文失败，乱码？）

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

0、踩坑背景

仍然是torch-rnn/LanguageModel.lua文件中的一些问题，仍然是这个狗血的LM:encode_string函数：

function LM:encode_string(s)
local encoded = torch.LongTensor(#s)
for i = , #s do
local token = s:sub(i, i)
local idx = self.token_to_idx[token]
assert(idx ~= nil, 'Got invalid idx')
encoded[i] = idx
end
return encoded
end

上篇文章Torch-RNN运行过程中的坑 [1]（读取Lua非空table，size为0）就在这部分测试table是不是空，填了个坑。

在填坑过程中，发现for...in pair table打印出的字典是没有问题的，但是上述encode_string函数的token竟然是乱码，每次从字典table中命中不了，每次返回的都是nil。

查了console编码，是没有问题的（UTF-8）。这是咋回事哩？

1、Lua中的string sub函数切分中文

我们捋一下整个工程，

第一步使用preprocess.py对文本文件转为json和hdf5文件，值得一提的是，json中使用Unicode存储字典文件；

第二步train.lua中对json和hdf5文件进行训练；

第三步sample.lua中对checkpoint和start_text进行抽样。

由于是对start_text进行character拆分时乱码，我们肯定首先对encode_string函数中的s:sub(i, i)函数进行debug。

这个sub函数首先在lua console中看看它到底返回的是啥：

> s1='a1b2c3'> print(s1:sub(,))
a --lua中从1开始计数，和java substring和python slice不同的是，start/end index它都包含
> print(s1:sub(,))
a1
> print(s1:sub(,))
b2c3> print(s1:sub(,))
b2c3 --lua还是比较智能，越界也没有报错，比java更脚本化一些
> print(s1:sub(,))
a1b2c3 > print(s1:sub(-,))
--脚本语言都有的负数下标

大概有个了解，就是java中的substring嘛，有些细节不一样。真的是这样吗？见下：

> s2='1a新华'
> print(s2:sub(,))
1a --前俩字母，正常
> print(s2:sub(,))
1a --WTF？这就尴尬了，我的汉字呢
> print(s2:sub(,))
1a --？？？
> print(s2:sub(,))
1a新 --？？？一个“新”字占了3个字节
> print(s2:sub(,))
新
> print(s2:sub(,))
新
> print(s2:sub(,))
新
> print(s2:sub(,))
新华 --？？？“华”字也是占了三个字节
> print(s2:sub(,))
新华
> print(string.len(s2))
--这。。。正常length 4的是8？

这“1a新华”四个字的length Lua给我输出个8，让我这个java选手情何以堪。。。。

好奇害死猫，尝试在python console下，也输出的是8，看来此处必有蹊跷。嗯。

2、各种字符编码的区别与联系？

一个汉字占了3个字符，学过计组的同学醒醒了，当年老师敲黑板的重点就是这个。。。

这里首先抛出ruanyf十年前写的一篇的浅显易懂的文章《字符编码笔记：ASCII，Unicode和UTF-8》。太通俗易懂了，我这里简要搬运下。。。

总结一下考点：

首先，ASCII码是1byte，8bit，最多可以表示2^8=256种字符，表示英文字符绰绰有余。

但是，以中文为代表的各国优秀博大精深语言（文中说汉字有10W+），渐渐走进了国际化道路，当年定制ASCII码的同志们发现1byte根本表示不了这么多字符。

于是，我国1980年推出了简体中文GB2312（1995年推出的GBK的前身），两个字节byte表示一个汉字。

再后来，1990年，各国都开发了各自的编码，这时候一个伟大的联盟组织、非营利机构统一码联盟承担了Unicode（万国码、国际码、统一码、单一码）的标准制定，该机构致力于让Unicode方案替换既有的字符编码方案。每个国家的字符都有对应的编码区间，终于实现了同一个世界，同一套编码。。。

但是Unicode还是有些小瑕疵，没有大量推广使用，这时候UTF-8左右Unicode的一种实现方式，闪亮登场。

文中还有一些大小端、BIG-5、UTF-8 BOM方面的考点，感兴趣的同学可以点链接。

3、有点跑题，咱们的问题怎么解决，切分中文string乱码？

如果单纯的string全都是中文，那还好办了，直接三个三个切分就成，如果混合字符串呢？例如“1a新华”这样的。

这时候就要对编码区间进行判断了。

function LM:encode_string(s)
local encoded = torch.LongTensor(#s)
local i =
-- cause 中文在UTF8中存储占位3个字节，而英文仍然是1个字节[ascii]
for token in s.gmatch(s, "[%z\1-\127\194-\244][\128-\191]*") do
local idx = self.token_to_idx[token]
assert(idx ~= nil, 'Got invalid idx')
encoded[i] = idx
i = i+
end
return encoded
end

按照博文lua 含中文的字符串处理--分离字符、计算字符数、截取指定长度中对regex的解释是：

--[[
UTF8的编码规则：
1. 字符的第一个字节范围： 0x00—0x7F(0-127),或者 0xC2—0xF4(194-244); UTF8 是兼容 ascii 的，所以 0~127 就和 ascii 完全一致
2. 0xC0, 0xC1,0xF5—0xFF(192, 193 和 245-255)不会出现在UTF8编码中
3. 0x80—0xBF(128-191)只会出现在第二个及随后的编码中(针对多字节编码，如汉字)
]]

这样就不会出现问题了~