{"id":10310,"date":"2026-08-28T12:30:00","date_gmt":"2026-08-28T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10310"},"modified":"2026-10-24T03:57:10","modified_gmt":"2026-10-24T01:57:10","slug":"einen-tc-string-lesen-was-in-den-213-kopfbits-steht","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/data-privacy-de\/einen-tc-string-lesen-was-in-den-213-kopfbits-steht\/","title":{"rendered":"Einen TC-String lesen: was in den 213 Kopfbits steht"},"content":{"rendered":"

Ein TC-String speichert Transparenz- und Einwilligungssignale in kompakter Form. Die Dekodierung zeigt gespeicherte Werte wie Zweckbits, Anbieterentscheidungen und die verwendete Version der Anbieterliste. Daraus folgt noch kein Nachweis f\u00fcr einen korrekten Banner, eine wirksame Einwilligung oder die tats\u00e4chliche Beachtung durch einen Anbieter.<\/p>\n

Das Format ist kodiert, nicht verschl\u00fcsselt. Zum Lesen ist kein geheimer Schl\u00fcssel n\u00f6tig. Auch ein signiertes Pr\u00fcfprotokoll stellt der String nicht dar. Eine belastbare Pr\u00fcfung verbindet deshalb die Signale mit dem tats\u00e4chlichen Dialog, der passenden Global Vendor List (GVL) und beobachteten Anfragen.<\/p>\n

\"TC-String:
Kodierte Signale sind kein signiertes Einwilligungsprotokoll<\/figcaption><\/figure>\n

Der feste Anfang: 213 Bit einschlie\u00dflich der Zwecke<\/h2>\n

Jedes Segment verwendet das Base64url-Alphabet; jedes Zeichen bildet sechs Bit ab. Punkte trennen die Segmente. Die ersten sechs Bit enthalten die Formatversion: Der Wert 2 ergibt 000010<\/code> und damit das Zeichen C<\/code>. Ein C am Anfang kennzeichnet dieses Versionsfeld, best\u00e4tigt aber nicht die G\u00fcltigkeit des restlichen Strings.<\/p>\n

Das Kernsegment beginnt mit den folgenden Feldern in genau dieser Reihenfolge. Die Bitpositionen z\u00e4hlen ab null: Position 0 bezeichnet das erste Bit. Der 213-Bit-Anfang enth\u00e4lt die Zweckbits bereits. Anbieterdaten beginnen an Position 213, also beim 214. Bit.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Feld<\/th>\nBitpositionen<\/th>\nL\u00e4nge<\/th>\n<\/tr>\n<\/thead>\n
Version<\/code><\/td>\n0\u20135<\/td>\n6<\/td>\n<\/tr>\n
Created<\/code><\/td>\n6\u201341<\/td>\n36<\/td>\n<\/tr>\n
LastUpdated<\/code><\/td>\n42\u201377<\/td>\n36<\/td>\n<\/tr>\n
CmpId<\/code><\/td>\n78\u201389<\/td>\n12<\/td>\n<\/tr>\n
CmpVersion<\/code><\/td>\n90\u2013101<\/td>\n12<\/td>\n<\/tr>\n
ConsentScreen<\/code><\/td>\n102\u2013107<\/td>\n6<\/td>\n<\/tr>\n
ConsentLanguage<\/code><\/td>\n108\u2013119<\/td>\n12<\/td>\n<\/tr>\n
VendorListVersion<\/code><\/td>\n120\u2013131<\/td>\n12<\/td>\n<\/tr>\n
TcfPolicyVersion<\/code><\/td>\n132\u2013137<\/td>\n6<\/td>\n<\/tr>\n
IsServiceSpecific<\/code><\/td>\n138\u2013138<\/td>\n1<\/td>\n<\/tr>\n
UseNonStandardTexts<\/code><\/td>\n139\u2013139<\/td>\n1<\/td>\n<\/tr>\n
SpecialFeatureOptIns<\/code><\/td>\n140\u2013151<\/td>\n12<\/td>\n<\/tr>\n
PurposesConsent<\/code><\/td>\n152\u2013175<\/td>\n24<\/td>\n<\/tr>\n
PurposesLITransparency<\/code><\/td>\n176\u2013199<\/td>\n24<\/td>\n<\/tr>\n
PurposeOneTreatment<\/code><\/td>\n200\u2013200<\/td>\n1<\/td>\n<\/tr>\n
PublisherCC<\/code><\/td>\n201\u2013212<\/td>\n12<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Der feste Anfang endet nach den ersten drei Bit des 36. Base64url-Zeichens. Die \u00fcbrigen drei Bit geh\u00f6ren bereits zu den Anbieterdaten. 35 Zeichen reichen daher nicht; 36 vollst\u00e4ndige Zeichen enthalten schon mehr als den festen Anfang.<\/p>\n

Zeitpunkte und Versionen getrennt auswerten<\/h2>\n

Die Zeitfelder bleiben 36-Bit-Werte in Zehntelsekunden seit der Unix-Epoche. Nach aktueller Spezifikation enthalten Created<\/code> und LastUpdated<\/code> jedoch denselben, auf den UTC-Tag begrenzten \u00c4nderungszeitstempel. Die Multiplikation mit 100 liefert JavaScript-Millisekunden. Aus der Zahleneinheit folgt keine auf Zehntelsekunden genaue Erfassung der Einwilligung.<\/p>\n

Ein altes \u00c4nderungsdatum ist Anlass, Erneuerung und Erinnerung zu pr\u00fcfen. Ein aktuelles Datum belegt umgekehrt keine frische Einwilligung; auch ein Vergleich mit dreizehn Monaten rekonstruiert keine Einwilligungshistorie. Die technische Spezifikation verweist auf Erinnerungen sp\u00e4testens nach dreizehn Monaten. Der String ersetzt die zugeh\u00f6rigen Nachweise nicht.<\/p>\n

Formatversion 2, Framework-Versionen wie TCF 2.3 oder 2.4, Richtlinienversion und GVL-Version sind verschiedene Kennungen. Der Richtlinienwert 4 wurde mit TCF 2.2 eingef\u00fchrt. Ein Wert ab 4 beweist nicht die Umsetzung s\u00e4mtlicher aktueller Anforderungen. VendorListVersion bezeichnet die verwendete GVL-Fassung, nicht die tats\u00e4chliche Anzeige aller darin enthaltenen Anbieter im Dialog.<\/p>\n

Anbieterabschnitte: L\u00e4nge ist kein Zustimmungsma\u00df<\/h2>\n

Ein Anbieterabschnitt beginnt mit einer 16-Bit-H\u00f6chstnummer und einem Bit f\u00fcr das Kodierungsverfahren. Beim Bitfeld folgt ein Bit je Anbieternummer bis zu dieser Grenze. Die Bereichskodierung erg\u00e4nzt zun\u00e4chst eine 12-Bit-Anzahl. Jeder Eintrag enth\u00e4lt ein Bereichskennzeichen und eine 16-Bit-Start- oder Einzelnummer; nur bei einem Bereich folgen weitere 16 Bit f\u00fcr dessen Ende.<\/p>\n

Bei H\u00f6chstnummer 800 ben\u00f6tigt ein Bitfeld einschlie\u00dflich Abschnittskopf 817 Bit. F\u00fcnfzig einzelne Nummern ben\u00f6tigen als Bereiche 879 Bit: 17 + 12 + 50 \u00d7 17. Ein zusammenh\u00e4ngender Bereich ben\u00f6tigt nur 62 Bit: 17 + 12 + 33. Bei Wahl der k\u00fcrzeren Darstellung gewinnt im ersten Beispiel das Bitfeld, im zweiten die Bereichskodierung. Eine Zustimmung zu allem garantiert daher nicht allgemein einen kurzen String.<\/p>\n

Anbietereinwilligungen und Signale zum berechtigten Interesse stehen in getrennten Abschnitten. Einschr\u00e4nkungen des Publishers und zus\u00e4tzliche Segmente beeinflussen die Gesamtl\u00e4nge ebenfalls. Ein langer String belegt weder umfassende Zustimmung noch einen Defekt oder besonders viele ausgew\u00e4hlte Anbieter.<\/p>\n

Aktuelle Regeln zus\u00e4tzlich zum Bitformat<\/h2>\n

TCF 2.2 entfernte berechtigtes Interesse als zul\u00e4ssige Grundlage f\u00fcr die Zwecke 3\u20136. F\u00fcr Zweck 1 war bereits Einwilligung als Grundlage vorgesehen; das l\u00e4nderspezifische Kennzeichen PurposeOneTreatment<\/code> behandelt eine andere Frage. Besondere Zwecke besitzen einen eigenen Nummernraum und geh\u00f6ren nicht in die gew\u00f6hnlichen Zweckbits.<\/p>\n

Bei den derzeit definierten Zwecken 1\u201311 stellen die reservierten Positionen 12\u201324 keine weiteren Auswahlm\u00f6glichkeiten dar. Unerwartet gesetzte Bits erfordern einen Abgleich mit der ma\u00dfgeblichen Spezifikation und GVL. Ein solcher Befund zeigt eine Unstimmigkeit, nicht die Herkunft der Implementierung. Zwecksignale allein erlauben au\u00dferdem nicht jedem Anbieter die Verarbeitung: Anbietersignale, Offenlegung, deklarierte Zwecke und Publisher-Einschr\u00e4nkungen geh\u00f6ren zur Auswertung.<\/p>\n

TCF 2.3 machte das Segment DisclosedVendors<\/code> f\u00fcr ab dem 1. M\u00e4rz 2026 erzeugte Strings verpflichtend. F\u00fcr \u00e4ltere Strings ohne dieses Segment gilt die \u00dcbergangsausnahme; ein fehlendes Segment ist deshalb nicht bei jedem historischen String gleich zu bewerten. Segmenttyp 1 bezeichnet offengelegte Anbieter, der optionale Typ 3 die Zwecke des Publishers. Der fr\u00fchere Typ 2 f\u00fcr erlaubte Anbieter entfiel mit TCF 2.2.<\/p>\n

TCF 2.4 erg\u00e4nzte anschlie\u00dfend \u00fcberarbeitete Informationen zu Features. Die offizielle Umsetzungsfrist f\u00fcr Webumgebungen endete am 23. Oktober 2026; f\u00fcr mobile Apps und CTV endet die Frist am 23. Februar 2027. Daraus wird keine sechs Bit breite Formatversion 2.4. Ein Bitdecoder kann die erforderlichen Texte und deren Darstellung im Dialog nicht pr\u00fcfen.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

Ist euconsent-v2 vorgeschrieben?<\/h3>\n

Nein. Das CMP bestimmt den Speichermechanismus; ein anderer Cookiename oder eine Speicherung ohne Cookie ist m\u00f6glich. Das Fehlen dieses Cookies belegt weder das Fehlen noch die Korrektheit einer Einwilligungsverwaltung.<\/p>\n

Welche Browserschnittstelle eignet sich?<\/h3>\n

getTCData<\/code> ist seit TCF 2.2 veraltet. Der unterst\u00fctzte Weg verwendet addEventListener<\/code>, pr\u00fcft den Erfolg des R\u00fcckrufs sowie CMP- und Ereigniszustand und liest einen verf\u00fcgbaren tcString<\/code>. W\u00e4hrend des Ladens kann der erste R\u00fcckruf noch unvollst\u00e4ndige Daten enthalten. Eine einmalige Diagnose entfernt den Listener nach dem gew\u00fcnschten Schnappschuss \u00fcber removeEventListener<\/code> mit der erhaltenen Listener-ID. Eine Anwendung zur Beobachtung sp\u00e4terer \u00c4nderungen ben\u00f6tigt dagegen ein geeignetes fortbestehendes Abonnement.<\/p>\n

Wie lassen sich unvollst\u00e4ndige Daten erkennen?<\/h3>\n

Ein Decoder pr\u00fcft Alphabet, Feldl\u00e4ngen, Eintragszahlen, Bereiche und Segmenttypen. Eine reine Base64-Dekodierung pr\u00fcft keine Richtlinienkonformit\u00e4t. Bei byteorientierten Decodern erfolgen Alphabetumsetzung und gegebenenfalls Auff\u00fcllung f\u00fcr jedes Segment getrennt. Die direkte \u00dcbersetzung jedes Zeichens in sechs Bit vermeidet falsche Annahmen \u00fcber Bytegrenzen.<\/p>\n

Fehlende Bits k\u00f6nnen durch Kopier-, Speicher-, Kodierungs- oder Transportfehler entstehen. Eine L\u00e4ngengrenze ist eine m\u00f6gliche Ursache, keine Diagnose. RFC 6265 empfiehlt f\u00fcr allgemeine Browser mindestens 4096 Byte je Cookie einschlie\u00dflich Name, Wert und Attributen; die Formulierung lautet SHOULD, nicht MUST. Zu gro\u00dfe Cookies oder Anfrageheader k\u00f6nnen abgelehnt werden, statt unbemerkt abgeschnitten zu werden. Der Vergleich von gespeichertem Wert, CMP-API-Ausgabe und \u00fcbertragenem Wert grenzt den Fehler ein.<\/p>\n

Was geh\u00f6rt zu einer praktischen Pr\u00fcfung?<\/h3>\n

Eine wiederholbare Pr\u00fcfung dokumentiert die Testentscheidung, den dazugeh\u00f6rigen Dialogzustand, dekodierte Zweck- und Anbietersignale, relevante Einschr\u00e4nkungen und die passende GVL-Fassung. Anschlie\u00dfend zeigt die Netzwerkbeobachtung, ob Verarbeitung und erwartete Entscheidung zusammenpassen. Keine einzelne dieser Pr\u00fcfungen best\u00e4tigt umfassende Rechtskonformit\u00e4t.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n