(这就是你们 apk 那么大的原因？？

不同公司运营的货币基金有设置不同额度的快速赎回，这个特性主要也是余额宝带起来的。传统的货币基金都是需要 T+1 的申购赎回。而银行有些理财产品也有较好的流动性，比如招行好几个产品都是 5 万起投、5 万秒到的。

然而！

这两年余额宝带起来很多支持快速赎回的平台，比如

天天基金网的活期宝，一票的货基支持 30 万以内的快速赎回

网上银行余利宝，100 万内快速赎回

汇添富基金现金宝，500 万内快速赎回

...普通人而言应该够用了，其他的产品可以忽略掉了。

保持匿名的成本会越来越高的，这是可以预见的未来。

@ysc3839 #19 嗯嗯。。。其实在 cmd 运行 python 前用 chcp 65001 切换一下就能让 cmd 显示 utf-8... 所以说显示编码是外部环境的问题，不一定是 python 能解决的……

@rebeccaMyKid #10 编码问题，归结下来有这几个地方需要注意：

输入编码 - 处理过程 - 输出编码 - 显示编码


输入编码是指，你获取的信息来源，比如从数据库里、文件里、网页里、源文件里，获取的是输入的数据，要让程序正确低读取出这些数据； python3 里，"中文"和 u"中文"是等价的，而.py 文件如无意外是 utf-8 编码的，这时候就是一个隐式的 utf-8 到 unicode 的转换了。如果文件编码不是 utf-8，是需要在源码前写#coding: GBK 这样的声名，说这个文件是 GBK 编码的； python2 时候，如果没声名 utf-8,，在源码里写中文是会报错的，因为默认了 ascii 编码而已。

处理过程，在 python 里的话用 Unicode 串最方便了，因为方便后续处理；其他语言有些是没有宽字节类型的比如 php，就用 utf-8。

输出编码，一般需要根据你输出的地方，把处理过程中的字符处理成合适的编码；这一点在 python 里很多时候是隐式处理的，意思就是，直接给输出接口喂 Unicode 的东西，自动封装来编码过程；例子就是，print(u'中文')跟 print("中文".encode('utf-8'))其实是两个处理方式了。

显示编码，根据使用环境，不一定是 python 的问题；比如 python 输出 web 页面，需要设置 HTTP Header 声名编码、Html META 声名，然后浏览器才能正确解释出内容，否则也是乱码。极端例子是在 windows 的命令符使用 python，直接 print(u'中文') 会出现 unicode 无法显示的问题，因为，中文 Windows 的终端是 GBK 的，print()输出时候没法编码正确。


其实所有语言处理编码都是这几个关键点。

主要问题是你的源码文件也是有编码的，utf8 的源码文件还是 GBK 的？这处理起来就不一样了。
最终都还是要理解透编码。

应该不可能的，A2DP 双声道时候，麦克风是禁用的；用麦克风时候就切换到双工的 Headset 模式了。

因为资源是稀缺的。

你们尽管捐，去得成算我输

@jahan #8 那就不要 readline 呀，直接 read 进去一段数据，然后尝试按 utf8 decode，如果出现异常就是有问题了。

机械键盘就是用来折腾的呀 淘宝个随便什么轴的键，如果你玩坏那个键是常用的，就跟不常用的 scroll 之类的调换，换上山寨轴

看这个文字排版就知道不年轻了。

configure --prefix 指定一个特别目录，比如 /opt/python27，不会影响系统的。

不奇怪啊，canonical 裁员了 50%，不可能还有那么多精力延续开发这些桌面组件的，最终也会回归社区的生态。

金属电器的带电不是静电，你还是好好讨论为什么不接个地线吧。

(这就是为啥 app 获取设备 imei 信息的理由？

都两天了，还 2 小时前？

一加 5，HDR+ 的阴影部分确实干净许多，但是拍照会很慢，应该是拍了多张然后有算法合成了。

如果这也能给你绕过去，https 还有什么存在的意义？