在文件头加入
#-*- coding:utf-8 -*- 
保存为 cp936，运行ok!
谢谢各位指教！

在 2005-11-03 15:47:59，"Du Jun" <jdu at haiercct.com.cn> 写道：
> 在文件头加入
> #-*- coding:utf-8 -*- 
> 保存为 cp936，运行ok!
> 谢谢各位指教！
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese

这显然不对吧。

你程序错误的原因应该是你没有使用转意符，这和你的空格没有任何关系。
因为你是在windows下，目录分割符是'\\'，而python中的字符串使用\做为转意符。
因此你的目录应该写成：'C:\\Document and Setting\\xxx'的形式.
如果你不想写两个'\\'，python的字符串有另一种语法，就是字符串前加r，这样可以取消
字符串中的转意符作用。
于是就变为：r'C:\Document and Setting\xxx'的形式了。

PS：牢骚几句。
发现这个列表：

吵吵嚷嚷的多，答疑解惑的少；
跑题的多，合题的少；
空谈的多，实干的少。

每天离题的邮件不下7,80封。实在是。。。

-- 
张骏 <zhangj at foreseen-info.com>

敏捷来自Python
简单源于我们
丰元信信息技术有限公司

在 05-11-3，张骏<zhangj at foreseen-info.com> 写道：
> 在 2005-11-03 15:47:59，"Du Jun" <jdu at haiercct.com.cn> 写道：
> > 在文件头加入
> > #-*- coding:utf-8 -*-
> > 保存为 cp936，运行ok!
> > 谢谢各位指教！
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
>
> 这显然不对吧。
>
> 你程序错误的原因应该是你没有使用转意符，这和你的空格没有任何关系。
> 因为你是在windows下，目录分割符是'\\'，而python中的字符串使用\做为转意符。
> 因此你的目录应该写成：'C:\\Document and Setting\\xxx'的形式.
> 如果你不想写两个'\\'，python的字符串有另一种语法，就是字符串前加r，这样可以取消
> 字符串中的转意符作用。
> 于是就变为：r'C:\Document and Setting\xxx'的形式了。
>
> PS：牢骚几句。
> 发现这个列表：
>
> 吵吵嚷嚷的多，答疑解惑的少；
> 跑题的多，合题的少；
> 空谈的多，实干的少。
>
> 每天离题的邮件不下7,80封。实在是。。。

指出的明确！所以要坚持自个儿 的言行，主动帮忙，量力而为，不随便意见，
共勉之…………

> --
> 张骏 <zhangj at foreseen-info.com>
>
> 敏捷来自Python
> 简单源于我们
> 丰元信信息技术有限公司
>
>
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
>


--
# Time is unimportant, only life important!
## 面朝开源，我心自由！

Du Jun wrote:
> 在文件头加入
> #-*- coding:utf-8 -*- 
> 保存为 cp936，运行ok!
> 谢谢各位指教！

文件头指定的编码应和文件实际编码一致。你这里运行ok其实是你运气好，正好你
的cp936的中文用utf-8编码也能解释。

刚才又看了一下你的主贴，你的代码写的还是有些问题，重贴如下：

> import os,string,time
> iWorkDir=os.path.normpath('D:\Documents and Settings\Arui\桌面\工作夹')

用os.path.normpath转换路径分隔符时，参数中的路径分隔符应用正斜杠表示：

iWorkDir=os.path.normpath('D:/Documents and Settings/Arui/桌面/工作夹')

os.path.normpath会自动转成反斜杠。如果不用os.path.normpath，用\\或者raw
string都可以。

> iDirList=os.listdir(iWorkDir)
> iFolderName=string.join(time.ctime().split()[:3],'-')

string.join这种用法已经deprecated了，建议的用法是直接使用str对象的join方法：

iFolderName = '-'.join(time.ctime().split()[:3])

> 
> if(iFolderName in iDirList):
> 	pass
> else:
> 	iNewFolder=os.path.join(iWorkDir,iFolderName)
> 	os.mkdir(iNewFolder)



-- 
Qiangning Hong, Registered Linux User #396996
My Blog: http://www.hn.org/hongqn
RSS: http://feeds.feedburner.com/hongqn

在 2005-11-03 17:44:35，Qiangning Hong <hongqn at gmail.com> 写道：
> Du Jun wrote:
> > 在文件头加入
> > #-*- coding:utf-8 -*- 
> > 保存为 cp936，运行ok!
> > 谢谢各位指教！
> 
> 文件头指定的编码应和文件实际编码一致。你这里运行ok其实是你运气好，正好你
> 的cp936的中文用utf-8编码也能解释。
> 
> 刚才又看了一下你的主贴，你的代码写的还是有些问题，重贴如下：
> 
> > import os,string,time
> > iWorkDir=os.path.normpath('D:\Documents and Settings\Arui\桌面\工作夹')
> 
> 用os.path.normpath转换路径分隔符时，参数中的路径分隔符应用正斜杠表示：
> 
> iWorkDir=os.path.normpath('D:/Documents and Settings/Arui/桌面/工作夹')
> 
> os.path.normpath会自动转成反斜杠。如果不用os.path.normpath，用\\或者raw
> string都可以。
> 
> > iDirList=os.listdir(iWorkDir)
> > iFolderName=string.join(time.ctime().split()[:3],'-')
> 
> string.join这种用法已经deprecated了，建议的用法是直接使用str对象的join方法：
> 
> iFolderName = '-'.join(time.ctime().split()[:3])
> 
> > 
> > if(iFolderName in iDirList):
> > 	pass
> > else:
> > 	iNewFolder=os.path.join(iWorkDir,iFolderName)
> > 	os.mkdir(iNewFolder)
> 
> 
> 
> -- 
> Qiangning Hong, Registered Linux User #396996
> My Blog: http://www.hn.org/hongqn
> RSS: http://feeds.feedburner.com/hongqn
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese

其实结果正确也不能算运气好。

coding: utf-8这种指定只对unicode常量字符串有效，对于str，还是以存放时的编码处理。
因此，路径实际被normpath处理的时候还是gbk的编码。

也就是说如果
iWorkDir=os.path.normpath(u'D:\Documents and Settings\Arui\桌面\工作夹')
这样写，coding设定才起作用。

但是这样写的结果是脚本根本无法执行，因为python在编译这个字符串的时候，utf8无法成功转换。

-- 
张骏 <zhangj at foreseen-info.com>

敏捷来自Python
简单源于我们
丰元信信息技术有限公司

张骏 wrote:
> 在 2005-11-03 17:44:35，Qiangning Hong <hongqn at gmail.com> 写道：
>>Du Jun wrote:
>>>在文件头加入
>>>#-*- coding:utf-8 -*- 
>>>保存为 cp936，运行ok!
>>
>>文件头指定的编码应和文件实际编码一致。你这里运行ok其实是你运气好，正好你
>>的cp936的中文用utf-8编码也能解释。
> 
> 其实结果正确也不能算运气好。
> 
> coding: utf-8这种指定只对unicode常量字符串有效，对于str，还是以存放时的编码处理。
> 因此，路径实际被normpath处理的时候还是gbk的编码。
> 
> 也就是说如果
> iWorkDir=os.path.normpath(u'D:\Documents and Settings\Arui\桌面\工作夹')
> 这样写，coding设定才起作用。
> 
> 但是这样写的结果是脚本根本无法执行，因为python在编译这个字符串的时候，utf8无法成功转换。

[发文请剪裁引文，谢谢]

coding行不仅仅在创建unicode常量时才使用，它还在python编译器读入源代码的
时候使用。python编译器读入源文件后，首先要先把源文件内容转成unicode再转
成UTF-8字节流，然后再进行语法分析。这一切都发生在编译代码之前。

你可以尝试一下把下面的代码用utf8保存为test.py：

# coding: cp936
a = "桌"

然后运行它。这段代码中没有unicode常量，但是却会segmentation fault，至少
在我这里是这样。

-- 
Qiangning Hong, Registered Linux User #396996
My Blog: http://www.hn.org/hongqn
RSS: http://feeds.feedburner.com/hongqn

在 2005-11-03 18:54:20，Qiangning Hong <hongqn at gmail.com> 写道：
> 你可以尝试一下把下面的代码用utf8保存为test.py：
> 
> # coding: cp936
> a = "桌"
> 
> 然后运行它。这段代码中没有unicode常量，但是却会segmentation fault，至少
> 在我这里是这样。
 
确实会这样。
但是你把这块代码用cp936保存，却可以正常运行
# coding: utf-8

a = "桌"
print a
print `a`

且最后的print打印出的就是汉字的gb2312编码

但是：
>>> a = '桌'
>>> a
'\xd7\xc0'
>>> a.decode( 'utf-8' )
Traceback (most recent call last):
  File "", line 1, in ?
  File "C:\Python24\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data
>>> a.decode( 'gbk' )
u'\u684c'

就是说utf8直接处理"桌"这个汉字的'gb2312'编码是会抛异常的。

> python编译器读入源文件后，首先要先把源文件内容转成unicode再转
> 成UTF-8字节流，然后再进行语法分析
因此，你所说的可能不对。

而且，抛出segmentation fault本身就应该是个bug。
-- 
张骏 <zhangj at foreseen-info.com>

敏捷来自Python
简单源于我们
丰元信信息技术有限公司

张骏 wrote:
> 但是你把这块代码用cp936保存，却可以正常运行
> # coding: utf-8
> 
> a = "桌"
> print a
> print `a`

在parser读入源文件的时候，有两个编码是特殊的：iso-8859-1和utf-8。
对这两个编码，parser不激活set_readline，即默认这两个编码可以读入一切字符
组成的源文件。[1]

前面我回Du Jun的信说他的程序能运行是因为cp936的中文正好能用utf-8编码是不
准确的，在指定utf-8编码的情况下，无论什么编码的源文件均能被parser读入。
但是我们仍然要保证coding行和文件实际编码的一致性，因为在coding行不是utf-
8或iso-8859-1的情况下，就可能导致python不能理解源文件内容。无论源代码中
有没有unicode常量。

> 且最后的print打印出的就是汉字的gb2312编码

这是正常的，因为字符串并不做编码转换，你源代码里是两个字节，自然就输出两
个字节。这个和coding行以及源文件编码均无关。

> 但是：
[...略...]
> 就是说utf8直接处理"桌"这个汉字的'gb2312'编码是会抛异常的。

这个异常是由unicode类型产生的，是运行时异常。和parser读源文件时做的编码
转换是两个流程。

>>python编译器读入源文件后，首先要先把源文件内容转成unicode再转
>>成UTF-8字节流，然后再进行语法分析
> 
> 因此，你所说的可能不对。

你可以再仔细看看PEP263[2]，Concepts节的第三点。他说的比我详细。

> 而且，抛出segmentation fault本身就应该是个bug。

当编译器无法理解源文件内容时，segmentation fault并不是坏的选择。


[1] 参考python源代码Parser/tokenizer.c的check_coding_spec函数
[2] http://www.python.org/peps/pep-0263.html

-- 
Qiangning Hong, Registered Linux User #396996
My Blog: http://www.hn.org/hongqn
RSS: http://feeds.feedburner.com/hongqn

谢谢，这个答案可以接受。

PS：希望列表能多出现这样的文章。

-- 
张骏 <zhangj at foreseen-info.com>

敏捷来自Python
简单源于我们
丰元信信息技术有限公司