@zzxa 没有用过不要误导别人， Session 会自动保持 cookies

@xuboying 纳尼，强推 VIP 怎么回事？普通用户什么功能不能用了吗？我前几个月用积分换了好久的 VIP ……

我刚想说 nolocal

@Delbert requests 特定网页有一个问题，没记错的话是信任服务器反馈的 encoding 而不是 html 中指定的 encoding 。

不过这个函数官方也写了，我不懂他们为啥不默认开启

握草 楼主这个门槛也太高了。

话说现在的迅雷还有啥卵用吗，下啥都是非法

1. 楼主你别用 urllib ，换 requests ， resp.text 直接是 unicode ， py2 py3 直接 print 都能看
2. 上 Python3 ， py2 我们别管了

蛤蛤 楼主你不喜欢 ORM 但这不也搞了一个 ORM 的轮子吗？

我觉得 JSON 有个劣势就是不能像是语义的 ORM 一样补全，当然见仁见智。

项目开源的很专业，已 star 。

赞一个，资慈分享

“握草 你看到对面那个山没？”
“哪呢哪呢，你等一下，地形还没加载好。”

“你看那边那块石头”
“机器太渣，地表细节我关闭了”

楼主先不要慌，切 markdown 排下版

```python
pass
```

虽然代码没有看得很明白，猜测是类型转换问题？楼主你直接把上面那个类对象传进去了？

- - 建议楼主看一下 PEP8 ，然后用个 ORM 操作数据库，推荐 Peewee 或者 SQLAlchemy

楼主等一下，产品是什么？

CURD

很有价值 收藏了

楼主翻一下 http2
然后翻一下异步 WebSocket 相关的资料

用来装逼： https://github.com/fy0/tinyre
这门课赋予了你构建软件行业基石的能力。

对了，其实将\0 当作字符串末尾我觉得不是一个好的设计。

python 在写扩展的时候，字符串的姿势有好几种，包括这种直接的\0 为末尾，中间不能有\0 的字符串，以及给出长度的字符串等等。

@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