English
Deutsch
PolskiEinen TC-String lesen: was in den 213 Kopfbits steht
Inhalt
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ür einen korrekten Banner, eine wirksame Einwilligung oder die tatsächliche Beachtung durch einen Anbieter.
Das Format ist kodiert, nicht verschlüsselt. Zum Lesen ist kein geheimer Schlüssel nötig. Auch ein signiertes Prüfprotokoll stellt der String nicht dar. Eine belastbare Prüfung verbindet deshalb die Signale mit dem tatsächlichen Dialog, der passenden Global Vendor List (GVL) und beobachteten Anfragen.
Der feste Anfang: 213 Bit einschließlich der Zwecke
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 und damit das Zeichen C. Ein C am Anfang kennzeichnet dieses Versionsfeld, bestätigt aber nicht die Gültigkeit des restlichen Strings.
Das Kernsegment beginnt mit den folgenden Feldern in genau dieser Reihenfolge. Die Bitpositionen zählen ab null: Position 0 bezeichnet das erste Bit. Der 213-Bit-Anfang enthält die Zweckbits bereits. Anbieterdaten beginnen an Position 213, also beim 214. Bit.
| Feld | Bitpositionen | Länge |
|---|---|---|
Version |
0–5 | 6 |
Created |
6–41 | 36 |
LastUpdated |
42–77 | 36 |
CmpId |
78–89 | 12 |
CmpVersion |
90–101 | 12 |
ConsentScreen |
102–107 | 6 |
ConsentLanguage |
108–119 | 12 |
VendorListVersion |
120–131 | 12 |
TcfPolicyVersion |
132–137 | 6 |
IsServiceSpecific |
138–138 | 1 |
UseNonStandardTexts |
139–139 | 1 |
SpecialFeatureOptIns |
140–151 | 12 |
PurposesConsent |
152–175 | 24 |
PurposesLITransparency |
176–199 | 24 |
PurposeOneTreatment |
200–200 | 1 |
PublisherCC |
201–212 | 12 |
Der feste Anfang endet nach den ersten drei Bit des 36. Base64url-Zeichens. Die übrigen drei Bit gehören bereits zu den Anbieterdaten. 35 Zeichen reichen daher nicht; 36 vollständige Zeichen enthalten schon mehr als den festen Anfang.
Zeitpunkte und Versionen getrennt auswerten
Die Zeitfelder bleiben 36-Bit-Werte in Zehntelsekunden seit der Unix-Epoche. Nach aktueller Spezifikation enthalten Created und LastUpdated jedoch denselben, auf den UTC-Tag begrenzten Änderungszeitstempel. Die Multiplikation mit 100 liefert JavaScript-Millisekunden. Aus der Zahleneinheit folgt keine auf Zehntelsekunden genaue Erfassung der Einwilligung.
Ein altes Änderungsdatum ist Anlass, Erneuerung und Erinnerung zu prüfen. Ein aktuelles Datum belegt umgekehrt keine frische Einwilligung; auch ein Vergleich mit dreizehn Monaten rekonstruiert keine Einwilligungshistorie. Die technische Spezifikation verweist auf Erinnerungen spätestens nach dreizehn Monaten. Der String ersetzt die zugehörigen Nachweise nicht.
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ührt. Ein Wert ab 4 beweist nicht die Umsetzung sämtlicher aktueller Anforderungen. VendorListVersion bezeichnet die verwendete GVL-Fassung, nicht die tatsächliche Anzeige aller darin enthaltenen Anbieter im Dialog.
Anbieterabschnitte: Länge ist kein Zustimmungsmaß
Ein Anbieterabschnitt beginnt mit einer 16-Bit-Höchstnummer und einem Bit für das Kodierungsverfahren. Beim Bitfeld folgt ein Bit je Anbieternummer bis zu dieser Grenze. Die Bereichskodierung ergänzt zunächst eine 12-Bit-Anzahl. Jeder Eintrag enthält ein Bereichskennzeichen und eine 16-Bit-Start- oder Einzelnummer; nur bei einem Bereich folgen weitere 16 Bit für dessen Ende.
Bei Höchstnummer 800 benötigt ein Bitfeld einschließlich Abschnittskopf 817 Bit. Fünfzig einzelne Nummern benötigen als Bereiche 879 Bit: 17 + 12 + 50 × 17. Ein zusammenhängender Bereich benötigt nur 62 Bit: 17 + 12 + 33. Bei Wahl der kürzeren Darstellung gewinnt im ersten Beispiel das Bitfeld, im zweiten die Bereichskodierung. Eine Zustimmung zu allem garantiert daher nicht allgemein einen kurzen String.
Anbietereinwilligungen und Signale zum berechtigten Interesse stehen in getrennten Abschnitten. Einschränkungen des Publishers und zusätzliche Segmente beeinflussen die Gesamtlänge ebenfalls. Ein langer String belegt weder umfassende Zustimmung noch einen Defekt oder besonders viele ausgewählte Anbieter.
Aktuelle Regeln zusätzlich zum Bitformat
TCF 2.2 entfernte berechtigtes Interesse als zulässige Grundlage für die Zwecke 3–6. Für Zweck 1 war bereits Einwilligung als Grundlage vorgesehen; das länderspezifische Kennzeichen PurposeOneTreatment behandelt eine andere Frage. Besondere Zwecke besitzen einen eigenen Nummernraum und gehören nicht in die gewöhnlichen Zweckbits.
Bei den derzeit definierten Zwecken 1–11 stellen die reservierten Positionen 12–24 keine weiteren Auswahlmöglichkeiten dar. Unerwartet gesetzte Bits erfordern einen Abgleich mit der maßgeblichen Spezifikation und GVL. Ein solcher Befund zeigt eine Unstimmigkeit, nicht die Herkunft der Implementierung. Zwecksignale allein erlauben außerdem nicht jedem Anbieter die Verarbeitung: Anbietersignale, Offenlegung, deklarierte Zwecke und Publisher-Einschränkungen gehören zur Auswertung.
TCF 2.3 machte das Segment DisclosedVendors für ab dem 1. März 2026 erzeugte Strings verpflichtend. Für ältere Strings ohne dieses Segment gilt die Übergangsausnahme; 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ühere Typ 2 für erlaubte Anbieter entfiel mit TCF 2.2.
TCF 2.4 ergänzte anschließend überarbeitete Informationen zu Features. Die offizielle Umsetzungsfrist für Webumgebungen endete am 23. Oktober 2026; für 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üfen.
Fragen und Antworten
Ist euconsent-v2 vorgeschrieben?
Nein. Das CMP bestimmt den Speichermechanismus; ein anderer Cookiename oder eine Speicherung ohne Cookie ist möglich. Das Fehlen dieses Cookies belegt weder das Fehlen noch die Korrektheit einer Einwilligungsverwaltung.
Welche Browserschnittstelle eignet sich?
getTCData ist seit TCF 2.2 veraltet. Der unterstützte Weg verwendet addEventListener, prüft den Erfolg des Rückrufs sowie CMP- und Ereigniszustand und liest einen verfügbaren tcString. Während des Ladens kann der erste Rückruf noch unvollständige Daten enthalten. Eine einmalige Diagnose entfernt den Listener nach dem gewünschten Schnappschuss über removeEventListener mit der erhaltenen Listener-ID. Eine Anwendung zur Beobachtung späterer Änderungen benötigt dagegen ein geeignetes fortbestehendes Abonnement.
Wie lassen sich unvollständige Daten erkennen?
Ein Decoder prüft Alphabet, Feldlängen, Eintragszahlen, Bereiche und Segmenttypen. Eine reine Base64-Dekodierung prüft keine Richtlinienkonformität. Bei byteorientierten Decodern erfolgen Alphabetumsetzung und gegebenenfalls Auffüllung für jedes Segment getrennt. Die direkte Übersetzung jedes Zeichens in sechs Bit vermeidet falsche Annahmen über Bytegrenzen.
Fehlende Bits können durch Kopier-, Speicher-, Kodierungs- oder Transportfehler entstehen. Eine Längengrenze ist eine mögliche Ursache, keine Diagnose. RFC 6265 empfiehlt für allgemeine Browser mindestens 4096 Byte je Cookie einschließlich Name, Wert und Attributen; die Formulierung lautet SHOULD, nicht MUST. Zu große Cookies oder Anfrageheader können abgelehnt werden, statt unbemerkt abgeschnitten zu werden. Der Vergleich von gespeichertem Wert, CMP-API-Ausgabe und übertragenem Wert grenzt den Fehler ein.
Was gehört zu einer praktischen Prüfung?
Eine wiederholbare Prüfung dokumentiert die Testentscheidung, den dazugehörigen Dialogzustand, dekodierte Zweck- und Anbietersignale, relevante Einschränkungen und die passende GVL-Fassung. Anschließend zeigt die Netzwerkbeobachtung, ob Verarbeitung und erwartete Entscheidung zusammenpassen. Keine einzelne dieser Prüfungen bestätigt umfassende Rechtskonformität.
Passend dazu
