|
|
|
|
| [精华] fedora下如何支持zh_CN.utf8? |
  [精华] fedora下如何支持zh_CN.utf8? - nimitz [ 2004-02-05 22:43 | 262 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - unix [ 2004-02-09 17:04 | 92 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - yuking [ 2004-02-10 08:33 | 38 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - unix [ 2004-02-10 13:46 | 79 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - Rigel [ 2004-02-12 15:28 | 208 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - tram [ 2004-02-18 09:37 | 152 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lucida [ 2004-02-14 15:36 | 161 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - Rigel [ 2004-02-16 15:19 | 971 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - tram [ 2004-02-18 09:39 | 705 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lucida [ 2004-02-17 05:29 | 661 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lhl [ 2004-02-16 17:08 | 117 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - Rigel [ 2004-02-17 16:33 | 797 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lhl [ 2004-02-17 20:53 | 446 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - shuyong [ 2004-02-17 13:51 | 132 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lhl [ 2004-02-17 20:35 | 258 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - shuyong [ 2004-02-18 13:15 | 141 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - lhl [ 2004-02-18 19:05 | 242 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - tram [ 2004-02-13 00:14 | 34 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - Rigel [ 2004-02-16 15:24 | 64 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - tram [ 2004-02-18 09:14 | 46 byte(s)]
[精华] 果真是“一天不学习,赶不上tram” - xiaohuo [ 2004-02-18 10:00 | 216 byte(s)]
[精华] Re: 果真是“一天不学习,赶不上tram” - tram [ 2004-02-18 20:56 | 33 byte(s)]
[精华] Re: 果真是“一天不学习,赶不上tram” - tram [ 2004-02-18 20:47 | 250 byte(s)]
[精华] 原来如彼 - xiaohuo [ 2004-02-19 09:37 | 471 byte(s)]
[精华] Re: 果真是“一天不学习,赶不上tram” - Eric.Hu [ 2004-02-19 09:23 | 300 byte(s)]
[精华] Re: 果真是“一天不学习,赶不上tram” - nxin [ 2004-02-19 09:36 | 80 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - unix [ 2004-02-12 16:35 | 134 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - Rigel [ 2004-02-16 16:15 | 1,027 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - unix [ 2004-02-22 13:03 | 188 byte(s)]
[精华] 重帖附件 - Rigel [ 2004-02-16 16:21 | 0 byte(s)]
[精华] Re: 重帖附件 - WC_CLF [ 2004-02-16 17:03 | 81 byte(s)]
[精华] Re: 重帖附件 - tram [ 2004-02-18 09:42 | 161 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - yuking [ 2004-02-10 17:04 | 37 byte(s)]
[精华] Re: fedora下如何支持zh_CN.utf8? - unix [ 2004-02-10 19:57 | 30 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
|
我在fedora下把simsun.ttc拷到/usr/share/fonts/用mkfontdir生成fonts.dir，把locale设成zh_CN.utf8，但是我用xfontsel选择simsun-iso10646，英文正常，中文是乱码，只有simsun-gb2312.1980中文显示正常，因为要用fvwm，所以必需要用iso10646的字符集，请教一下，如何设置？谢谢！！
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
如果一年前你说为时过早，可能还着点儿边儿。现在的情况是，如果你还没用，可能
已经为时过晚了。我用 redhat 缺省的 en_US.utf-8 locale 一年多了，没发现有任何
针对中文的特殊问题，输入显示都很好啊。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
是吗？请问最上面那个问题是怎么回事，SimSun应该是Unicode字体，而且发现好多好看的字体也不被支持。另外还有很多习惯用的程序不支持Unicode。
|
|
----
Stern des Südens
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>> utf8还是很麻烦的，比如运行xmms之类的gtk1程序
麻烦在何处？我天天用 xmms 怎么没觉得？
>> 但是对大多数人而言，也不会有什么额外的好处
好处大发了！技术上的好处就不说了，这不是讨论技术的地方。就说全球同码这一点，
对用户和开发者要省多大心啊？
以你贴的 xpdf patch 中文书签为例，为什么长期以来 acroread 和 xpdf 都不能正常
显示中文书签（按 PDF 术语叫 outline）？因为在 PDF 标准中 outline object 无法
指定编码或字体。它的本意就是只能用 latin1 编码。这怎么行？我们中国人当然要中文
的书签，韩国人要韩文书签，阿拉伯人要阿拉伯文书签，......。于是大家就纷纷用自己
的编码写书签。结果呢？应用程序无从判断你用的是什么编码。你的补丁基本是个 hack，
要求用户来提供编码信息。这不是给用户添麻烦吗？要是大家都用 utf-8 呢？是不是都 要
省好大事儿？
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>> 是吗？请问最上面那个问题是怎么回事
怎么回事？我告诉你是怎么回事。对提问者来说叫天下本无事庸人自扰之。他已经可以
看见 -*-simsun-*-iso10646 字体，用就完了。非要 xfontsel，他又不知道怎么用，这
不是跟自己过不去吗？对你这个回答者叫不懂装懂。你显然对 xfontsel 这个程序一壳不
通。xfontsel 是一个不倚赖 locale 的程序，在任何locale 下显示的结果是一样的。如果
有错误，那是 X core font 系统和 freetype/xtt 模块的错误。你却在大谈什么 UTF－8，
gb18030之类。总而言之你们俩都是不知所云。附件里是在 en_US.UTF-8 locale 下 xfontsel
选择 -*-simsun-*-iso10646 字体显示中文，你看看有问题吗？
>> SimSun应该是Unicode字体，而且发现好多好看的字体也不被支持。
这话像对计算机一窍不通的人说的。什么叫字体不被支持？我还没发现有哪个字体在
en_US.UTF-8 locale 下不能用，无论是好看的，还是丑陋的。:-)
>> 另外还有很多习惯用的程序不支持Unicode。
比如说 ......
|
|
|
--
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
借地方请问Rigel一下，windows的unicode兼容性做的不错，不过诱发很多安全漏洞，不知道是否linux和gcc也潜在存在这样的隐患。
|
|
----
时间永是流驶，BBS依旧不太平。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
@Rigel:
pdf的outline是ucs2编码的，也算是unicode的一种，并不是你说的“于是大家就纷纷用自己
的编码写书签”。
gtk1的xmms，如果你的mp3的id3 tag都是utf8编码的，自然没问题，否则。。。
再比如，写点东西给别人，也许对方会抱怨说“都是乱码”，你再告诉他，你得用gedit打开。。。
同屏处理多国文字，对大多数人来说并不是什么实际需求——当然，同屏处理中文英文也许是，但是现在的gbk/18030也能作的很好。
utf8技术是先进，特别是配合gtk2的时候，用起来的确很爽。但是先进的东西不一定会成为主流，这样的例子太多，不独utf8为然。当然尝试新事物也是一种乐趣，但是在它足够流行之前，我还是宁愿用些老旧的东西。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
哈哈，正如楼下 shuyong 兄说的，编码无罪，用者之罪。
我想你指的大盖是几年前轰动一时的所谓微软“IIS Unicode Venurability”。在那件事上
微软犯了两个错误。
1。先分析 URL，然后才转换成 Unicode。这个归根到底是对 unicode 的支持不好，而不是
太好了。
2。在转换 unicode 的时候（这里是处理 UTF－8），接受非法的 code sequence。这个
早在 1998 年的 RFC 2279 就已经指出是 security 隐患。微软置若罔闻。
对处理各种 UTF 来说，最重要的 security 考虑就是坚决不能接受 illegal code sequence。
这是我们熟习的 ASCII 码没有的新情况。这和 gcc 恐怕关系不大，但 glibc 确实是这么做的。
但归根到底系统的安全靠的是我们每个程序员都意识到这点，这个需要教育。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>不会是编程习惯不好，造成buffer overflow，然后瞎想出来的吧
既然明明知道，就没必要皮里阳秋了。”编程习惯不好“是个坑，啥玩意儿都朝里扔。GPL的东西”编程习惯不好“的可老了去了，为什么就不能怀疑？
|
|
----
时间永是流驶，BBS依旧不太平。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>1。先分析 URL，然后才转换成 Unicode。这个归根到底是对 unicode 的支持不好，而不是
>太好了。
我想这是流程上的漏洞，不一定就是对 unicode 的支持不好。
谢谢，我想知道的就是现有GNU代码还是有漏洞的。什么”编码无罪，用者之罪“不敢苟同。既然OS不分Windows还是linux都有类似问题，这说明这个体系还是不完善的，既然不完善，就有漏洞。狗屎盆子都扣到编码人员身上没有道理。
|
|
----
时间永是流驶，BBS依旧不太平。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
你不看看redhat里有多少补丁?
如果这些补丁被各自的项目组接受，那还可以，不过很多project根本不管这种补丁的，你用着不是自找麻烦?还是要绑在redhat上?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>>以你贴的 xpdf patch 中文书签为例，为什么长期以来 acroread 和 xpdf 都不能正常
显示中文书签（按 PDF 术语叫 outline）？因为在 PDF 标准中 outline object 无法
指定编码或字体。它的本意就是只能用 latin1 编码。这怎么行？我们中国人当然要中文
的书签，韩国人要韩文书签，阿拉伯人要阿拉伯文书签，......。于是大家就纷纷用自己
的编码写书签。结果呢？应用程序无从判断你用的是什么编码。你的补丁基本是个 hack，
要求用户来提供编码信息。这不是给用户添麻烦吗？要是大家都用 utf-8 呢？是不是都 要
省好大事儿？
这就纯粹是偷换概念了，你程序用什么编码，是程序的事，和系统locale根本没关系。pdf自己的标准不支持，难道你系统locale改成utf8就支持了?
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
这个“淘汰”UTF-8的是什么玩意儿,能不能透露一点,让我们大家都学习学
习?
至于“高”也好,“低”也好,不过是相对而言。比如你要是能把淘汰UTF-8的
事讲清楚,我就觉得你还要“高”。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
标准或许可以做到无泄可击，标准的实现产生漏洞还是有可能的。我原来的贴子不就是问人家在实现过程中是否有产生漏洞的可能吗？
原来以为汉语不容易产生歧义，可忘了现在英语水平比汉语水平高的同志太多。没说足够明白，是我的错。
|
|
----
时间永是流驶，BBS依旧不太平。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
utf-8里中文的那三个字节，要多难看有多难看，就看这一点，utf-16也比它强得多。
要么是系统工具支持16位的字串，要么是做一个结合两者优点的编码，我看前者的可能性更大。
utf-8这样的东西，说到底只是历史欠债太多，一下还不过来，有什么好推广的。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
其实，从一个完美主义的技术人员角度来看，很多标准其实制定的非常“丑陋”。但是，他就是标准，现实令人无奈。一个简单的例子，哪位有幸去写一下标准键盘的驱动，一定会对设计键盘扫描码的人恨之入骨，骂他脑子进水了。呵呵。
一点感想而已。并不支持这场口水战的任何一方。特此申明，不要把我卷进去，非常感谢。
|
|
----
Hello,world!
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我只好又“避而不谈”了。硬要说什么,那就是在UTF-8和UTF-16之间,UTF-16
根本不用考虑,原因很简单:要8不要四四16,这个时髦好像跟非典一样,是
从广东传染过来的 
至于PDF outline,我不过是不懂,不够资格谈。虽然我并不反对,甚至还常
常鼓励大家想到什么就说什么,说对说错都没关系,只要最后都有收获就行
了—但对我自己而言,于不懂的事宁愿多问多看。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
对上面两个问题的确是我一窍不通。但现在还有很多程序的确不支持
UTF-8编码，如PHPMyAdmin,老点版本的mysql。而且除了Redhat,Turbo等几个最新版本的Linux,其它的对UTF-8编码的支持也不是太好。
|
|
----
Stern des Südens
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。