今天帮一个朋友看了一下Oracle中处理用户自定义字的存储问题。

我的测试是利用windows自带的TrueType造字程序进行的，自己随便写了个字，字的代码为AAA1，然后将其与所有的字体文件进行关联。为了可以方便的输入，与全拼输入法进行了关联。

然后这个字就可以在我的机器上正确显示了。

其实Oracle数据库在这里起的作用只是一个存储的作用，显示问题是客户端程序完成的。

即使TELNET登陆到其他数据库服务器，执行select chr(43681) from dual,也可以正确的显示这个字符。而其他的机器，即使访问我的数据库也无法显示这个字。

突然想到，这种方式也可以作为一种客户端本身的加密方式。只有设置了造字字体的客户端可以正确的显示，而对于其他的客户端，甚至是服务器本身，所有的数据都是没有任何意义的。

上面的测试使用了ChineseGBK字符集，如果换成Unicode字符集，则无法在sqlplus中正常显示。怀疑问题可能是两点造成的，一是sqlplus并不支持Unicode的显示，二是Unicode到AL16UTF16的转换有问题。

这个情况，最好采用RAW/BLOB类型替代VARCHAR2/CLOB类型。保证二进制数据的正确存储，而将数据的展示完全交给应用程序。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-69163/，如需转载，请注明出处，否则将追究法律责任。