Benutzer-Werkzeuge

Webseiten-Werkzeuge


dev:all:examples:gtk-charset

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
dev:all:examples:gtk-charset [26.06.2018 22:50] – angelegt Manuela v.d.Deckendev:all:examples:gtk-charset [14.04.2023 15:33] (aktuell) – [UTF8mb4] Manuela v.d.Decken
Zeile 11: Zeile 11:
 Der ASCII-Standard basiert auf einem 7-Bit Code und definiert 128 Zeichen, bestehend aus 33 nicht druckbaren sowie 95 druckbaren Zeichen.\\ Der ASCII-Standard basiert auf einem 7-Bit Code und definiert 128 Zeichen, bestehend aus 33 nicht druckbaren sowie 95 druckbaren Zeichen.\\
 Die druckbaren Zeichen umfassen das lateinische Alphabet in Groß- und Kleinschreibung, die zehn arabischen Ziffern sowie einige Interpunktionszeichen (Satzzeichen, Wortzeichen) und andere Sonderzeichen. Der Zeichenvorrat entspricht weitgehend dem einer Tastatur oder Schreibmaschine für die englische Sprache. Die nicht druckbaren Steuerzeichen enthalten Ausgabezeichen wie Zeilenvorschub oder Tabulatorzeichen, Protokollzeichen wie Übertragungsende oder Bestätigung und Trennzeichen wie Datensatztrennzeichen. Die genauen Spezifikationen dazu sind hier zu finden: [[https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#Kompatible_Zeichenkodierungen|American Standard Code for Information Interchange]]\\ Die druckbaren Zeichen umfassen das lateinische Alphabet in Groß- und Kleinschreibung, die zehn arabischen Ziffern sowie einige Interpunktionszeichen (Satzzeichen, Wortzeichen) und andere Sonderzeichen. Der Zeichenvorrat entspricht weitgehend dem einer Tastatur oder Schreibmaschine für die englische Sprache. Die nicht druckbaren Steuerzeichen enthalten Ausgabezeichen wie Zeilenvorschub oder Tabulatorzeichen, Protokollzeichen wie Übertragungsende oder Bestätigung und Trennzeichen wie Datensatztrennzeichen. Die genauen Spezifikationen dazu sind hier zu finden: [[https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#Kompatible_Zeichenkodierungen|American Standard Code for Information Interchange]]\\
-Fast alle später definierten Standards basieren noch heute auf diesem 7-Bit ASCII-Code. E-Mails werden z.B. grundsätzlich als 7-Bit Code übertragen.+Fast alle später definierten Standards basieren noch heute, 60 Jahre später, auf diesem 7-Bit ASCII-Code. E-Mails werden z.B. grundsätzlich als 7-Bit Code übertragen.
 Mit der fortschreitenden Internationalisierung genügten die verfügbaren 95 Zeichen nicht mehr. Auf Grund dessen wurde der Code um 1 Bit auf 8-Bit erweitert. Das bedeutete, dass 128 zusätzliche Zeichen verfügbar waren. Um jetzt den Unterschiedlichsten Sprachen und Schriften gerecht zu werden, wurde für jede Sprache/Schrift eine eigene Codepage und/oder ISO 8859 entworfen. All diese waren in den ersten 128 Zeichen identisch und in den oberen 128 Zeichen (128-255) wurden die Sprachspezifischen Zeichen abgelegt. Recht schnell genügten auch diese zusätzlichen Zeichen nicht mehr aus. Zumal sich auch das Problem ergab, dass keine 2 Schriften gleichzeitig eingesetzt werden konnten. Mit der fortschreitenden Internationalisierung genügten die verfügbaren 95 Zeichen nicht mehr. Auf Grund dessen wurde der Code um 1 Bit auf 8-Bit erweitert. Das bedeutete, dass 128 zusätzliche Zeichen verfügbar waren. Um jetzt den Unterschiedlichsten Sprachen und Schriften gerecht zu werden, wurde für jede Sprache/Schrift eine eigene Codepage und/oder ISO 8859 entworfen. All diese waren in den ersten 128 Zeichen identisch und in den oberen 128 Zeichen (128-255) wurden die Sprachspezifischen Zeichen abgelegt. Recht schnell genügten auch diese zusätzlichen Zeichen nicht mehr aus. Zumal sich auch das Problem ergab, dass keine 2 Schriften gleichzeitig eingesetzt werden konnten.
 ==== Unicode / UTF ==== ==== Unicode / UTF ====
Zeile 23: Zeile 23:
 Alles in allem: Eine saubere, einfache Sache. Wenn, ja wenn da nicht die ganzen Programmierer mit ihren Werkzeugen wären!!! Alles in allem: Eine saubere, einfache Sache. Wenn, ja wenn da nicht die ganzen Programmierer mit ihren Werkzeugen wären!!!
 Denn diese (also die Werkzeuge) stören sich gewaltig an den 'überflüssigen' Zeichen vor den eigentlichen Daten. Nehmen wir der Einfachheit halber PHP in Verbindung mit einem Webserver.\\ Denn diese (also die Werkzeuge) stören sich gewaltig an den 'überflüssigen' Zeichen vor den eigentlichen Daten. Nehmen wir der Einfachheit halber PHP in Verbindung mit einem Webserver.\\
-Die grundlegende Tätigkeit eines Webservers ist es, aufgerufene Dateien auf der Festplatte zu finden, einzulesen und 1:1 direkt wieder auszugeben. Bestes Beispiel sind hierfür die *.html oder *.txt Dateien. Enthält z.B. eine *html Datei jedoch ein BOM, so wird der Browser dieses als erstes, noch vor dem **''<!doctype html>''** erhalten und auch anzeigen. Auf dem Browser wird das im Quelltext so aussehen: **''<!doctype html>''**. Nicht so schön?? Sag ich auch.\\+Die grundlegende Tätigkeit eines Webservers ist es, aufgerufene Dateien auf der Festplatte zu finden, einzulesen und 1:1 direkt wieder auszugeben. Bestes Beispiel sind hierfür die *.html oder *.txt Dateien. Enthält jedoch z.B. eine *html Datei eine BOM, so wird der Browser dieses als erstes, noch vor dem **''<!doctype html>''** erhalten und auch anzeigen. Auf dem Browser wird das im Quelltext so aussehen: **''<!doctype html>''**. Nicht so schön?? Sag ich auch. Zumal die Zeichenausgabe vor dem Doctype manchen Browser in den Quirks-Modus zwingt, was wiederum Boxmodell und CSS in's Schleudern bringen kann.\\
 In Verbindung mit PHP wird es nicht nur eine optische, sondern bereits eine Funktionsstörung erzeugen. Der Server erkennt anhand der Endung (z.B. *.php), dass er die Datei anders behandeln muss. Er liest die Datei ein und gibt sie direkt zum Browser aus... solange, bis er auf ein **''<?php''** Tag trifft, was bei reinen *.php Dateien lt. Coding Standards in Zeile1/Spalte1 der Fall sein sollte. Von hier ab bis zum ersten **''?>''** Tag, oder falls keines kommt bis zum Dateiende, schickt er die Daten jetzt erst mal zum PHP-Interpreter, der diese als Script behandelt, ausführt und das Ergebnis an den Server zurück gibt, der es zum Browser weiterleitet.\\ In Verbindung mit PHP wird es nicht nur eine optische, sondern bereits eine Funktionsstörung erzeugen. Der Server erkennt anhand der Endung (z.B. *.php), dass er die Datei anders behandeln muss. Er liest die Datei ein und gibt sie direkt zum Browser aus... solange, bis er auf ein **''<?php''** Tag trifft, was bei reinen *.php Dateien lt. Coding Standards in Zeile1/Spalte1 der Fall sein sollte. Von hier ab bis zum ersten **''?>''** Tag, oder falls keines kommt bis zum Dateiende, schickt er die Daten jetzt erst mal zum PHP-Interpreter, der diese als Script behandelt, ausführt und das Ergebnis an den Server zurück gibt, der es zum Browser weiterleitet.\\
 Hat die Datei eine BOM, dann setzt sich die **vor** das <?php und erzeugt dadurch wiederum eine unerwünschte Ausgabe der drei Zeichen ****. Optisch nicht schön, technisch eine Katastrophe, denn durch die Ausgabe kann PHP keine Header mehr senden. Also nix mehr los mit dem allseits beliebten header(location....) oder Cookie setzen... oder.. oder Hat die Datei eine BOM, dann setzt sich die **vor** das <?php und erzeugt dadurch wiederum eine unerwünschte Ausgabe der drei Zeichen ****. Optisch nicht schön, technisch eine Katastrophe, denn durch die Ausgabe kann PHP keine Header mehr senden. Also nix mehr los mit dem allseits beliebten header(location....) oder Cookie setzen... oder.. oder
Zeile 32: Zeile 32:
 Also grundsätzlich: das offizielle UTF-8 (wie es auch in PHP verwendet wird) kann Zeichen mit 1-4 Byte großer Codierung benutzen. Also grundsätzlich: das offizielle UTF-8 (wie es auch in PHP verwendet wird) kann Zeichen mit 1-4 Byte großer Codierung benutzen.
  
-mySQL hat bei der Implementierung damals, als UTF-8 noch nicht so verbreitet war, dieses implementiert. Um Platz zu sparen wurde jedoch nur eine 1-3 Byte große Codierung benutzt.+mySQL hat damals, als UTF-8 noch nicht so verbreitet war, dieses implementiert. Um Platz zu sparen wurde jedoch nur eine 1-3 Byte große Codierung benutzt.
 Nach ein paar Jahren erkannte man, dass man doch den vollen Umfang von UTF-8 benötigt. Eine Anpassung auf 4 Byte war jedoch aus verschiedenen Gründen nicht möglich. Deshalb wurde ein zweites UTF-8 Format, nämlich das UTF8mb4 definiert, das in der Lage ist den vollen UTF-8 Umfang mit 1-4 Bytes aufzunehmen.\\ Nach ein paar Jahren erkannte man, dass man doch den vollen Umfang von UTF-8 benötigt. Eine Anpassung auf 4 Byte war jedoch aus verschiedenen Gründen nicht möglich. Deshalb wurde ein zweites UTF-8 Format, nämlich das UTF8mb4 definiert, das in der Lage ist den vollen UTF-8 Umfang mit 1-4 Bytes aufzunehmen.\\
-//**__Für uns ist es nur wichtig zu wissen, dass das UTF8 von PHP absolut identisch ist zu dem UTF8mb4 von mySQL.__**//+//**__Für uns ist es nur wichtig zu wissen, dass das UTF8 von PHP absolut kompatibel ist zu dem UTF8mb4 von mySQL.__**//
  
  
  
dev/all/examples/gtk-charset.1530053413.txt.gz · Zuletzt geändert: 26.06.2018 22:50 von Manuela v.d.Decken