@est JPEG 模糊过的大段文字读起来比较费神的（这是我反对 JPEG 屏幕的最主要原因）。

另外截图传递的并不一定是文字信息，也可能是屏幕渲染的信息（比如不同软件的渲染结果有差异是怎么回事啊之类的）。

这里有个对比截图，清晰地显示出 JPEG 对屏幕截图的损坏：

http://lilyimg.b0.upaiyun.com/temp/png_vs_jpeg/a.jpg

http://lilyimg.b0.upaiyun.com/temp/png_vs_jpeg/a.png

exiv2 rm xxx.png

@blacktulip @est 截图会损坏大量数据的。如果你不想破坏图片就不要截图。尤其是 QQ 的工具，很容易把图片重新保存为 JPEG。如果对边缘清晰的图像（如屏幕截图）进行这样的处理，图像会模糊的。

@Mavious 重新保存 JPEG 是会重新编码从而导致信息丢失的。我会通过 JPEG 的 ELA 来判断照片的真实性（至少能判断出明显修改过及反复保存过的照片）。

又见「阀值」……

+1

嗯 1 楼是对的。另外 set encoding=utf8 和文件编码没关系；它主要影响 Vim 界面。

@Shy07 嗯我说的是 Ruby 的实现。语法因为我不写所以不清楚，感觉还好，就是库的不同版本之间的兼容性比 Python 还差的样子。

@GeekTest 还可以面向屏幕阅读器编程的说。虽然那样基本无法使用国内网站。

面向猜测编程、面向谷歌翻译编程。

@Shy07 细节我不记得了，应该是 C API 不兼容，不然正常的嵌入代码不会报错的。

1.8 到 1.9 中文相关的程序容易出问题。

@xgowex 如果证书比较多的话，还是自建一个 CA 吧。

@incompatible Linux 内核开发者交换密钥的方法是在线下见面交换 :-)

要可否认性（plausible deniability）就用 bitmessage，不需要就用 OTR、Tox、PGP 加密邮件之类的。都是不依赖于可信第三方的。当然，密钥怎么交换自己看着办！

@Shy07 可是每次 Ruby 小版本升级 Vim 都要打补丁的说！

@spacewander 是的。因为 3.4 向下兼容 3.2，但是 2 和 3 之间是互不兼容的。重新使用 u 前缀并没有多大的坏处（只是加了个前缀而已，并没有语义上的差异），但是能使迁移顺利一些，何乐而不为呢？

@yakczh Java 是 UTF16，不是 Unicode，对于 U+ffff 以上的字符会当成两个字符的。

@tini31 会有很多单独的输出？我真没见过几乎满屏都是 print 的情况。交互式命令行下你可以 p=print，然后用 p(xxx)，如果 repr 的结果不好用的话。

各个版本差异大的应该是 Lua 和 Ruby 而不是 Python，因为 Python 只是 2.x 和 3.x 差异很大，2.x 内部以及 3.x 内部基本上都是向下兼容的。

Python 3 为了正确地支持 Unicode，不得不与 Python 2 不兼容。既然都不兼容了，不如趁此机会把 Python 2 那些不好的地方都改了。于是又弄出许多小的语法差异。

另外，Perl 5 和 Perl 6 的差异更大。

@tini31 你是不是应该用 logging 了？

@guoqiao 如果你说 print 函数打字多，那么大部分情况下是的。可是 print('loading...', end='', flush=True) 真的很棒呢～

为什么不符合 Python 的哲学呢？不符合哪一条？我看它倒是挺符合 Explicit is better than implicit. 以及 Special cases aren't special enough to break the rules.