@ruoyu0088 也是吧，不过也只能管一部分。因为 python 字符串内部可以有\0 。总体来说付出一个字的位置还是值得的。

但想想还是很蛋疼啊，比如经常有人掺杂一两个诡异的字符在纯英文文本里面，整个文本就会被拉长 2-4 倍不等。

不过我想最常用的字符集也就是 UCS2 了吧，所以还能够接受的样子。

我去，原来如此复杂。
感谢楼上几位给出的资料和方法。

python 源码中这个文件有 15665 行，实在是让人望而生畏。
@ruoyu0088 提到编码是自动选择的，我结合读文档的理解和一些测试，
再次进行了一遍求证，最后得到的结论是：

python3 的字符串是根据输入确定编码，在 Latin1 ， UTF16 、 UTF32 之间进行切换。


验证的过程是这样的：

1. 首先是 ucs2(utf16) 的情况 （据我所知 ucs2 与 u16 等价， ucs4 与 u32 等价，不知是否正确）

In [60]: a = '中文'

In [61]: binascii.hexlify(ctypes.string_at(id(a), a.__sizeof__()))
Out[61]: b'010000003094e51d0200000056f1a772a8000000f447c7000000000000000000020000002d4e87650000'

In [62]: binascii.hexlify('中文'.encode('utf-16'))
Out[62]: b'fffe2d4e8765'

我们可以看到，“中文”两个字在编码为 utf16 之后首先是 fffe 这个头部，随后的 2d4e 8765 分别对应两个字，这与从内存中弄到的字符串形态是相同的。


2. 那么我们在文本中加入一个 UCS2 表示不了的字符串呢？会怎么样？

In [64]: a = '\U000a1ffa 中文'

In [65]: binascii.hexlify(ctypes.string_at(id(a), a.__sizeof__()))
Out[65]: b'010000003094e51d03000000220bc0a8b000000000000000000000000000000000000000fa1f0a002d4e00008765000000000000'

我们可以看到， 2d4e 变成了 2d4e0000 ， 8765 变成了 87650000 ，最后是 8 个 0 （一个 UCS4 字符）结尾。

而 fa1f0a00 是 000a1ffa 在内存中的形式（从右向左，每一个字节——即俩 HEX ——逐个倒装）

其实我觉得奇怪的地方在于， python 其实记录了文本的长度，为啥坚持 C 风格的字符串（末尾加\0 ）？



看看这个字符串 encode 后的样子吧！

In [66]: binascii.hexlify('\U000a1ffa 中文'.encode('utf-32'))
Out[66]: b'fffe0000fa1f0a002d4e000087650000'

In [67]: binascii.hexlify('\U000a1ffa 中文'.encode('utf-8'))
Out[67]: b'f2a1bfbae4b8ade69687'

头部变成了 fffe0000 其他都一致。


3. 最后再看看单字节的字符串

In [68]: a = "\x9a\x9b"

In [69]: binascii.hexlify(ctypes.string_at(id(a), a.__sizeof__()))
Out[69]: b'010000003094e51d02000000b9bdd189a4000000000000000000000000000000000000009a9b00'

=====

In [70]: a = "\x9a\x9b 中"

In [71]: binascii.hexlify(ctypes.string_at(id(a), a.__sizeof__()))
Out[71]: b'010000003094e51d03000000a4036e4ba8656164f44dc7000000000000000000030000009a009b002d4e0000'

=====

In [72]: a = "\x9a\x9b 中\U000a1ffa"

In [73]: binascii.hexlify(ctypes.string_at(id(a), a.__sizeof__()))
Out[73]: b'010000003094e51d04000000776e9375b000005a000000000000000000000000000000009a0000009b0000002d4e0000fa1f0a0000000000'

果然不出所料。



说起来\U0000000 是一个比较少用的语法，专门用来转义 UCS4 的。
要不是前段时间搞了 tinyre 这个项目，我肯定是弄不出这样的字符的……
顺便宣传一下在下最近这个项目，一个正则引擎： https://github.com/fy0/tinyre

@lcj2class WOW ，这个办法好。

感谢大家，成就达成了。

@polandeme 几年前的事情了，后来也是某天发现 42 区没有了，貌似是用户太少。

@talkin1 不好意思 手头压了一堆东西，年前可能都没空了

握草 写完了切到外面一看， LZ 机智的水了 3 贴，都在顶部。。。

框架： flask tornado django

入门： Flask ，资料就是官方文档

版本： py3
py3 从语言层面上解决了混乱的编码问题（虽然这是 2 、 3 分裂的主要原因），以及更多细节更为合理（例如 range 成为迭代器，不用再出现 range 性能有问题 xrange 有数值上限，这样的例子很多）。既然是新项目，没有历史包袱，直接上 3 ，万一有需要用 2 也不是很难。
此外，现在推荐用 2 的帖子基本都是 2013 年前的了，目前很多人都倾向从 3 开始新项目。

系统： ubuntu
优先推荐的 linux ，最大好处就是拆封即用不折腾，软件源也相对较新。 win 上装需要编译的包会比较蛋疼。

潜力：我不能做一些预言，说 Python 已经被钦定了，这样你们肯定会说不按照基本法，把我批判一番。但是学 Python 很多好处在 web 之外，你能用它做很多事情， Python 的前景还是不错的。这个我只能说见仁见智吧，语言这么多，选一门喜欢的就好。

轮子：看框架， Django 基本轮子现成，但是大而重，约束甚多，个人不太喜欢。 Flask 也有很多现成的轮子。 Tornado 的话，需要很多轮子，这是我目前总结自用的轮子： https://github.com/fy0/fpage

楼主
不仅
骗了
一波
铜币
，说
不定
还能
挑起
战争

破事水呀，这东西没标准吧

@yoa1q7y

这些插件并不是 flask 本体啊？ Flask 的组件已经并没有明确说什么不兼容了。
再说这已经不是几年前， py3 的支持几乎是标配。也就科学计算那边支持的慢一些。

Tornado

另外 Flask 支持的还不全吗？
LZ 看的那篇文档是老的吧？

@617450941

while (alive) {
connect();
recv(); // 阻塞住等消息，掉线后退出
reset();
}

@617450941 简单呀 设定用户掉线，倒计时再次进行登录行为

坑都在 py2 ，郁闷的是 py2/3 的分别本身也是个坑，向下兼容很烦人。

并没有 swig 有自带的几个封装文件…… 但说好用也有限

怒骗铜币

蛤蛤，挺不错的。
我也广告一波我的 tornado 轮子： https://github.com/fy0/fpage
加了语法糖的 tornado