诸位，首先要解决的问题不是在题主不会在一个处理多文件工程的 IDE 里面创建多个文件吗…？

@dlllcs mkhtmltopdf 有个坑点（不过主要是对于发行版打包者来说的）：迟迟不迁移到 QWebEngine ，内置的老版本 QWebView (WebKit) 还带魔改…

https://github.com/travist/jsencrypt

直接调 openssl 啊……

改写一下 @b1eberg0n ，来个范围攻击的……

a_b = [a.findall('b') for a in soup.findall('a')]
a_b_flat = [result for a in soup.findall('a') for result in a.findall('b')]

@Mithrandir MediaWiki 没有模板功能直接就没有灵魂了差不多…… GitHub 那个 好像是 Ruby 写的 wiki 系统也是支持那么多，也是各种只有层皮。

MDN 那个 Kuma 相比之下没有语法兼容却有类似功能（ KumaScript ）。

（说回来这么强调用模板大概也是在 MediaWiki 下被折腾多了出来的……）

https://stackoverflow.com/questions/16121001 ，直接插空格。
当然想模仿一下 br 处理的话还得再费点事。 strip 那玩意本来就是拿来吃空格的，别指望它……

gbk 我记得是没有谚文字符的，全都得用 18030 的 UTF 去做（ https://r12a.github.io/apps/encodings/）。要不要默认这一点然后用一下 'gb18030' 去 decode/encode ？（结果变成猜 conhost 怎么处理复制粘贴输入，还有解码 cp936 的时候会不会尝试 cp54936 了……）

print b'\xd0\xc2\xbd\xa8\xce\xc4\xbc\xfe\xbc\xd0\x828\xc71\x833\x9a7\x835\xc47' # gb18030 出来的

另外 Python 的 cp936 实现坑很大（没有欧元字符， Py#28343 ），不过在 Windows 上因为会直接调用系统 MultiByteToUnicode 还是建议一试。要兼容不同语言 Windows 的话可以试试 'mbcs' 这个特殊编码名，直接 MultiByteToUnicode 按照当前编码解析。

慢着，怎么全都是 encode 不是 decode 来着……？一般 print 的话直接把 <type 'unicode'> 的浆糊丢出去让 Py 看着办吧。

* * *

@zungmou 开个 65001 当然该解决问题。如果你看到的不是问号字符而是有个框的问号，那就说明是字体问题不是 Python 解码问题了。造个 cmd 快捷方式去注册表折腾折腾换个字体试试吧。

@imn1 py3 不是转 utf-8 ，是转了一个内部可能为 UTF-8/16/32 的 <type 'str'>（也就是 py2 'unicode'）实现。

2 的某些痛点可以 __future__ 和和稀泥（ 2 的后面几个版本在这个意义上还是能用的，毕竟还能写写 b"" 出个 str ），至于 3 那些在工程上可以帮助减少脑抽概率的语法新增（ type annotation ）大概只能靠游说和憋着了。说起“后面几个版本”， Py2.6+ 的 io 那套完全就是 Py3 的用词，恶毒一点的话可以故意多用用把人逼上 Py3 。

或者可以造点 RPC 的轮子在 2 和 3 之间传东西……（雾）

* * *

@gouchaoer py 最傻逼的地方是 3 不兼容 2 的傻逼之处。

@loveminds 字符串、 except ……还有就是关于写了 3 为什么还要不用新特性之类的事情。

@prefere 如果经验指的是记得绕着坑走路的话，正常人都愿意直接用坑少的吧……？

@nullizer 不不不，现在是 Python 8 的时代 /

@crazykuma 欸有 native 部分啊……迁移 C API 好像事情列出来倒是比脚本语言那块少： http://python3porting.com/cextensions.html 。 Python 3.x 这方面有个地方好， 3.2 开始有 stable ABI 了。话说和女孩子交流并没什么可以另外表示困难、奇怪的吧。

@AlexZou 不要把人往坑里送……到时候就是“项目图速度快不用转译，可是总有人要用 ES2018[???] 了”。

少了一步 substring ，把第一个字切掉就是……

@codehz 自由字体放 release 不就好了（ x

东西不错，加个 1 。（要是把输出文件找个 releases 挂着做个懒人包就更棒了(x)）

> 因为 Unicode 中的好多特性都不能实现

叫做 UCS 就好了（小声）

> 还有好多游戏中文显示不了的

嘛，字太多，没必要特地去设计放进去……
语言设定里面有个 Force Unicode Font 的设定会把你全都搞进系统字体（以及你设置的这个字体？），大概也有点信任系统没眼瞎的意思吧。（笑
话说这个字体材质的话有加粗这回事吗？我看别人 Linux 上跑的 Minecraft 截图，遇到加粗字体文泉驿会有描边……

> 想到 ASCII 总共才 256 个字符

不不不和编码完全没关系，真的就是懒的事。你看 minecraft 默认字体显示 naïve 是不是很正常啊。

> 删去 0-9 的, 还算能看

其实没什么好删的，本来也该是这样：
https://en.wikipedia.org/wiki/Power_law

@zhijiansha 换成 python3 立地成佛，或者 python2 去乖乖用 unicode 数据类型。我感觉我说了很多遍了啊。

@Magic347 其实是因为 requests 没有调 encoding 直接取 text ，自动当作 ISO-8859-1 回落解码了：

>>> import requests
>>> resp = requests.get("http://jobs.51job.com/shenzhen-baq/81498324.html?s=0" )
>>> resp.encoding
'ISO-8859-1'

这时候取内容会逐 byte 处理，按照你提到的 U+00 ~ U+FF 和 latin1 一一对应的方式处理得到了一个 *错误的* resp.text 字符串：

<class 'str'>

接下来你直接把这锅浆糊送进 lxml 是在碰运气作死。之所以说碰运气，是因为 GBK 第二范围有 [40, 7F) ∪ [80, FF)， 直接按照字节处理的话前半在 ASCII 内有对应的部分搞不好会和别的东西撞。比如说 CDATA 用 ]]> 结尾，而“昡”这个字又是编码成 b'\x95\x50'，原文出现“昡]>”的时候就会错误认定 CDATA 结束。这是一个安全问题。

要正确解决的话很简单，就是先把 resp.encoding 设置成正确的编码名，这样取 resp.text 才会按照正确的解码方式得到正确的字符串。

@mingyun lxml 只是拿来解析得到的数据而已，和你解码文字的过程并无太大关系。

（对不起，我把 issue 看错了……啊自己真是的。）

@qq7171891 （啊…继续歪楼。）

其实刚才直接说不能 eval 也不对，至少 ES5 是可以了， JSON 设计目标之一也是这个： https://github.com/judofyr/timeless/issues/57

问题是明明可以避免数据库中邪恶管理员插入的任意代码执行的……

@qq7171891 暂时不吐槽你在 Python 版里面 eval JSON ，我先告诉你这样子对 JS 都行不通：

http://timelessrepo.com/json-isnt-a-javascript-subset

JS 也好， Py 也好，为什么就是不愿意去用专门的东西呢？

当你尝试用 TextIOWrapper 钦定这东西是有效的某种编码的纯文本的时候就已经在犯了用记事本打开文件的错误了。你要在已有的 stream （已经是 file-like 了吧？）上面再构造 file-like 的话可以看看 io.BufferedReader 之类的东西，反正不要搞 text 。

楼上的技术建议都差不多了。

> 在 cmd 和 IDLE 下运行，显示的 logo 不一致

（想不通， txt 里面都是中规中矩的字符啊。）

* 项目里面 pyc 干掉。 GitHub 网页新建一个 .gitignore 的话里面有 Python 专用的模板的。
* 既然楼上提到了变量拼写，那么我也说一句 language 只见 lang 没见过 lan 的。
* 不要用 docstring 当未来代码的注释…………

> @264768502 输出的时候(比如 print)先 encode …… GBK

py2 的 unicode 类型和 py3 那个讲人话的 str 在 print 的时候都会自动转化的吧？手动指名只会在其他语言的 Windows 以及非 Windows 平台下砸自己的脚。