目錄
1 Unicode
2 Python中的Unicode
#2.1 Unicode物件的好處
2.2 Python對Unicode的最佳化
3 Unicode对象的底层结构体
3.1 PyASCIIObject
3.2 PyCompactUnicodeObject
3.3 PyUnicodeObject
3.4 示例
4 interned机制
首頁 後端開發 Python教學 Python內建類型str原始碼分析

Python內建類型str原始碼分析

May 09, 2023 pm 02:16 PM
python str

1 Unicode

電腦儲存的基本單位是位元組,由8個位元位元組成。由於英文只由26個字母加若干符號組成,因此英文字元可以直接用位元組來保存。但是其他語言(例如中日韓等),由於字元眾多,不得不使用多個位元組來進行編碼。

隨著電腦科技的傳播,非拉丁文字元編碼技術不斷發展,但仍有兩個比較大的限制:

  • 不支援多語言:一種語言的編碼方案不能用於另一種語言

  • 沒有統一標準:例如中文就有GBK、GB2312、GB18030等多種編碼標準

#由於編碼方式不統一,開發人員就需要在不同編碼之間來回轉換,不可避免地會出現很多錯誤。為了解決這類不統一問題,Unicode標準被提出了。 Unicode會對世界上大部分文字系統進行整理、編碼,讓電腦可以用統一的方式處理文字。 Unicode目前已經收錄了超過14萬個字符,自然支援多語言。 (Unicode的uni就是「統一」的字根)

2 Python中的Unicode

#2.1 Unicode物件的好處

Python在3之後,str物件內部改用Unicode表示,因此在原始碼中成為Unicode物件。使用Unicode表示的好處是:程式核心邏輯統一使用Unicode,只需在輸入、輸出層進行解碼、編碼,可最大程度地避免各種編碼問題。

圖示如下:

Python內建類型str原始碼分析

2.2 Python對Unicode的最佳化

#問題:由於Unicode收錄字元已經超過14萬個,每個字元至少要4個位元組來保存(這裡應該是因為2個位元組不夠,所以才用4個位元組,一般不會使用3個位元組)。而英文字元用ASCII碼表示只需要1個字節,使用Unicode反而會使頻繁使用的英文字元的開銷變成原來的4倍。

首先我們來看看Python中不同形式的str物件的大小差異:

>>> sys.getsizeof('ab') - sys.getsizeof('a')
1
>>> sys.getsizeof('一二') - sys.getsizeof('一')
2
>>> sys.getsizeof('????????') - sys.getsizeof('????')
4
登入後複製

由此可見,Python內部對Unicode物件進行了最佳化:根據文字內容,選擇底層儲存單元。

Unicode物件底層儲存根據文字字元的Unicode碼位元範圍分成三類:

  • PyUnicode_1BYTE_KIND:所有字元碼位元在U 0000到U 00FF之間

  • PyUnicode_2BYTE_KIND:所有字元碼位元在U 0000到U FFFF之間,且至少有一個字元的碼位元大於U 00FF

  • PyUnicode_1BYTE_KIND:所有字元碼位在U 0000到U 10FFFF之間,且至少有一個字元的碼位大於U FFFF

對應枚舉如下:

enum PyUnicode_Kind {
/* String contains only wstr byte characters.  This is only possible
   when the string was created with a legacy API and _PyUnicode_Ready()
   has not been called yet.  */
    PyUnicode_WCHAR_KIND = 0,
/* Return values of the PyUnicode_KIND() macro: */
    PyUnicode_1BYTE_KIND = 1,
    PyUnicode_2BYTE_KIND = 2,
    PyUnicode_4BYTE_KIND = 4
};
登入後複製

根據不同的分類,選擇不同的儲存單元:

/* Py_UCS4 and Py_UCS2 are typedefs for the respective
   unicode representations. */
typedef uint32_t Py_UCS4;
typedef uint16_t Py_UCS2;
typedef uint8_t Py_UCS1;
登入後複製

對應關係如下:

##字元儲存單元字元儲存單元大小(位元組)PyUnicode_1BYTE_KINDPy_UCS11#PyUnicode_2BYTE_KIND1#PyUnicode_2BYTE_KIND#PyUnicode_2BYTE_KIND1
#文字類型
1#PyUnicode_2BYTE_KIND
1

    #PyUnicode_2BYTE_KIND
  • 1

  • #PyUnicode_2BYTE_KIND

    1

  • #PyUnicode

  • Py_UCS2
  • 2

PyUnicode_4BYTE_KIND

Py_UCS4#4#Py_UCS4#4#由於Unicode內部儲存結構因文字類型而異,因此類型kind必須作為Unicode物件公共欄位進行儲存。 Python內部定義了一些標誌位,作為Unicode公共字段:(介於筆者水平有限,這裡的字段在後續內容中不會全部介紹,大家後續可以自行了解。抱拳~)##compact:記憶體分配方式,物件與文字緩衝區是否分離asscii:文字是否皆為純ASCII透過PyUnicode_New函數,根據文字字元數size以及最大字元maxchar初始化Unicode物件。此函數主要是根據maxchar為Unicode物件選擇最緊湊的字元儲存單元以及底層結構體:(原始碼比較長,這裡就不列出了,大家可以自行了解,下面以表格形式展現)maxchar < 128kindascii
#interned:是否為interned機制維護kind:類型,用於區分字元底層儲存單元大小
 
#128 <= maxchar < 256256 <= maxchar < 65536 65536 <= maxchar < MAX_UNICODE
PyUnicode_1BYTE_KINDPyUnicode_1BYTE_KIND PyUnicode_2BYTE_KINDPyUnicode_4BYTE_KIND
#1######0######0#####0# ###########字元儲存單元大小(位元組)######1#######1######2######4### #########底層結構體######PyASCIIObject######PyCompactUnicodeObject######PyCompactUnicodeObject#######PyCompactUnicodeObject########## ##

3 Unicode对象的底层结构体

3.1 PyASCIIObject

C源码:

typedef struct {
    PyObject_HEAD
    Py_ssize_t length;          /* Number of code points in the string */
    Py_hash_t hash;             /* Hash value; -1 if not set */
    struct {
        unsigned int interned:2;
        unsigned int kind:3;
        unsigned int compact:1;
        unsigned int ascii:1;
        unsigned int ready:1;
        unsigned int :24;
    } state;
    wchar_t *wstr;              /* wchar_t representation (null-terminated) */
} PyASCIIObject;
登入後複製

源码分析:

length:文本长度

hash:文本哈希值

state:Unicode对象标志位

wstr:缓存C字符串的一个wchar_t指针,以“\0”结束(这里和我看的另一篇文章讲得不太一样,另一个描述是:ASCII文本紧接着位于PyASCIIObject结构体后面,我个人觉得现在的这种说法比较准确,毕竟源码结构体后面没有别的字段了)

图示如下:

(注意这里state字段后面有一个4字节大小的空洞,这是结构体字段内存对齐造成的现象,主要是为了优化内存访问效率)

Python內建類型str原始碼分析

ASCII文本由wstr指向,以’abc’和空字符串对象’'为例:

Python內建類型str原始碼分析

Python內建類型str原始碼分析

3.2 PyCompactUnicodeObject

如果文本不全是ASCII,Unicode对象底层便由PyCompactUnicodeObject结构体保存。C源码如下:

/* Non-ASCII strings allocated through PyUnicode_New use the
   PyCompactUnicodeObject structure. state.compact is set, and the data
   immediately follow the structure. */
typedef struct {
    PyASCIIObject _base;
    Py_ssize_t utf8_length;     /* Number of bytes in utf8, excluding the
                                 * terminating \0. */
    char *utf8;                 /* UTF-8 representation (null-terminated) */
    Py_ssize_t wstr_length;     /* Number of code points in wstr, possible
                                 * surrogates count as two code points. */
} PyCompactUnicodeObject;
登入後複製

PyCompactUnicodeObject在PyASCIIObject的基础上增加了3个字段:

utf8_length:文本UTF8编码长度

utf8:文本UTF8编码形式,缓存以避免重复编码运算

wstr_length:wstr的“长度”(这里所谓的长度没有找到很准确的说法,笔者也不太清楚怎么能打印出来,大家可以自行研究下)

注意到,PyASCIIObject中并没有保存UTF8编码形式,这是因为ASCII本身就是合法的UTF8,这也是ASCII文本底层由PyASCIIObject保存的原因。

结构图示:

Python內建類型str原始碼分析

3.3 PyUnicodeObject

PyUnicodeObject则是Python中str对象的具体实现。C源码如下:

/* Strings allocated through PyUnicode_FromUnicode(NULL, len) use the
   PyUnicodeObject structure. The actual string data is initially in the wstr
   block, and copied into the data block using _PyUnicode_Ready. */
typedef struct {
    PyCompactUnicodeObject _base;
    union {
        void *any;
        Py_UCS1 *latin1;
        Py_UCS2 *ucs2;
        Py_UCS4 *ucs4;
    } data;                     /* Canonical, smallest-form Unicode buffer */
} PyUnicodeObject;
登入後複製

3.4 示例

在日常开发时,要结合实际情况注意字符串拼接前后的内存大小差别:

>>> import sys
>>> text = &#39;a&#39; * 1000
>>> sys.getsizeof(text)
1049
>>> text += &#39;????&#39;
>>> sys.getsizeof(text)
4080
登入後複製

4 interned机制

如果str对象的interned标志位为1,Python虚拟机将为其开启interned机制,

源码如下:(相关信息在网上可以看到很多说法和解释,这里笔者能力有限,暂时没有找到最确切的答案,之后补充。抱拳~但是我们通过分析源码应该是能看出一些门道的)

/* This dictionary holds all interned unicode strings.  Note that references
   to strings in this dictionary are *not* counted in the string&#39;s ob_refcnt.
   When the interned string reaches a refcnt of 0 the string deallocation
   function will delete the reference from this dictionary.
   Another way to look at this is that to say that the actual reference
   count of a string is:  s->ob_refcnt + (s->state ? 2 : 0)
*/
static PyObject *interned = NULL;
void
PyUnicode_InternInPlace(PyObject **p)
{
    PyObject *s = *p;
    PyObject *t;
#ifdef Py_DEBUG
    assert(s != NULL);
    assert(_PyUnicode_CHECK(s));
#else
    if (s == NULL || !PyUnicode_Check(s))
        return;
#endif
    /* If it&#39;s a subclass, we don&#39;t really know what putting
       it in the interned dict might do. */
    if (!PyUnicode_CheckExact(s))
        return;
    if (PyUnicode_CHECK_INTERNED(s))
        return;
    if (interned == NULL) {
        interned = PyDict_New();
        if (interned == NULL) {
            PyErr_Clear(); /* Don&#39;t leave an exception */
            return;
        }
    }
    Py_ALLOW_RECURSION
    t = PyDict_SetDefault(interned, s, s);
    Py_END_ALLOW_RECURSION
    if (t == NULL) {
        PyErr_Clear();
        return;
    }
    if (t != s) {
        Py_INCREF(t);
        Py_SETREF(*p, t);
        return;
    }
    /* The two references in interned are not counted by refcnt.
       The deallocator will take care of this */
    Py_REFCNT(s) -= 2;
    _PyUnicode_STATE(s).interned = SSTATE_INTERNED_MORTAL;
}
登入後複製

可以看到,源码前面还是做一些基本的检查。我们可以看一下37行和50行:将s添加到interned字典中时,其实s同时是key和value(这里我不太清楚为什么会这样做),所以s对应的引用计数是+2了的(具体可以看PyDict_SetDefault()的源码),所以在50行时会将计数-2,保证引用计数的正确。

考虑下面的场景:

>>> class User:
    def __init__(self, name, age):
        self.name = name
        self.age = age
>>> user = User(&#39;Tom&#39;, 21)
>>> user.__dict__
{&#39;name&#39;: &#39;Tom&#39;, &#39;age&#39;: 21}
登入後複製

由于对象的属性由dict保存,这意味着每个User对象都要保存一个str对象‘name’,这会浪费大量的内存。而str是不可变对象,因此Python内部将有潜在重复可能的字符串都做成单例模式,这就是interned机制。Python具体做法就是在内部维护一个全局dict对象,所有开启interned机制的str对象均保存在这里,后续需要使用的时候,先创建,如果判断已经维护了相同的字符串,就会将新创建的这个对象回收掉。

示例:

由不同运算生成’abc’,最后都是同一个对象:

>>> a = &#39;abc&#39;
>>> b = &#39;ab&#39; + &#39;c&#39;
>>> id(a), id(b), a is b
(2752416949872, 2752416949872, True)
登入後複製

以上是Python內建類型str原始碼分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

PHP和Python:解釋了不同的範例 PHP和Python:解釋了不同的範例 Apr 18, 2025 am 12:26 AM

PHP主要是過程式編程,但也支持面向對象編程(OOP);Python支持多種範式,包括OOP、函數式和過程式編程。 PHP適合web開發,Python適用於多種應用,如數據分析和機器學習。

在PHP和Python之間進行選擇:指南 在PHP和Python之間進行選擇:指南 Apr 18, 2025 am 12:24 AM

PHP適合網頁開發和快速原型開發,Python適用於數據科學和機器學習。 1.PHP用於動態網頁開發,語法簡單,適合快速開發。 2.Python語法簡潔,適用於多領域,庫生態系統強大。

Python vs. JavaScript:學習曲線和易用性 Python vs. JavaScript:學習曲線和易用性 Apr 16, 2025 am 12:12 AM

Python更適合初學者,學習曲線平緩,語法簡潔;JavaScript適合前端開發,學習曲線較陡,語法靈活。 1.Python語法直觀,適用於數據科學和後端開發。 2.JavaScript靈活,廣泛用於前端和服務器端編程。

PHP和Python:深入了解他們的歷史 PHP和Python:深入了解他們的歷史 Apr 18, 2025 am 12:25 AM

PHP起源於1994年,由RasmusLerdorf開發,最初用於跟踪網站訪問者,逐漸演變為服務器端腳本語言,廣泛應用於網頁開發。 Python由GuidovanRossum於1980年代末開發,1991年首次發布,強調代碼可讀性和簡潔性,適用於科學計算、數據分析等領域。

vs code 可以在 Windows 8 中運行嗎 vs code 可以在 Windows 8 中運行嗎 Apr 15, 2025 pm 07:24 PM

VS Code可以在Windows 8上運行,但體驗可能不佳。首先確保系統已更新到最新補丁,然後下載與系統架構匹配的VS Code安裝包,按照提示安裝。安裝後,注意某些擴展程序可能與Windows 8不兼容,需要尋找替代擴展或在虛擬機中使用更新的Windows系統。安裝必要的擴展,檢查是否正常工作。儘管VS Code在Windows 8上可行,但建議升級到更新的Windows系統以獲得更好的開發體驗和安全保障。

visual studio code 可以用於 python 嗎 visual studio code 可以用於 python 嗎 Apr 15, 2025 pm 08:18 PM

VS Code 可用於編寫 Python,並提供許多功能,使其成為開發 Python 應用程序的理想工具。它允許用戶:安裝 Python 擴展,以獲得代碼補全、語法高亮和調試等功能。使用調試器逐步跟踪代碼,查找和修復錯誤。集成 Git,進行版本控制。使用代碼格式化工具,保持代碼一致性。使用 Linting 工具,提前發現潛在問題。

notepad 怎麼運行python notepad 怎麼運行python Apr 16, 2025 pm 07:33 PM

在 Notepad 中運行 Python 代碼需要安裝 Python 可執行文件和 NppExec 插件。安裝 Python 並為其添加 PATH 後,在 NppExec 插件中配置命令為“python”、參數為“{CURRENT_DIRECTORY}{FILE_NAME}”,即可在 Notepad 中通過快捷鍵“F6”運行 Python 代碼。

vscode 擴展是否是惡意的 vscode 擴展是否是惡意的 Apr 15, 2025 pm 07:57 PM

VS Code 擴展存在惡意風險,例如隱藏惡意代碼、利用漏洞、偽裝成合法擴展。識別惡意擴展的方法包括:檢查發布者、閱讀評論、檢查代碼、謹慎安裝。安全措施還包括:安全意識、良好習慣、定期更新和殺毒軟件。

See all articles