Fehlerhafte Zeichenkodierung nach Copy&Paste

[Karl Heinz]

Hallo,

bezogen auf einen neuen Kunden (www.bohny-buerobedarf.de) möchte ich Google Analytics auf der Webseite integrieren.

Aus diesem Grund habe ich dem Programmierer des Kunden den Google Analytics Code per E-Mail zugeschickt, mit der Bitte diesen im Quellcode der Webseite einzubinden.

Dies hat der Programmierer getan. Anschließend habe ich mit Hilfe des Google Chrome Plugins „Google Tag Assistant“ überprüft, ob die Einbindung korrekt funktioniert. Leider Fehlanzeige. Der Google Tag Assistant meldet folgende Fehlermeldung:

Invalid or missing Web-Property ID (siehe hierzu nachfolgender Screenshot):

Ich habe die Web-Property-ID überprüft, es ist definitiv die richtige Web-Property-ID gesetzt. Hier der Quellcode der Google Analytics Integration:

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-­106473715­-1', 'auto');
  ga('send', 'pageview');

</script>

Nach einem Telefongespräch mit Google wurde meine Frage an die technische Abteilung von Google eskaliert. Von der technischen Abteilung habe ich nun folgende Rückmeldung per E-Mail erhalten:

Hallo,

Ich habe wie besprochen das Problem mit dem Tag Assistant an unser technisches Spezialistenteam weitergeleitet.

Der Kollege hat mich darüber informiert, dass der Ursprung des Problem bei der Zeichencodierung liegt.

Offensichtlich wurde der Code und die UA-Nummer manuell eingefügt, was wiederum zu einem Codierfehler geführt hat. Sie haben zwar UA-106473715-1 eingetippt, das System hat allerdings UA-106473715%AD-1 erkannt.

Die Empfehlung unseres technischen Spezialistenteam ist es, wenn möglich den Code (oder nur die Property-ID) aus Analytics zu kopieren und direkt wieder in Ihrem Quellcode einzufügen.

Ich hoffe, ich konnte Ihnen auf diesem Wege helfen und wünsche Ihnen noch einen schönen Tag.

Mit freundlichen Grüßen aus Dublin,

Wie ich das Problem lösen kann weiß ich nun, ich habe allerdings noch nicht so richtig verstanden an welcher Stelle sich der Fehler eingeschlichen hat. Wird bei Copy&Paste vom Analytics Backend in eine E-Mail die Zeichenkdierung verändert?

Könnt ihr mir sagen an welcher konkreten Stelle sich das Problem mit der Zeichenkodierung eingeschlichen hat bzw. wie man beim Versand der E-Mail die fehlerhafte Zeichenkodierung vermeiden hätte können?

Viele Grüße

[Auge]

Hallo

Wie ich das Problem lösen kann weiß ich nun, ich habe allerdings noch nicht so richtig verstanden an welcher Stelle sich der Fehler eingeschlichen hat. Wird bei Copy&Paste vom Analytics Backend in eine E-Mail die Zeichenkdierung verändert?

Hinter %AD verbirgt sich das typografisch korrekte Zeichen für das Minus. Das ist ein anderes Zeichen, als das, was der Nutzer über seine Tastatur erreichen kann (zusammen mit dem Unterstrich rechts unten, neben der Shift-Taste bzw. im Zifferblock) und es ist im Kontext der Google-ID offensichtlich das falsche Zeichen.

Könnt ihr mir sagen an welcher konkreten Stelle sich das Problem mit der Zeichenkodierung eingeschlichen hat bzw. wie man beim Versand der E-Mail die fehlerhafte Zeichenkodierung vermeiden hätte können?

Nein, das kann zumindest ich nicht. Ich kann mir aber vorstellen, dass es ein Programm wieder einmal zu gut gemeint hat. MS-Office wandelt ja auch genre mal selbsttätig Zeichen (wie z.B. Anführungszeichen) um. Manchmal greift es auch daneben.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Hinter %AD verbirgt sich das typografisch korrekte Zeichen für das Minus.

Wie kommst du darauf? U+00AD ist der soft hyphen.

LLAP 🖖

[Sophie]

Hallo,

nur eine kleine Anmerkung. In Deutschland muss die IP Adresse anonymisiert werden. Dieses machst du mit dieser Zeile in deinem Code

ga('set', 'anonymizeIp', true);

Das ganze sieht dann fertig folgendermaßen aus

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-­106473715­-1', 'auto');
  ga('set', 'anonymizeIp', true);
  ga('send', 'pageview');

</script>

Wenn du noch mehr zu diesem Thema erfahren willst:

1. https://www.datenschutzbeauftragter-info.de/fachbeitraege/google-analytics-datenschutzkonform-einsetzen/

[Karl Heinz]

Hallo Sophie,

nur eine kleine Anmerkung. In Deutschland muss die IP Adresse anonymisiert werden. Dieses machst du mit dieser Zeile in deinem Code

ga('set', 'anonymizeIp', true);

Ich weiß, das mache ich auch immer, nur im Beispiel weg gelassen. Trotzdem danke.

Nur am Rande: Universal Analytics bzw. analytics.js ist sowieso Vergangenheit :-). Es lebe Globel Site Analytics bzw. gtag.js :-).

Wenn du noch mehr zu diesem Thema erfahren willst:

1. https://www.datenschutzbeauftragter-info.de/fachbeitraege/google-analytics-datenschutzkonform-einsetzen/

Den Artikel kenne ich, der ist prima (gebe ich meinen Kunden öfter mal zum lesen), als Ergänzung noch die Erklärung wie man anonymizeIP für den neuen Global Site Analytics (gtag.js) nutzt:

https://developers.google.com/analytics/devguides/collection/gtagjs/ip-anonymization

[Matthias Apsel]

Hallo Karl Heinz,

Der Kollege hat mich darüber informiert, dass der Ursprung des Problem bei der Zeichencodierung liegt.

Sie haben zwar UA-106473715-1 eingetippt, das System hat allerdings UA-106473715%AD-1 erkannt.

Das ist kein Fehler bei der Zeichenkodierung, sondern ein zusätzliches Zeichen, der bedingte Trennstrich, HTML-Entity ­. Dieses ist im Normalfall unsichtbar. Wie es da hineingekommen ist, kann ich dir nicht sagen.

Bis demnächst
Matthias

[Karl Heinz]

Hallo Matthias,

Das ist kein Fehler bei der Zeichenkodierung, sondern ein zusätzliches Zeichen, der bedingte Trennstrich, HTML-Entity ­.

Stimmt du hast recht ich war blind :-).

Dieses ist im Normalfall unsichtbar.

Welchen Nutzen hat ein unsichtbares Zeichen?

Wie es da hineingekommen ist, kann ich dir nicht sagen.

Ich hatte den Code in meinem Mint System in ein Libre Office Dokument inklusive Beschreibung gepackt und dann in ein PDF umgewandelt. Ich glaube wenn man in Linux eine PDF mit Libre Office erstellt wird hinsichtlich der Zeichenkodierung so einiges zerhauen. Hatte ein ähnliches Problem schonmal mit Libre in Verbindung mit PDFs.

[Matthias Apsel]

Hallo Karl Heinz,

Welchen Nutzen hat ein unsichtbares Zeichen?

Dieses konkret hat den Auftrag, sich ggf. am Zeilenende in einen Trennstrich zu verwandeln. Siehe Wiki/bedingter Trennstrich.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Karl Heinz,

Ich hatte den Code in meinem Mint System in ein Libre Office Dokument inklusive Beschreibung gepackt und dann in ein PDF umgewandelt.

Das ist für Quellcode im Allgemeinen eine ganz schlechte Idee. Sowas würde ich immer als puren Text verschicken.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Karl Heinz

Welchen Nutzen hat ein unsichtbares Zeichen?

Sich anderweitig nützlich zu machen.

U+2060 WORD JOINER bspw.:

• zur Vermeidung falscher Silbentrennung
• zur Vermeidung von Verlinkungen von @… und #… auf Twitter
• zur Vermeidung von Deppenapostrophen auf Twitter, s.a. @g16ns Tweet

LLAP 🖖

[Karl Heinz]

Der Kollege hat mich darüber informiert, dass der Ursprung des Problem bei der Zeichencodierung liegt.

Offensichtlich wurde der Code und die UA-Nummer manuell eingefügt, was wiederum zu einem Codierfehler geführt hat. Sie haben zwar UA-106473715-1 eingetippt, das System hat allerdings UA-106473715%AD-1 erkannt.

Hierzu noch ein Frage:

Wie haben die von Google denn herausgefunden, dass sich bei UA-106473715-1 hinter der 5 noch ein %AD eingeschlichen hat? Schaue ich mir UA-106473715-1 im Quellcode an ist von %AD nichts zu sehen, da steht einfach nur UA-106473715-1. Hinter der 5 keine Spur von %AD.

[Matthias Apsel]

Hallo Karl Heinz,

Wie haben die von Google denn herausgefunden, dass sich bei UA-106473715-1 hinter der 5 noch ein %AD eingeschlichen hat?

http://www.fontspace.com/unicode/analyzer

Bis demnächst
Matthias

[Karl Heinz]

Wie haben die von Google denn herausgefunden, dass sich bei UA-106473715-1 hinter der 5 noch ein %AD eingeschlichen hat?

http://www.fontspace.com/unicode/analyzer

Hallo Matthias,

vermutlich ist der Programmierer her gegangen und hat den Analyitcs-Code bzw. die UA-Nummer, die Bestandteil des Analytics-Codes ist, aus dem PDF-Dokument kopiert und in den Quellcode gepackt.

Um zu prüfen, ob sich an dieser Stelle der Fehler mit den zusätzlichen unsichtbaren Zeichen (dem bedingten Trennstrich) eingeschlichen hat, bin ich her gegangen und habe die UA-Nummer aus dem PDF-Dokument kopiert und in den von Dir verlinkten Unicode Analyzer gepackt. Hierbei fällt mir folgendes auf:

Durch das Kopieren von UA-­106473715­-1 vom PDF in das Eingabefeld von Unicode Analyzer werden die beiden – einfach verschluckt, Sie werden einfach nicht im Eingabefeld angezeigt. Im Eingabefeld vom Unicode Analyzer wird folgendes angezeigt:

UA1064737151

Vermutlich wurden die beiden – aus irgend einem Grund im PDF durch durch den bedingten, nicht sichtbaren Trennstrich, ersetzt. Eine Analyse mit dem Unicode Analyzer bestätigt diese Vermutung.

Aus diesem Grund wird der Programmierer die beiden – (einmal hinter UA und einmal hinter der 5) vermutlich händisch eingegeben haben.

Es ergibt sich demnach folgendes:

UA<Soft Hyphen>-106473715<Soft Hyphen>-1

Das passt dann auch mit der Ausgabe des Unicode Analyzer zusammen.

Demnach hat sich beim Erstellen des PDF Dokumentes irgendwo der Fehler eingeschlichen, sprich das – wurde durch den bedingten nicht sichtbaren Trennstrich ersetzt.

Ich haben den Fehler sogar noch weiter eingrenzen können:

Ich habe ein Libre Office Writer Dokument erstellt und folgende Nummer eintragen: UA-106473715-1

Option 1:

Erstelle ich aus dem Libre Office Writer Dokument sofort ein PDF, ohne die Nummer mit einer anderen Schriftart zu formatieren, bleibt das – im PDF erhalten und wird nicht durch einen bedingten Trennstrich ersetzt.

Option 2:

Ändere ich im Libre Office Writer Dokument zunächst die Schriftart der Nummer UA-106473715-1 in Courier 10 Pitch ist das – im PDF zwar nach wie vor zu sehen, ein Copy und Paste in den Unicode Analyzer zeigt allerdings, dass hier irgendwas schief gelaufen ist. Nach dem Einfügen in die Eingabebox des Unicode Analyzer wird das – nichtmehr angezeigt sondern stattdessen UA1064737151. Im PDF Quell-Dokument wird hingegen UA-106473715-1 angezeigt. Ist das ein Bug im Libre Office PDF Generator?

Wie kann es sein, dass im PDF - angezeigt wird, dieses - aber bei Copy & Paste vom PDF in die Unicode Analyzer Eingabebox verschwindet?