分册导航
TC String 逐位解析
同意类定位与分类
由互动广告局（Interactive Advertising Bureau，IAB）Europe 维护的透明度与同意框架（Transparency & Consent Framework，TCF）EU v2，其 TC String = Core String . Disclosed Vendors . Publisher TC，三段以 . 分隔并各自以 3-bit SegmentType 自我标识（Core 段无前缀）。它既是全球隐私平台（Global Privacy Platform，GPP）§2 的载荷，也以首字符 C 的独立串与 GPP 并存。Core 段 17 字段逐位布局。
- GPP section
- §2 (tcfeuv2)
- 状态
- Final v2.2 (+2.3/2.4)
- 独立形态
- 首字符 C，与 §2 并存
- Core 段字段
- 17 个（末段变长）
字符串与字段布局
IAB Europe TCF v2（TCF 2.2 起政策版本为 4；政策版本低于 4 的字符串自 2023-09-30 起无效）
[Core String].[Disclosed Vendors].[Publisher TC] —— Core 之后的各段以 "." 分隔，并各自以一个 3-bit 的 SegmentType 自我标识段（Segment）
供应商透明度与同意的基础信息；总是第一段，且不带 SegmentType 前缀。ENBasic vendor transparency & consent; always first, no SegmentType prefix.
CMP 向用户披露过的供应商列表。自 TCF 2.3（2025 年 4 月）起为强制段，用于消除特殊用途下正当利益（LI）的歧义。ENVendors disclosed to the user by the CMP. Mandatory since TCF 2.3 (Apr 2025) to resolve special-purpose LI ambiguity.
媒体方自身的用途透明度与同意，含自定义用途（custom purposes）。ENPublisher's own purposes transparency & consent, incl. custom purposes.
Core String 字段布局
bit 区间由上表位宽累加得出，与前面走查的第四阶段完全同源；末条为变长三段，位宽由数据本身决定。
| 字段 | 位宽 | bit 区间 | 描述 |
|---|---|---|---|
| Version | 6 | bits[0..6) | 编码格式版本（值为 2）。ENEncoding format version (2). |
| Created | 36 | bits[6..42) | TC String 首次创建时刻的 epoch 十分之一秒数。ENEpoch deciseconds when the TC string was first created. |
| LastUpdated | 36 | bits[42..78) | 最后一次更新的 epoch 十分之一秒数（2021 年 12 月起按天级精度与 Created 保持一致）。ENEpoch deciseconds of the last update (since Dec 2021 kept equal to Created at day-level resolution). |
| CmpId | 12 | bits[78..90) | 最后更新该字符串的 CMP 的 ID。ENID of the CMP that last updated the string. |
| CmpVersion | 12 | bits[90..102) | 该 CMP 的版本号。ENVersion of that CMP. |
| ConsentScreen | 6 | bits[102..108) | 用户给出同意时所在的 CMP 界面屏号。ENCMP screen number where consent was given. |
| ConsentLanguage | 12 | bits[108..120) | CMP 界面的 ISO 639-1 语言码（2×6 bit，a=0…z=25）。ENISO 639-1 language of the CMP UI (2×6 bits, a=0…z=25). |
| VendorListVersion | 12 | bits[120..132) | 所使用的 Global Vendor List 版本。ENGlobal Vendor List version used. |
| TcfPolicyVersion | 6 | bits[132..138) | GVL 对应的 TCF 政策版本（TCF 2.2 起为 4）。ENTCF policy version of the GVL (4 since TCF 2.2). |
| IsServiceSpecific | 1 | bits[138..139) | 必须为 1；值为 0 的字符串会被供应商判为无效。ENMust be 1; a string with 0 is considered invalid by vendors. |
| UseNonStandardTexts | 1 | bits[139..140) | CMP 改动了标准的 stack / illustration 文案。ENCMP modified standard stack/illustration texts. |
| SpecialFeatureOptIns | 12 | bits[140..152) | 各 Special Feature（1–2）的 opt-in 状态。ENOpt-in per Special Feature (1–2). |
| PurposesConsent | 24 | bits[152..176) | Purpose 1–24 的同意状态（法律依据：同意）。ENConsent per Purpose 1–24 (legal basis: consent). |
| PurposesLITransparency | 24 | bits[176..200) | Purpose 维度的正当利益（LI）状态；TCF 2.2 已废弃 Purpose 3–6 的 LI（对应位必须为 0）。ENLegitimate interest per Purpose; TCF 2.2 deprecated LI for purposes 3–6 (bits must be 0). |
| PurposeOneTreatment | 1 | bits[200..201) | 1 表示不披露 Purpose 1（按辖区施行的特殊处理）。EN1 = Purpose 1 not disclosed (special treatment by jurisdiction). |
| PublisherCC | 12 | bits[201..213) | ISO 3166-1 alpha-2 国家码，决定参照的立法辖区。ENISO 3166-1 alpha-2 country determining the legislation of reference. |
| VendorConsents + VendorLI + PubRestrictions | 变长 | bits[213..) | 依次为 Vendor Consent Section 与 Vendor Legitimate Interest Section（各为 MaxVendorId int(16) + bitfield 或 range），再接 NumPubRestrictions int(12) 与可选的限制条目（PurposeId 6 bit + RestrictionType 2 bit + 供应商 range）。三段均为变长，位宽由数据本身决定，无法静态推算。ENVendor Consent Section and Vendor Legitimate Interest Section (MaxVendorId int(16) + bitfield or range), then NumPubRestrictions int(12) with optional restriction entries (PurposeId 6 + RestrictionType 2 + vendor range). |
走一遍：一条真实字符串的解码过程
抽象的 Fibonacci 编码与 bitfield，看一次真实字符串怎么被逐位读出来最直观。下面用官方示例串分四个阶段走查：每一步都会高亮当前字段覆盖的 base64 字符与 bit 区间，并给出解出的值。
样本 · 官方 GPP String Example 2DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN
完整样本串
DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN当前读取的片段
DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN- 编码类型
- modified base64
- bit 区间
- 字符级切分，本步不涉及 bit 读取
- 字符区间
- chars[0..6)
Header
解出的值
DBACNY
整条串被 ~ 切成 3 段：第 1 段是 Header，其余每段是一个 section 的载荷。Header 声明本次携带的 section ID 为 [2, 6]。
字符串所含 Section ID 的有序列表；ID 顺序与其 section 在串中的出现顺序一致。Fibonacci range 编码：先读 int(12) 的条目数 amount，随后每条读一个 single/group 标志位 + 一个 Fibonacci 偏移量（相对上一个 ID，首条以 0 为基准）；若为 group 再读一个 Fibonacci 长度。ENOrdered list of Section IDs contained in the string; IDs appear in the same order as their sections. Fibonacci range: int(12) amount, then per item a single/group bit + Fibonacci offset (from last seen ID, 0-based for the first entry), groups add a Fibonacci length.
第 1 步，共 29 步：Header，modified base64，值 DBACNY
换你自己的字符串
走查用的是固定官方样本。把下面输入框换成你线上抓到的字符串，即可看到完整的字段级解码结果（含走查未覆盖的变长 Vendor 段）。解析全部在浏览器本地完成，字符串不会上传。
GPP Header
GPP v1Header 声明 sections：[2, 6]
Section 2 · EU TCF v2
tcfeuv2Core String
TCF v2Section 6 · USPrivacy String (Unencoded)
uspv1承载与访问
- GPP §2 — 作为 GPP 容器的一段载荷，apiPrefix tcfeuv2，随整串经 regs.gpp / ${GPP_STRING} 承载。
- 独立 TC String — 首字符 C、不套 GPP 容器；欧洲经济区（European Economic Area，EEA）规范明确在 IAB Europe 正式废弃前须继续随交易头传递，与 §2 并存而非被替代。
- __tcfapi — 浏览器侧经同意管理平台（Consent Management Platform，CMP）的 JS API 读取，详见 CMP JS API 分册。
版本差异
TC String 的编码格式版本恒为 2（Core 段首字段 Version）；TCF 政策版本演进（v2.0→v2.1→v2.2→v2.3）见版本差异分册。 TCF 版本差异 →
失效形态
- IsServiceSpecific=0：供应商会判为无效（必须为 1）
- TcfPolicyVersion<4 的字符串自 2023-09-30 起无效
- Core 段之后的各段缺 3-bit SegmentType 自识别前缀