中国DOS联盟论坛

中国DOS联盟

-- 联合DOS 推动DOS 发展DOS --
联盟域名:www.cn-dos.net 论坛域名:www.cn-dos.net/forum
游客 | 登录 | 注册 | 会员 | 搜索 | 中国DOS联盟
中国DOS联盟论坛
现在时间是 2026-08-19 07:35
47,814 主题排行 / 349,908 发帖 / 今日 1 篇 / 48,259 会员排行
DOS疑难解答 & 问题讨论 (解答室) » [讨论]DOS下处理UNCODE文本的最大处理极限是什么?
可打印版本  1,007 / 12
第1楼 nipo 发表于 2008-05-11 12:02
中级用户 发帖 106 积分 228
[讨论]DOS下处理UNCODE文本的最大处理极限是什么?
用TYPE等方法可以读取,但无论如何不能保存。

既然能读取,就应该可以进行中间环节的处理。

是否DOS处理UNCODE文本的障碍主要在于不能保存为这种格式呢?
第2楼 nipo 发表于 2008-05-11 12:22
中级用户 发帖 106 积分 228
第3楼 netwinxp 发表于 2008-05-11 12:59
高级用户 发帖 366 积分 741
问题在于Unicode一个字符恒定两个字节,原来的ASCII字符被多加了个ASC(00),并且还有大头和大尾之分,而这些附加特性刚好涉及到批处理的一些特殊字符,所以还需要附加个把Unicode转成ASCII和GB2312的小程序才好解决。
第4楼 nipo 发表于 2008-05-11 13:38
中级用户 发帖 106 积分 228
谢谢3楼朋友的解答,话不多,说得很透彻。

偶正在研究这个问题。如果能弄懂它,比走其它道路要快捷得多。

现在好象有点眉目了,还要看最后结果。

http://www.cn-dos.net/forum/viewthread.php?tid=24079&fpage=1&highlight=unicode
第5楼 netwinxp 发表于 2008-05-11 15:27
高级用户 发帖 366 积分 741
有一个很大的问题,GB2312与UniCode没有明显的映射规则,需要依靠一张表来完成转换。甚至更大的问题是UniCode里面有很多字符GB2312没有。
第6楼 slore 发表于 2008-05-11 15:55
铂金会员 发帖 2,478 积分 5,212
VBS用流对象……
第7楼 netwinxp 发表于 2008-05-11 19:07
高级用户 发帖 366 积分 741
Originally posted by slore at 2008-5-11 15:55:
VBS用流对象……

VBS最终还是调用系统的转换功能,windows把unicode转成gb码也同样是用查表法。
第8楼 nipo 发表于 2008-05-11 21:55
中级用户 发帖 106 积分 228
TYPE命令可以读取UNCODE文本。试了一些文本,没发现有异常的显示。这是什么原理?

可否利用TYPE来进行中间的过渡处理?
第9楼 netwinxp 发表于 2008-05-12 11:31
高级用户 发帖 366 积分 741
是的,CMD的TYPE会把UNICODE的文本文件转成GBK输出(DOS的肯定不行),但GBK和GB2312是不同的,而DOS下通常使用的是GB2312(部分GBK字符无法显示)。

[ Last edited by netwinxp on 2008-5-12 at 11:36 AM ]
第10楼 nipo 发表于 2008-05-17 23:13
中级用户 发帖 106 积分 228
正在研究码表问题,看来不是个简单的事情。

[ Last edited by nipo on 2008-5-17 at 11:15 PM ]
第11楼 nipo 发表于 2008-05-17 23:15
中级用户 发帖 106 积分 228
又发现用find命令也可以导出UNICODE文本,并且可以很方便地选择性导出,例如:
find /v "TINTLPHR.EXE" a.txt>>b.txt

a.txt(UNICODE文本):

TINTLGD_.IMD
TINTLPHR.EXE
TINTSETP.EXE
TMIGRATE.DLL

且记录下来备考。
第12楼 netwinxp 发表于 2008-05-18 15:03
高级用户 发帖 366 积分 741
这些都只有在CMD才有效...
第13楼 nipo 发表于 2008-05-19 02:41
中级用户 发帖 106 积分 228
看得出来,netwinxp朋友对编码问题有很深的研究。钦佩!
[ 联系联盟系统管理团队 - 中国DOS联盟 - 标准版 ]
Sponsored by ifanr Inc | © 2001–2023