[求助]：ll_j 請進，頁碼越搞越糊塗

柔柔

如果，臺灣過來一張圖，上面寫上“中國”，它的頁碼是ANSI_950，我打開它，用chineset.shx字體，圖上應該能正常顯示“中國”，在文字編輯框上顯示“ \M+2A4A4\M+2B0EA ”。

打开图纸后，我用简体写上“中国”，用gbcbig.shx字体，则也能显示（当然的事），文字编辑框上显示“ 中国”。保存文件，这时的页码应该是 ANSI_936 。

把这张图发到台湾，打開文件，结果如何呢？
我认为应该是：图面上“中国”、“中國”都显示，文字编辑框上“ 中国”显示成 “\M+2D6D0\M+2B9FA ”，而“中國”就显示成“中國”。
对不对呢？？

另外，WORD的简繁转换究竟转了什么？原来我不认为它是内码转换，但。。。？？？

我帖子裏簡繁混打，説明問題還有。*-*3 *-*3 *-*3

ll_j

一般说来，文字编辑框上“ 中国”对方应该显示成 “\M+5D6D0\M+5B9FA ”。
大多数情况下，Acad能自动识别图形的代码页，就是说，台湾传来的图纸中“中國”是可以被识别的，当选用合适的字体后在图面可以显示，有时不能识别，就解释成Unicode，显示的就是“乱码”，形式如“\U+00xx”。这在打开低版本图形文件时也会出现，就是常见的“乱码”文件。
有时Windows与Acad一起“自作聪明”，会将代码页解释成“Dos437”，显示为“\U+25xx”的形式，个人认为这是Windows代码页机制的缘故，看看Windows“命令行提示符”默认值设定就知道，说实在的，研究代码页只是为了Acad使用，没有深入，不知中文Windows支持Dos437到底起什么作用，但可以肯定，我们的一些乱码，以及Windows2000+不能显示Dos状态下的汉字与此有关。
没有繁体中文系统，不知在繁体中文系统中使用“宋体”（GBK内码）能否显示台湾的汉字，但是在简体系统中，有些情况下，用来显示繁体的“mingliu”（细明体，Big5内码？）与“宋体”是可以兼容的（http://xdcad.net/forum/showthread.php?s=&threadid=14991），这是否说明GBK内码已经涵盖了GB与Big5？（如果有兴趣，龙龙仔斑竹倒可以帮点忙）。如果是这样，Word转换简繁的功能转换代码页也是正常的，转换后也不必换字体，可以直接显示。
以上是一些个人体会，可能不正确，供参考。

柔柔

谢谢ll_j !
慧眼！把我的 \M+2D6D0\M+2B9FA  错误挑出来了，嘻嘻～～～，这个错误是我有意犯的：）
\M+2A4A4\M+2B0EA 与 ANSI_950 对应，所以就显示“中國”， \M+5D6D0\M+5B9FA  与ANSI_936 对应，所以就显示“中国”。可是，有的人很喜欢用页码转换程序，结果呢？繁体字没转换好，简体字体成了\M+2xxxx（显示倒不成问题）。

言归正传，由此得出几个结论，你看对否。
1，ACAD上的文字，其内码不随打开的系统而变
2，页码不同，不影响字体显示，所以“繁体图纸上显示乱码”的说法不明确。
3，输入和打开的页码不同，图上显示与实际字符永远没法相等
4，WORD的简繁转换倒真转了，我帖子里的繁体字是选择输入法上的繁体字符，假的（南极星输入法倒是真的）。
5，所谓“繁体字乱码”大多是非真的繁体，我怀疑都是页码转换程序惹的祸。

这样，实质性的问题来了：
1，在ACAD上没法把繁体（big5）转为简体（GB），至少用Lsp无法编程，对吗？

2，由繁体字图纸产生乱码的一个很大的可能是用页码转换程序把\M+2xxxx改成\M+5xxxx，结果既不能显示繁体，又没有对应相应简体字符。解决的方法应该是用页码转换程序把它们再转回去，对吗？

3，如果是假的繁体，也就是在文字编辑框内能显示繁体汉字的那种（怎么产生的我一直没弄明白），可以通过dxf-->Word简繁转换-->简体，同理，我们完全可以把简体转成真正的繁体，但是，却没有办法把真正的繁体转换成简体，因为尽管在图上能显示繁体，但它的数据却是\M+2xxxx。对吗？ 那么，用什么软件可以达到这种转换呢？

不好意思，提了那么多问题，麻烦ll_j 了。*-*4 *-*4 *-*4

加一个：哈哈～～～
关于乱码产生的原因，你曾介绍过，好像是R14打开R12、R13的图引起的，不错，那段时间这种乱码图纸很多。问题是我自己从没遇到过，都是别人的图纸，也就没花时间研究。现在大家都用高版本了，我电脑内只有2004、2005，按理不会再有这个问题了吧，呵呵～～～我能用高版本制造出这种乱码（下次给你制造个让你翻译翻译），所以成因似乎有待研究。

ll_j

我的看法：
[B]1，ACAD上的文字，其内码不随打开的系统而变[/B]
完全正确。前面所说的因Acad不能识别代码页而出现乱码的除外，在Acad不能识别代码页时，字符将以单字节形式被解释成Unicode代码，有些代码在我们的系统中不能显示，或出现“多一对应”的重码，可以视为内码改变。
[B]2，页码不同，不影响字体显示，所以“繁体图纸上显示乱码”的说法不明确。[/B]
基本正确。早期版本的Acad是不支持双字节的，所谓的代码页也只是在各种西文平台之间转换，所以我们早期使用Acad时都忽视了一个系统变量：Dwgcodepage，当Acad进入双字节平台使用时，这个变量变得重要，于是Autodesk公司将此变量变为“只读”，这样就使得一些一起代码页不正确的图形在高版本中无法识别，不仅是繁体字在简体系统上识别问题，同样的简体字在简体系统上仍不能识别。因而，可以认为，一般情况下，只要选择合适的字体，繁体字显示不是问题，但特殊情况下可能是乱码。
[B]3，输入和打开的页码不同，图上显示与实际字符永远没法相等[/B]
这是操作系统及软件的制作者们在考虑的问题，就如同IE安装适当的字体就可以显示多种内码一样，以后也许会解决。
[B]4，WORD的简繁转换倒真转了，我帖子里的繁体字是选择输入法上的繁体字符，假的（南极星输入法倒是真的）。[/B]
紫光拼音的繁体输入是基于GBK的，可以认为是假的，南极星的输入法及南极星中文平台是针对各种系统平台的，应该是从内核识别的，所以是真的。
[B]5，所谓“繁体字乱码”大多是非真的繁体，我怀疑都是页码转换程序惹的祸。[/B]
有点冤枉。如果知道代码页转换程序，则多数不为“乱码”犯愁，多数是不知此程序并不知如何处理“乱码”文件，才让“乱码”文件真的产生。
至于处理方法：
[B]1，在ACAD上没法把繁体（big5）转为简体（GB），至少用Lsp无法编程，对吗？[/B]
Lisp处理文字问题受字符ascii码范围影响，他的read-char函数不能读取二进制文件，更明白点说，是不能读取ascii在32（020）一下的控制字符，如果Big5内码使用的范围在此以上，理论上完全可以实现转换（GBK使用字符代码范围在040～0ff，不知Bg5在什么范围），即便如此，可以想见，这不是一个小工程。
[B]2，由繁体字图纸产生乱码的一个很大的可能是用页码转换程序把\M+2xxxx改成\M+5xxxx，结果既不能显示繁体，又没有对应相应简体字符，解决的方法应该是用页码转换程序把它们再转回去，对吗？ [/B]
不能这样解决。正如Autodesk所说的，这些“乱码”是不可逆的。如果只是使用代码页转换工具对文件代码页转来转去当然没有问题，如果打开后[B]实施[/B]存盘，则图形代码页已经转变为系统代码页，当然也就无从转回。这就是需要解决的问题。

柔柔

上面“加一个：。。。。似乎有待研究。”之乱码

柔柔

谢谢ll_j 解答。
乱码图片，呵呵～～～
请别指出我的制造工艺（你一看就明白的，但不要明说），要不，我就成了乱码教唆犯啦。。。。。。

告诉你关于乱码处理正确率达100%的秘密：）
1、有一种乱码非常有规律，大写字符其Unicode代码也是大写，小写字符其Unicode代码也是小写，这样，可以在程序中替换：E0-->C0，c0-->e0
2、增加人工干預，它们的排列组合最多有4组，AB  Ab  ab aB，这样，先不把它们转换成\M+5xxxx，通过人工调整（当然也是用程序）后转成\M+5xxxx。

ll_j

接着昨天没有来得及回答的问题：
[B]3，如果是假的繁体，也就是在文字编辑框内能显示繁体汉字的那种（怎么产生的我一直没弄明白），可以通过dxf-->Word简繁转换-->简体，同理，我们完全可以把简体转成真正的繁体，但是，却没有办法把真正的繁体转换成简体，因为尽管在图上能显示繁体，但它的数据却是\M+2xxxx。对吗？ 那么，用什么软件可以达到这种转换呢？[/B]
先说答案，如果是真的繁体（Big5内码），可以使用南极星通用内码转换程序转换。附件是我转换的文件，遗憾的是，只能在简体系统中（GB）测试。可以看出，使用南极星转换效果还是很好的，因为昨天所说的Bg5内码区域的问题，以前转换其他图形时，有些字符在打开Dxf文件时会冲突，可能需要手动修改shx文件名。
在此之前，我也使用Word转换过，遗憾的是，这种文件只能使用“宋体”、“Mingliu”等字体打开，这就使得我怀疑“Mingliu”字体的正在代码页（前几天就考虑这个问题了），好像[B]“Mingliu”是为了简体系统定制的、实际使用GBK内码的、可以识别Big5内码网页的一种特殊字体[/B]（过几天要向使用繁体系统的网友请教了）。

关于手动制造乱码，使用代码页转换程序转换一下就可以了（我的Lisp中的替换源码就是这样来的）。遗憾的是更多的情况下，被Acad识别的图形出现的“乱码”与我们转换的“乱码”是不同的，或者说显示不同，这也是出现乱码的原因之一，如“\U+00e8”显示为“è”，而同样“\U+00c8”也显示为“è”，由于保存过，在机器中只能认做“è”，这就是需要手动干预的情况。
需要指出的是，十六进制使用时，“c0”与“C0”是等同的，而几个需要干预的字符在文件中被[B]再次读出[/B]时显示的不再是“\U+00c8”的形式，而是“è”的形式，这就需要人工判别这是“\U+00c8”还是“\U+00e8”，好在双字节字最大只有四个选择，还有处理的可能。

distancenl

看得有点晕了,深奥!看来还得好好研究,路漫漫其修远兮~