zrui
新手上路
新手上路
阅读:6705回复:14

U+9FB4 - U+9FBB 这8个字在 GB18030 -> Unicode 转换时是不是错了

楼主#
更多 发布于:2017-03-28 22:21
这8个字分别是:龴、龵、龶、龷、龸、龹、龺、龻。
当码表以 GB18030 编码保存时,打这几个字会变成:(U+E81E)、(U+E826)、(U+E82B)、(U+E82C)、(U+E832)、(U+E843)、(U+E854)、 (U+E864)。虽然长得差不多,但后者是专用字符,并非标准,不应使用。(况且“宋体”中, U+9FB5 的字形和 U+E826 的字形并不一样。)
使用 UTF-8 编码则不存在此问题。是不是内置的 GB18030 -> Unicode 映射错了?
在用户码表不能采用 UTF-8 编码的情况下,要把 U+9FB4 - U+9FBB 这些字符放进用户码表是不是无解?
沙发#
发布于:2017-03-28 22:24
你用的什么操作系统?win版调用的是操作系统的转换接口。
zrui
新手上路
新手上路
板凳#
发布于:2017-03-28 22:39
我用的 Windows 10。
是系统问题的话那也没办法了。libiconv 转换的是对的。
地板#
发布于:2017-03-29 10:00
测了一下xp下没这个问题,网页版和linux表现符合预期,手上没有win10,暂时无法测试。你先检查一下你码表中的这几个字的编码是否就已经有问题了。
4楼#
发布于:2017-03-29 13:08
win10上测试的结果和xp上一样,表现正常,9fb4不会变成e81e
5楼#
发布于:2017-03-29 13:48
u+9fb4对应的gb编码应该是282359037
u+e81e对应的gb编码应该是fe59

很怀疑你码表中的编码就已经是fe59了
zrui
新手上路
新手上路
6楼#
发布于:2017-03-29 15:15
你说的对。我的码表里的确是 FE59。但:
1. 只有 Windows 把 U+9FB4 编码为 82359037。其他系统中,U+9FB4 的 GB18030 编码都是 FE59。
2. 参考 http://www.fmddlmyy.cn/text24.html。按这篇文章的意思,Windows是对的。
zrui
新手上路
新手上路
7楼#
发布于:2017-03-29 15:38
又试了一下,主要问题是 libiconv 会 U+9FB4 <-> FE59,影响了很多软件。
Windows 和(Linux 下的 Python)都是 U+9FB4 <-> 82359037,U+E81E <-> FE59。

我因为用了 vim,它可能用了 libiconv,保存时 U+9FB4 -> FE59,然后小小调用 Windows 的转换,FE59 -> U+E81E。

小小在 Linux 上调用什么做编码转换?同样的码表文件在 Linux 上就是 FE59 -> U+9FB4。

我觉得最好能有个全局选项把默认编码设成 UTF-8 吧,现在操作系统的接口都是 Unicode 的,用 GB18030 + 转换 的办法理论上没什么问题但总是觉得不方便。
8楼#
发布于:2017-03-29 20:34
zrui:又试了一下,主要问题是 libiconv 会 U+9FB4 <-> FE59,影响了很多软件。
Windows 和(Linux 下的 Python)都是 U+9FB4 <-> 82359037,U+E81E <-> FE59。

我因...
回到原帖
linux版的编码转换是自己开发的,不存在问题。windows提供的调用也是对的。我自己开发的版本可能更好点,gb私有区的汉字有非私有区的unicode时,就不转到unicode的私有编码上。
vim的问题可能是你设置了文件编码为gbk而不是gb18030造成的。
9楼#
发布于:2017-03-29 20:40
除了上面楼主说的那 8 个字符(实际上一共有 14 个),
在 Windows 里是严格按 GB18030 规范,和 GBK 一样,继续映射到 Unicode 的私用区,
而在 libiconv 里,是和其他几十个有俩 Unicode 编码的字符一样,优先使用了非私用区的编码,
这个冲突点之外,小小输入法好像还有一个问题?

貌似小小用 UTF-8 格式的码表,在非 Windows 环境下,打不出 Unicode 私用区编码的字符。
在码表里,不管是私用区的编码,还是后来收录的非私用区的编码,
在小小内部的 GB18030 编码里,都会被映射到非私用区对应的那个 GB 编码上,被输出出来。
也就是说你在 Linux、Android 上用 UTF-8 的码表可能打不出 U+E81E 这些字符。
可以看成 Unicode 私用区的那个字符丢失了,被替换成了对应的非私用区的字符。

---

GB18030 是大陆推荐的规范,编码空间够大,很多软件也都支持了,
但不管怎样,也是不如国际规范 Unicode 获得的支持更广泛。
平时接触的各种东西也是用 UTF-8 的比较多。
GB18030 在功能上确实一点不差,在大陆常用字范围内用起来也挺爽,
但我和楼主有同感,在有些场合下,觉得还是不如 UTF-8 方便。

为了所谓的「更通用性」,就要在小小这边的主码表坚持使用 UTF-8,
因为不能用码表优化功能(会变成 GB18030),(不然也不想用,不同内容分段摆(非纯按编码排序)会乱掉。)
也就不能用添删词、调序、用户词库的功能。
这意味着想添删改词、调序时,全部要打开码表文件手动编辑。
因为分词库不支持 UTF-8,所以也不能用。

总之现在采用的是这套方案。
上一页
游客

返回顶部