Zeichenkodierung einer Datei auslesen

[Ashura]

Hallo.

Ich überarbeite gerade einen PHP-basierten Dateimanager, in dem erwartungsgemäß auch eine „Editieren“-Funktion enthalten ist.

Da ich nahezu überall UTF-8 als Kodierung wähle, musste ich diese Funktion erst einmal UTF-8 fähig machen (mittels utf8_encode / -_decode und iconv_set_encoding).
Nun werden Dateien also UTF-8-kodiert eingelesen und auch korrekt gespeichert.

Das Problem sind jedoch Dateien, die nicht UTF-8 kodiert sind.
Jegliche Sonderzeichen werden da natürlich falsch dargestellt, weil ja nun einmal UTF-8 erwartet wird.

Nun bin ich also auf der Suche nach einer verlässlichen Methode, die Kodierung einer Datei auszulesen. Habt ihr einen Tipp für mich?
(Die optionale Signatur am Anfang ist kein zuverlässiges Indiz)

Einen schönen Sonntag noch.

Gruß, Ashura

[Tom]

Hello,

Nun bin ich also auf der Suche nach einer verlässlichen Methode, die Kodierung einer Datei auszulesen. Habt ihr einen Tipp für mich?

Da mag ich mich doch glatt anschließen...

Da aber UTF-8 nur eine Untermenge von ASCII ist (also 7bit-Codierung), könnte da doch schon einmal ein Kriterium sein: eine Datei, die auch das achte Bit benutzt, kan  nicht UTF-8 sein. Oder habe ich da was falsch verstanden?

http://de.wikipedia.org/wiki/UTF-8

Diese UTF-8-Kacke kommt mir vor wie ein Virus, der langsam und allmählich die in Jahrzehnten geschaffene Codebasis auffrisst. Leider muss ich mich auch damit auseinandersetzen. Wir weren und hier zu diesem Thema also noch öfter begegenen.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Ashura]

Hallo Tom.

Da aber UTF-8 nur eine Untermenge von ASCII ist (also 7bit-Codierung), könnte da doch schon einmal ein Kriterium sein: eine Datei, die auch das achte Bit benutzt, kan  nicht UTF-8 sein. Oder habe ich da was falsch verstanden?

http://de.wikipedia.org/wiki/UTF-8

Ich werde mir das Ganze noch einmal genau durchlesen, vielleich finde ich ja einen brauchbaren Punkt, an dem ich ansetzen kann.

Diese UTF-8-Kacke kommt mir vor wie ein Virus, der langsam und allmählich die in Jahrzehnten geschaffene Codebasis auffrisst. Leider muss ich mich auch damit auseinandersetzen.

Warum „leider“? Was gefällt dir an der Geschichte mit den erweiterten Zeichensätzen (hier eben UTF-8) nicht?

Wir weren und hier zu diesem Thema also noch öfter begegenen.

Na dann: Happy (En)Coding. :-)

Einen schönen Sonntag noch.

Gruß, Ashura

[Eternius]

Hi,

http://de.wikipedia.org/wiki/UTF-8

Diese UTF-8-Kacke kommt mir vor wie ein Virus, der langsam und allmählich die in Jahrzehnten geschaffene Codebasis auffrisst. Leider muss ich mich auch damit auseinandersetzen. Wir weren und hier zu diesem Thema also noch öfter begegenen.

da kann ich dir nur zustimmen. ich mag es auch nicht besonders, gerade auch, wenn ich mir daten von einer anderen webseite hole, diese in meine webseite einbinde, dann hab ich den salat, wenn die codierung der anderen webseite meiner nicht gleicht. was soll denn das überhaupt? zack, vorgeschrieben es wird ab jetzt nur noch eine codierung verwendet, die alle zeichen enthält. warum muss sich jeder hans wurst auch ne codierung aussuchen, gibts da vorgaben, oder DINs, good practice, oder was auch immer?

gruss

[Ludger]

Hi,

Diese UTF-8-Kacke kommt mir vor wie ein Virus, der langsam und allmählich die in Jahrzehnten geschaffene Codebasis auffrisst.

diese "UTF-8-Kacke" (gemeint wohl eher der Unicode) ist aber so zu sagen die "letzte Kodierung", so zu sagen der letzte Anzug. Und darum eigentlich alles andere als Unicode Kacke.

Gruss,
Ludger

[Tom]

Hello,

Da aber UTF-8 nur eine Untermenge von ASCII ist (also 7bit-Codierung), könnte da doch schon einmal ein Kriterium sein: eine Datei, die auch das achte Bit benutzt, kan  nicht UTF-8 sein. Oder habe ich da was falsch verstanden?

http://de.wikipedia.org/wiki/UTF-8

Sorry, das war falsch.
Es werden alle 8 Bit benutzt.
Das Bit 7 (80h  128d) wird eben zur Kennzeichnung der Umschaltung benutzt...

Der Ansatz von Candid https://forum.selfhtml.org/?t=112485&m=711482 ist da schon besser.

Schau Dir doch den UTF-8-Code mal im Hex-Editor an:

Ich kämpfe mich da gerade durch, wie man utf-8 und PHP unter einen Hut bringt.
Welchen Header sendet der Webserver für die Zeichenkodierung?
Reicht es, das charset im Header zu setzen?
Wer hat Vorrang? Der HTTP-Header oder das Meta-Äquivalent?

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

reicht es, alle Ausgaben, die PHP produziert mit utf8_encode
http://de.php.net/manual/en/function.utf8-encode.php
zu behandeln?

Was passiert mit den Zeichen, die schon mit HTML-Entitäten codiert sind?
Dürfen die drin stehenbleiben? Ist die Codierung dann trotzdem noch eindeutig?
Oder würde es reichen, _nur_ eine UTF-Codierung des Textes vorzunehmen?
also:

echo utf8_encode(htmlspecialchars($wilder_text));

?

Fragen über Fragen.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Sven Rautenberg]

Moin!

Da aber UTF-8 nur eine Untermenge von ASCII ist (also 7bit-Codierung), könnte da doch schon einmal ein Kriterium sein: eine Datei, die auch das achte Bit benutzt, kan  nicht UTF-8 sein. Oder habe ich da was falsch verstanden?

http://de.wikipedia.org/wiki/UTF-8

Sorry, das war falsch.
Es werden alle 8 Bit benutzt.
Das Bit 7 (80h  128d) wird eben zur Kennzeichnung der Umschaltung benutzt...

Auch das ist falsch.

UFT-8 ist keine Untermenge von ASCII. Umgekehrt! ASCII ist eine Untermenge von UTF-8.

Ich kämpfe mich da gerade durch, wie man utf-8 und PHP unter einen Hut bringt.

Das ist eigentlich recht simpel, wenn man nur simple Dinge will. Wenn man kompliziertere Dinge will, muß man UTF-8-fähige oder Unicode-fähige Software einsetzen (bei PHP wäre das Stichwort "mbstring" (Multibyte-String) anzubringen).

Welchen Header sendet der Webserver für die Zeichenkodierung?

Den üblichen. UTF-8 ist äquivalent zu ISO-8859-1 oder Windows-1252 in der Headerverwendung.

Reicht es, das charset im Header zu setzen?
Wer hat Vorrang? Der HTTP-Header oder das Meta-Äquivalent?

Das sollte dir doch eigentlich bekannt sein: HTTP-Header hat Vorrang vor Meta-Angabe.

reicht es, alle Ausgaben, die PHP produziert mit utf8_encode
http://de.php.net/manual/en/function.utf8-encode.php
zu behandeln?

Das kann man so pauschal nicht sagen, denn deine Strings könnten ja bereits UTF-8-codiert sein - ein Encoding wäre also falsch.

Was passiert mit den Zeichen, die schon mit HTML-Entitäten codiert sind?

Entities werden aus Zeichen gebildet, die sich auch mit ASCII darstellen ließen, mithin also in UTF-8 den Bereich >= 0x7F einnehmen.

Dürfen die drin stehenbleiben?

Man darf sie natürlich mit utf8_encode behandelt, das wird sie aber nicht verändern.

Ist die Codierung dann trotzdem noch eindeutig?

Welche Frage verbirgt sich hier?

Oder würde es reichen, _nur_ eine UTF-Codierung des Textes vorzunehmen?
also:

echo utf8_encode(htmlspecialchars($wilder_text));

Hängt davon ab, was in $wilder_text drinsteht - codierungsmäßig.

- Sven Rautenberg

[Tom]

Hello Sven,

Es werden alle 8 Bit benutzt.
Das Bit 7 (80h  128d) wird eben zur Kennzeichnung der Umschaltung benutzt...

Auch das ist falsch.

Nö, das ist jetzt richtig. Ich hatte es ja verkehrt herum geschrieben und hier eben versucht richtigzustellen.

also nochmal in kleinen Schritten:
UTF-8 verwendet alle 8 Bit
ist Bit 7 nicht gesetzt, handelt es sich beim Zeichen sich um ein ASCII-Zeichen
ASCII ist also in UTF-8 eingebettet und damit eine Untermenge davon
  (ich hatte es falsch herum gesagt)
Ist Bit 7 gesetzt und Bit 6 nicht, dann wird das Zeichen in zwei Bytes codiert
Ist Bit 7 gesetzt und Bit 6 und Bit 5 nicht, dann wird das Zeichen in drei Bytes codiert
Ist Bit 7 gesetzt und Bit 6 und Bit 5 und Bit 4 nicht, dann wird das Zeichen in vier Bytes codiert

Da Bit 7 immer nur gesetzt sein kann, wenn ein Zeichen beginnt, ist UTF-8 selbstsynchoniesierend.

Ich kämpfe mich da gerade durch, wie man utf-8 und PHP unter einen Hut bringt.

Das ist eigentlich recht simpel, wenn man nur simple Dinge will. Wenn man kompliziertere Dinge will, muß man UTF-8-fähige oder Unicode-fähige Software einsetzen (bei PHP wäre das Stichwort "mbstring" (Multibyte-String) anzubringen).

Ich will eine viersprachige Webseite bauen, die ggf. auch alle vier Sprachen _gleichzeitig_ anzeigen können soll.

Setzt das jetzt voraus, dass die entsprechenden Zeichensätze zur Verfügung stehen, oder unterstützen Browser, die UTF-8 interpretieren können automatisch alle darstellbaren Zeichen?
Ich würde vermutren, dass nein ;-)

Was passiert also, wenn man in UTF-8 die wilden Zeichen irgendwelcher Aliens codiert hat und nun die Seite in USA anschaut. Die kennen da ja nur sich... Soll heißen, der Alienzeichnsatz ist nicht installiert. Kommen dann die hübschen Kästchen auf den Schirm?

Nächste Frage:
Mit welchem Editor und welcher Tastatur und welchen OS-Einstellungen bekomme ich denn die Alien-Texte überhaupt in die Maschine?

Welchen Header sendet der Webserver für die Zeichenkodierung?

Den üblichen. UTF-8 ist äquivalent zu ISO-8859-1 oder Windows-1252 in der Headerverwendung.

Das kann ich so nicht nachvollziehen.
Als ich

<?php  ### make_utf-8.php ###

error_reporting(E_ALL);
define('CRLF',chr(13).chr(10));

$text = "Die ärgerliche Straßenkrümmumg ödet uns an. Ein Ölfleck auf dem Ärmel lässt sich nicht überbügeln";

$fh = fopen('utf8-output.txt','a+');
fwrite ($fh, utf8_encode($text).CRLF);
fclose($fh);

header('Content-Type: text/html; charset=UTF-8');

echo utf8_encode($text);
?>

dieses Scriptchen eben ohne den Content-Type-Header benutzt habe, und dann mit
http://web-sniffer.net/?url=
aufgerufen habe, kam nur Müll in der Browseranzeige an. Charset war ISO-8859-1. Genauso hatte ich es auch erwartet.

Mit dem Header hat der Browser auch artig gezeigt, was er sollte und der Web-Sniffer hat auch brav den passenden Header angezeigt (*logisch*).

Reicht es, das charset im Header zu setzen?

Scheint also der richtige Weg zu sein.
Alternativ könnte man natürlich den VirtHost entsprechend konfigurieren.

Wer hat Vorrang? Der HTTP-Header oder das Meta-Äquivalent?
Das sollte dir doch eigentlich bekannt sein: HTTP-Header hat Vorrang vor Meta-Angabe.

Danke. Ich probiers aber trotzdem nochmal selber aus. Darum heiße ich ja Thomas *g*

reicht es, alle Ausgaben, die PHP produziert mit utf8_encode
http://de.php.net/manual/en/function.utf8-encode.php
zu behandeln?

Das kann man so pauschal nicht sagen, denn deine Strings könnten ja bereits UTF-8-codiert sein - ein Encoding wäre also falsch.

Das ist jetzt der spannende Teil.
Im ersten Moment habe ich gedacht: Nö, der Sven spinnt...
Aber leider spinnt der nicht, sondern mein Problem ist größer, als ursprünglich angenommen:

Wenn ich mit Templates arbeite, und mich überall auf ASCII beschränke, dann kann ich die
  abspeichern in was ich will (UTF-8 oder ANSI, ...). Das Bitmuster siehr überall genauso
  aus.

Wenn ich nun von PHP die Platzhalter ersetzen lasse, muss ich wissen, in welcher Codierung
  die in der Datenbasis stehen. Um dort sinnvoll sortieren zu können, sollte die DB wissen,
  dass sie nun utf-8 enthält, oder?

Beim Arbeiten mit Flatfiles müsste es doch egal sein. Nur wie bekomme ich Türkische Zeichen
  in mein Textpad? Woher weiß mein Editor auf einem deutschen Computer, dass er den Zeichen-
  Quellcode nun plötzlich als Türksiche Zeichen interpretieren soll zum Konvertieren in utf-8
  und Wegschreiben ins Flatfile?

Was passiert mit den Zeichen, die schon mit HTML-Entitäten codiert sind?
Dürfen die drin stehenbleiben?

Entities werden aus Zeichen gebildet, die sich auch mit ASCII darstellen ließen, mithin also in UTF-8 den Bereich >= 0x7F einnehmen.
Man darf sie natürlich mit utf8_encode behandelt, das wird sie aber nicht verändern.

Klar. Ergibt sich aus den anderen Überlegungen...

Ist die Codierung dann trotzdem noch eindeutig?
Welche Frage verbirgt sich hier?

Wie könnte ich es hinbekommen, innerhalb _einer_ PHP-Quelldatei Ausgabefunktionen sowohl für Deutschen Text, als auch für Türkisch und 'Alienesisch' zu erfassen?

Darf ich die Alien-Zeichen dann alle mittels "Einfügen Sonderzeichen" anreihen? Gibts Editoren, die während der Arbeit (ohne die Datei schließen zu müssen) das Umschalten des Zeichensatzes erlauben?

Schön wäre dann natürlich auch das Umschalten der Tastatur. Gibt es Tastaturumschalter, die den Betrieb von _mehreren_ Tastaturen an _einem_ PC ermöglichen?

Alternativ muss man die Inhalte sonst eben wirklich _alle_ auslagern.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Sven Rautenberg]

Moin!

UTF-8 verwendet alle 8 Bit

Stimmt.

ist Bit 7 nicht gesetzt, handelt es sich beim Zeichen sich um ein ASCII-Zeichen

Das würde ich so nicht formulieren, weil es etwas mischt, was man nicht mischen sollte.

UTF-8 ist eine Codierungsform für Unicode-Zeichen. Diese umfassen selbstverständlich auch die Zeichen, die man als ASCII-Zeichen kennt.

Das Problem deiner Mischung ist nur: ASCII ist ein für 7-Bit-Zeichen definierter, sehr eingeschränkter Zeichensatz aus 128 verschiedenen Zeichen (ein großer Anteil nicht-druckbare Sonderzeichen wie Tabulatoren, Druckersteuerungen etc. ist auch dabei).

Unicode hingegen umfaßt sämtliche Zeichen. Es ist ein Feature von UTF-8, dass es hinsichtlich der Zeichencodes für diese "ASCII-Zeichen" kompatibel ist, aber ich würde einen UTF-8-String trotzdem nicht als ASCII-String bezeichenen wollen, denn diese Tatsache ändert absolut nichts an der Behandlung solcher UTF-8-Strings.

Ein vermeintliches ASCII-Zeichen in UTF-8 ist nichts, was eine Sonderregelung erfordert - warum dann eine Sonderbezeichnung?

ASCII ist also in UTF-8 eingebettet und damit eine Untermenge davon   (ich hatte es falsch herum gesagt)

Beides richtig. :)

Ist Bit 7 gesetzt und Bit 6 nicht, dann wird das Zeichen in zwei Bytes codiert Ist Bit 7 gesetzt und Bit 6 und Bit 5 nicht, dann wird das Zeichen in drei Bytes codiert Ist Bit 7 gesetzt und Bit 6 und Bit 5 und Bit 4 nicht, dann wird das Zeichen in vier Bytes codiert

Da Bit 7 immer nur gesetzt sein kann, wenn ein Zeichen beginnt, ist UTF-8 selbstsynchoniesierend.

Das ist wieder alles falsch. Ein Multibyte-Zeichen beginnt dort, wo Bit 7 und 6 gesetzt sind. Die Folgebytes haben Bit 7 gesetzt, Bit 6 ungesetzt.

Ein Zeichen aus zwei Bytes beginnt mit 110x xxxx im ersten Byte. Ein Zeichen aus drei Bytes beginnt mit 1110 xxxx im ersten Byte. Ein Zeichen aus vier Bytes beginnt mit 1111 0xxx im ersten Byte.

Alle Folgebytes bestehen aus 10xx xxxx.

Ich will eine viersprachige Webseite bauen, die ggf. auch alle vier Sprachen gleichzeitig anzeigen können soll.

Das ist simpel.

Setzt das jetzt voraus, dass die entsprechenden Zeichensätze zur Verfügung stehen, oder unterstützen Browser, die UTF-8 interpretieren können automatisch alle darstellbaren Zeichen? Ich würde vermutren, dass nein ;-)

Das Betriebssystem benötigt natürlich einen oder mehrere Fonts, welche dafür sorgen, dass eine vernünftige Zeichendarstellung möglich wird. Dabei besteht sogar die Möglichkeit (siehe in den Opera-Zeichensatzeinstellungen), für verschiedene Unicode-Bereiche verschiedene Fonts zu verwenden - das macht der Browser aber im Allgemeinen automatisch. Hast du beispielsweise nur einen einzigen Font für chinesische Zeichen installiert und wählt "Tahoma" als Schriftart, welche kein Chinesisch kann, wird in der Regel im Stillen einfach dein einziger chinesischer Zeichensatz gewählt, wenn du chinesisch schreibst.

Mit anderen Worten: Einfach alle gewünschten Unicode-Zeichen als UTF-8 in die Seite schreiben, und sie werden in der gegebenen Reihenfolge ohne Probleme angezeigt.

Was passiert also, wenn man in UTF-8 die wilden Zeichen irgendwelcher Aliens codiert hat und nun die Seite in USA anschaut. Die kennen da ja nur sich... Soll heißen, der Alienzeichnsatz ist nicht installiert. Kommen dann die hübschen Kästchen auf den Schirm?

Klar, dann kommen Kästchen auf den Bildschirm. Der Firefox mal dort hinein IIRC sogar die Hex-Codes der Unicodezeichen, so dass man eventuell nachgucken kann.

Einerseits: Wer nicht in der Lage ist, eine ausländische Sprache zu lesen, und sich deshalb nicht drum kümmert, dessen ausländische Zeichenformen als Font zu installieren, der wird sich kaum drum kümmern, dass stattdessen die Quadrate angezeigt werden. Er könnte es ja ohnehin nicht lesen.

Andererseits: Windows liefert gewisse Fonts wie Arial durchaus als Unicodefont mit aus (welche allerdings nicht den gesamten Unicode-Zeichensatz abdecken - das wäre wohl auch etwas zuviel verlangt). Die Lage ist also nicht komplett hoffnungslos.

Mit welchem Editor und welcher Tastatur und welchen OS-Einstellungen bekomme ich denn die Alien-Texte überhaupt in die Maschine?

Du benötigst irgendetwas, was unicodefähig ist und UTF-8 speichern/senden kann.

Empfehlenswert: Dein Webbbrowser mit einer Textarea. Alternativ: "Unired" als Freeware-Unicode-Editor (mit Syntax-Highlighting), falls du diese Textarea schon mit einer Unicode-HTML-Seite zusammensetzen willst. Alternativ-alternativ: Der Windows-Notepad ab Win2000 kann auch problemlos mit Unicode umgehen.

Welchen Header sendet der Webserver für die Zeichenkodierung?

Den üblichen. UTF-8 ist äquivalent zu ISO-8859-1 oder Windows-1252 in der Headerverwendung.

Das kann ich so nicht nachvollziehen.

Soll heißen: UTF-8 erfordert im Vergleich zu den beiden anderen genannten keine Sonderbehandlung.

Als ich

<?php  ### make_utf-8.php ###

error_reporting(E_ALL); define('CRLF',chr(13).chr(10));

$text = "Die ärgerliche Straßenkrümmumg ödet uns an. Ein Ölfleck auf dem Ärmel lässt sich nicht überbügeln";

$fh = fopen('utf8-output.txt','a+'); fwrite ($fh, utf8_encode($text).CRLF); fclose($fh);

header('Content-Type: text/html; charset=UTF-8');

echo utf8_encode($text); ?>

dieses Scriptchen eben ohne den Content-Type-Header benutzt habe, und dann mit http://web-sniffer.net/?url= aufgerufen habe, kam nur Müll in der Browseranzeige an. Charset war ISO-8859-1. Genauso hatte ich es auch erwartet.

Mit dem Header hat der Browser auch artig gezeigt, was er sollte und der Web-Sniffer hat auch brav den passenden Header angezeigt (logisch).

Ja klar ist das logisch. Wenn du irgendeine Bytefolge an den Browser sendest, und ihm nicht mitteilst, welche Codierungsform den Bytes zugrunde liegt, führt das fast immer zu Müllergebnissen.

PHP könnte ein Default-Encoding mitsenden, der Browser könnte eines verwenden, oder er könnte auch per Automatik versuchen zu raten, was gesendet wurde.

Reicht es, das charset im Header zu setzen?

Scheint also der richtige Weg zu sein. Alternativ könnte man natürlich den VirtHost entsprechend konfigurieren.

Ich empfehle dringend, immer auch einen gleichlautenden Meta-Eintrag mitzusenden. Dann geht die Information "UTF-8" nicht verloren, wenn die Seite z.B. auf Festplatte abgespeichert wird.

Das kann man so pauschal nicht sagen, denn deine Strings könnten ja bereits UTF-8-codiert sein - ein Encoding wäre also falsch.

Das ist jetzt der spannende Teil. Im ersten Moment habe ich gedacht: Nö, der Sven spinnt... Aber leider spinnt der nicht, sondern mein Problem ist größer, als ursprünglich angenommen:

Wenn ich mit Templates arbeite, und mich überall auf ASCII beschränke, dann kann ich die abspeichern in was ich will (UTF-8 oder ANSI, ...). Das Bitmuster siehr überall genauso aus.

Logisch, da die Bytes von ASCII-Zeichen gleichzeitig auch gültige UTF-8-Zeichen sind.

Wenn ich nun von PHP die Platzhalter ersetzen lasse, muss ich wissen, in welcher Codierung die in der Datenbasis stehen.

Es ist schlau, sämtliche Daten in UTF-8 abzuspeichern bzw. diese EINMALIG dorthin zu konvertieren.

Um dort sinnvoll sortieren zu können, sollte die DB wissen, dass sie nun utf-8 enthält, oder?

Jein.

UTF-8 selbst besitzt die magische Eigenschaft, dass es sich als String auch ohne Kenntnis über Multibyte-Zeichen sortieren läßt - und zwar basierend auf den Zeichencodes aufsteigend.

Allerdings ist diese Sortierung nicht unbedingt die, welche für die verwendete Sprache zum Einsatz kommen sollte.

Allein im Deutschen haben wir ja schon mindestens zwei Sortierformen laut DIN:

1. Die Umlaute ä, ö und ü werden alphabetisch wie a, o und u behandelt.
2. Die Umlaute werden wie "ae", "oe" und "ue" behandelt.

Beide Sortierungen lassen sich mit einer schlichten, bytecodebasierten Sortierung NICHT realisieren, sondern da werden die Umlaute immer hinter das Z sortiert.

Sofern du also kompliziertere Sortierungen wünschst, mußt du einen dafür passenden Sortieralgorithmus verwenden. MySQL 4.1 erlaubt sowohl die Verwendung von UTF-8 (kann damit also wirklich etwas anfangen), als auch die Definition, nach welcher Sortierung vorgegangen werden soll (collation genannt).

Beim Arbeiten mit Flatfiles müsste es doch egal sein.

Nein, ganz und gar nicht! Auch Flatfiles produzieren, genau wie Datenbanken, lediglich Strings, die im Skript verwendet werden.

Nur wie bekomme ich Türkische Zeichen in mein Textpad?

Es gibt zwei Methoden:

1. Du tippst die Zeichen ein.
2. Du öffnest irgendeine Datei, in der diese Zeichen schon enthalten sind, mit dem dazu passenden Programm (beispielsweide dem Browser oder einer Textverarbeitung) und gehst beispielsweise über die Zwischenablage (Copy&Paste).

Wenn dein Textpad nicht unicodefähig ist, dann wird das aber nicht funktionieren.

Woher weiß mein Editor auf einem deutschen Computer, dass er den Zeichen-Quellcode nun plötzlich als Türksiche Zeichen interpretieren soll zum Konvertieren in utf-8 und Wegschreiben ins Flatfile?

Ein unicodefähiger Editor betrachtet sämtliche eingetippten Zeichen als Unicode-Zeichen und speichert sie intern im RAM in einer passenden Form. Dies wird wahrscheinlich NICHT als UTF-8 geschehen, sondern vielleicht als UTF-16 oder gar UTF-32 (letzteres würde ich jedenfalls machen, weil dann jedes Zeichen genau 4 Byte lang ist, und man mit den Zeichenlängen nicht ins Schleudern kommen kann).

Will man die Texte dann speichern, wird das RAM-Abbild konvertiert in die gewünschte Zeichendarstellung. Dabei kann man dann den Text sowohl als UTF-8 speichern, als auch (sofern die Zeichen da reinpassen) als ISO-8859-1 o.ä.

Beim Öffnen bestehender Texte muß man natürlich mit angeben, als was die Datei codierungsmäßig zu interpretieren ist - sofern nicht am Dateianfang die "BOM" (Byte order mark) gefunden wird, welche relativ eindeutig besagt, dass es sich um eine Unicode-Codierung handelt, und um welche.

Mit der BOM kann man eindeutig UTF-32, UTF-16 und UTF-8 auseinanderhalten, und nur wenn eine eigene Textdatei zufällig eine dieser Bytemuster am Anfang enthält (was für Texte extrem unwahrscheinlich ist, viel wahrscheinlicher ist das bei Binärdateien, die man fälschlich für Texte hält), würde diese Erkennung fehlschlagen.

Ist die Codierung dann trotzdem noch eindeutig? Welche Frage verbirgt sich hier?

Wie könnte ich es hinbekommen, innerhalb einer PHP-Quelldatei Ausgabefunktionen sowohl für Deutschen Text, als auch für Türkisch und 'Alienesisch' zu erfassen?

Wenn du UTF-8-Strings hast, ist die damit geschriebene Sprache irrelevant. Jedenfalls programmseitig.

Darf ich die Alien-Zeichen dann alle mittels "Einfügen Sonderzeichen" anreihen? Gibts Editoren, die während der Arbeit (ohne die Datei schließen zu müssen) das Umschalten des Zeichensatzes erlauben?

Du kannst deine Tastaturbelegung live umschalten. Windows zeigt dazu in der Taskleiste ein passendes Symbol an. Die ganze Chose findest du, wenn du neue Tastaturlayouts installierst.

Schön wäre dann natürlich auch das Umschalten der Tastatur. Gibt es Tastaturumschalter, die den Betrieb von mehreren Tastaturen an einem PC ermöglichen?

Keine Ahnung, aber ich schätze, dass ein simpler Tastaturumschalter allein dir nichts bringt, du wirst auch dein OS davon in Kenntnis setzen müssen, dass die Scancodes der Tastatur plötzlich anders zu interpretieren sind.

Alternativ muss man die Inhalte sonst eben wirklich alle auslagern.

Das ist doch sowieso keine schlechte Idee, oder?

- Sven Rautenberg

[Tom]

Hello Sven,

so langsam werden Wirklichkeit und Vorstellung konvergent *freu*

Ist Bit 7 gesetzt und Bit 6 nicht, dann wird das Zeichen in zwei Bytes codiert
Ist Bit 7 gesetzt und Bit 6 und Bit 5 nicht, dann wird das Zeichen in drei Bytes codiert
Ist Bit 7 gesetzt und Bit 6 und Bit 5 und Bit 4 nicht, dann wird das Zeichen in vier Bytes codiert

ups, hätte ich eigentlich sehen müssen in den selber von mir zitierten Dokus (PHP und Wiki)

Ein Zeichen aus zwei Bytes beginnt mit 110x xxxx im ersten Byte.
Ein Zeichen aus drei Bytes beginnt mit 1110 xxxx im ersten Byte.
Ein Zeichen aus vier Bytes beginnt mit 1111 0xxx im ersten Byte.

Alle Folgebytes bestehen aus 10xx xxxx.

Einerseits: Wer nicht in der Lage ist, eine ausländische Sprache zu lesen, und sich deshalb nicht drum kümmert, dessen ausländische Zeichenformen als Font zu installieren, der wird sich kaum drum kümmern, dass stattdessen die Quadrate angezeigt werden. Er könnte es ja ohnehin nicht lesen.

Sollte man also bei gemsischtsprachlichen Texten im Title-Tag einen ASCII-Text (englisch) hinterlegen? Sonst würde man sich ggf. wundern, was denn die hübschen Kästchen dort sollen.
Haben denn wohl alle Browser dieser Welt (die verbreiteten) mindestens den ASCII-Zeichnsatz als gemeinsame Basis? Ich bin noch nie in China gewesen bzw. habe noch kein chinesich eingerichtetes Gerät zu sehen bekommen.

Mit welchem Editor und welcher Tastatur und welchen OS-Einstellungen bekomme ich denn die Alien-Texte überhaupt in die Maschine?

Du benötigst irgendetwas, was unicodefähig ist und UTF-8 speichern/senden kann.

Empfehlenswert: Dein Webbbrowser mit einer Textarea.
Alternativ: "Unired" als Freeware-Unicode-Editor (mit Syntax-Highlighting), falls du diese Textarea schon mit einer Unicode-HTML-Seite zusammensetzen willst.
Alternativ-alternativ: Der Windows-Notepad ab Win2000 kann auch problemlos mit Unicode umgehen.

Die Idee mit dem Browser hatte ich auch schon.
Da ich ohnehin Templates baue, wollte ich versuchen, Zur Bearbeitung eine "Musterseite" anzeigen zu lassen, in der die auszufüllenden Elemente in ihrer Mindestgröße angezeigt werden. Man kann dann hineinklicken und bekommt das Eingabefenster und darüber den Vorlagetext aus der eingestellten Muttersprache. Schön wäre es, wenn man dem Browser nun sagen könnte, dass er die in der Textarea eingegeben Zeichen gleich im Zeichensatz der Zielsprache darstellen soll ;-))

Reicht es, das charset im Header zu setzen?

Scheint also der richtige Weg zu sein.
Alternativ könnte man natürlich den VirtHost entsprechend konfigurieren.

Ich empfehle dringend, immer auch einen gleichlautenden Meta-Eintrag mitzusenden. Dann geht die Information "UTF-8" nicht verloren, wenn die Seite z.B. auf Festplatte abgespeichert wird.

Der Tipp ist Gold wert. Daran hätte ich jetzt nicht gedacht.

Wenn ich nun von PHP die Platzhalter ersetzen lasse, muss ich wissen, in welcher Codierung die in der Datenbasis stehen.

Es ist schlau, sämtliche Daten in UTF-8 abzuspeichern bzw. diese EINMALIG dorthin zu konvertieren.

Genau das kam mir in den Sinn. Allerdings wusste ich nicht, dass die 'natural order' der Zeichen im Gesamtzeichensatz auch der normalen Sortierreihenfolge in der jeweiligen Teilmmenge der Sprache genügt.

Beim Arbeiten mit Flatfiles müsste es doch egal sein.

Nein, ganz und gar nicht! Auch Flatfiles produzieren, genau wie Datenbanken, lediglich Strings, die im Skript verwendet werden.

Da haben wir und hoffentlich verkehrt verstanden. Die Flatfiles speichern doch lediglich einen Bytestream. Wie der vorbereitet wurde und demnach tunlichst nach dem Ausleden auch wieder interpretiert werden soll, ist doch Sache der Applikation, oder?
Ich will hoffen, dass PHP hier transparent arbeitet und nicht irgendeinen "Cooked Mode" eingebaut hat!

Wenn dein Textpad nicht unicodefähig ist, dann wird das aber nicht funktionieren.

Textpad kann UTF-8 abspeichern.
Es kann auch UTF-8 als Byte-Code anzeigen. Das gibt dann eben den "Datenmüll"

Bei dieser Gelgenheit: Wie kann ich dem IE6 abgewöhnen, dass er den "Quellcode" bereits durch die Decodierung jagt, bevor er ihn anzeigt? Ich würde ihn gerne als Bytecode (also 'ASCII') sehen können.

Fragt sich nun nur, woher ich mal eben schnell einen türkischen Zeichensatz zum testen bekomme.
Allerdings müsste die Sprachunterstützung vom Browser sowas ja mitbringen, oder?

Beim Öffnen bestehender Texte muß man natürlich mit angeben, als was die Datei codierungsmäßig zu interpretieren ist - sofern nicht am Dateianfang die "BOM" (Byte order mark) gefunden wird, welche relativ eindeutig besagt, dass es sich um eine Unicode-Codierung handelt, und um welche.

Mit der BOM kann man eindeutig UTF-32, UTF-16 und UTF-8 auseinanderhalten, und nur wenn eine eigene Textdatei zufällig eine dieser Bytemuster am Anfang enthält (was für Texte extrem unwahrscheinlich ist, viel wahrscheinlicher ist das bei Binärdateien, die man fälschlich für Texte hält), würde diese Erkennung fehlschlagen.

Das beantwortet ja auch fast vollständig die Frage des OP.

Wie sieht diese BOM aus? Kann man das was nachlesen? Irgendwann hatte ich das schonmal gelsen *umpf*

Du kannst deine Tastaturbelegung live umschalten. Windows zeigt dazu in der Taskleiste ein passendes Symbol an. Die ganze Chose findest du, wenn du neue Tastaturlayouts installierst.

Dann sollte das jetzt langsam Form annehmen ;-)

Alternativ muss man die Inhalte sonst eben wirklich _alle_ auslagern.

Das ist doch sowieso keine schlechte Idee, oder?

Nö. Das war die Grundidee. Nur als ich heute endlich damit anfing, habe ich mich gefragt, wie ich das machen könnte.

Ich werde jetzt folgendermaßen vorgehen:

Jede Seite erhält ein eingenes Subdirectory
in jedem Subdir wird eine index.php liegen
in jedem Subdir gibt es ein Template (.ht_template)
in jedem Subdir gibt es eine Content-Datei (.ht_content)

Template aufbauen.
Template-Editor aufbauen
  Der sucht alle Platzhalter aus dem Template heraus und erstellt daraus
  pro Sprache ein PHP-Array
  Bereits vorhandene Inhalte werden übernommen
  Die Seite wird mit "Blindtext" angezeigt, wenn keine Inhalte vorhanden sind
  Man kann in die Blindtexte klicken und damit ein Edit-Window öffnen
Die Inhalte können abgespeichert werden.

Die gesamte Struktur (Verzeichnisbaum) wird vorerst noch in englisch gehalten sein.

Wenn ich's zum Laufen bringe, wird als nächstes noch mittels Mod_Rewrite die Verzeichnisstruktur auf die betroffene Sprache angepasst...

Schaun wir mal.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Tom]

Hello,

Sorry, das sollte natürlich heißen:

Sollte man also bei gemischtsprachlichen Texten im Title-Attribut

dabei fällt mir noch ein:
Darf man eigentlich

<title><!-- Kommentar -->Titelstring</title>

schreiben?

Das mögen die Browser nämlich nicht und zeigen dann den Kommentar mit an.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[wahsaga]

hi,

Darf man eigentlich
  <title><!-- Kommentar -->Titelstring</title>
schreiben?

Das mögen die Browser nämlich nicht und zeigen dann den Kommentar mit an.

damit verhalten sie sich korrekt.

title hat #PCDATA als inhaltstyp.

gruß,
wahsaga

[Ashura]

Hallo Tom.

Mit der BOM kann man eindeutig UTF-32, UTF-16 und UTF-8 auseinanderhalten, und nur wenn eine eigene Textdatei zufällig eine dieser Bytemuster am Anfang enthält (was für Texte extrem unwahrscheinlich ist, viel wahrscheinlicher ist das bei Binärdateien, die man fälschlich für Texte hält), würde diese Erkennung fehlschlagen.

Das beantwortet ja auch fast vollständig die Frage des OP.

Nein, wie ich schon sagte:

(Die optionale Signatur am Anfang ist kein zuverlässiges Indiz)

Einen schönen Montag noch.

Gruß, Ashura

[Sven Rautenberg]

Moin!

Sollte man also bei gemsischtsprachlichen Texten im Title-Tag einen ASCII-Text (englisch) hinterlegen? Sonst würde man sich ggf. wundern, was denn die hübschen Kästchen dort sollen.

Hängt von der Situation ab. Kann ein Chinese englisch? Kann der mit englischen Worten bzw. Worten, die in lateinischen Buchstaben geschrieben wurden, etwas anfangen? Wenn ja, oder wenn egal, dann kannst du gerne nur ASCII in den Titel schreiben. Bedenke aber: Auch die deutschen Umlaute dürften dann nicht dort hinein. :)

Haben denn wohl alle Browser dieser Welt (die verbreiteten) mindestens den ASCII-Zeichnsatz als gemeinsame Basis? Ich bin noch nie in China gewesen bzw. habe noch kein chinesich eingerichtetes Gerät zu sehen bekommen.

Ich würde genau das behaupten. Computer und deren Zeichen sind im Grundsatz eine amerikanische Erfindung gewesen, deswegen auch "ASCII" = "American Standard Code for Information Interchange". :)

Diese elementare Grundlage konnte von keinem Hersteller mehr ignoriert werden. Selbst die Chinesen und Japaner benötigen ASCII-Buchstaben und -Zahlen für die Darstellung diverser ausländischer Worte und Bezeichnungen. Die ASCII-Zeichen also zu entfernen wäre reichlich blödsinnig.

Man kann dann hineinklicken und bekommt das Eingabefenster und darüber den Vorlagetext aus der eingestellten Muttersprache. Schön wäre es, wenn man dem Browser nun sagen könnte, dass er die in der Textarea eingegeben Zeichen gleich im Zeichensatz der Zielsprache darstellen soll ;-))

Das ist schlicht Aufgabe des Tastaturtreibers, die richtigen Zeichen zu produzieren, nicht Aufgabe des Browsers.

Stell' deine Tastatur richtig ein, so dass Tastendrücke türkische Zeichen produzieren, und alles wird perfekt funktionieren. Der Browser wird dir automatisch die richtige, utf-8-codierte Darstellung senden.

Da haben wir und hoffentlich verkehrt verstanden. Die Flatfiles speichern doch lediglich einen Bytestream. Wie der vorbereitet wurde und demnach tunlichst nach dem Ausleden auch wieder interpretiert werden soll, ist doch Sache der Applikation, oder?

Im Prinzip ja, dasselbe findet aber auch bei Datenbanken statt.

Ich will hoffen, dass PHP hier transparent arbeitet und nicht irgendeinen "Cooked Mode" eingebaut hat!

PHP interpretiert kein Unicode, jedenfalls noch nicht (bezogen auf Versionen bis 4.4.0, mit 5 habe ich noch nicht gearbeitet). PHP arbeitet nur mit Bytestrings, deren Zeichenbedeutung nicht festgelegt ist.

Im Gegensatz dazu arbeitet ASP beispielsweise sehr wohl mit Unicode. Sämtliche Strings sind im Unicode abgelegt, unabhängig von UTF-8 ist dort ein Zeichen, auch wenn es aus mehreren UTF-8-Bytes besteht, immer genau ein Zeichen (bezogen auf strlen() beispielsweise) und ergibt den Unicode-Zahlencode, wenn man ord() drauf anwendet. Man arbeitet einfach ganz natürlich mit "Zeichen", ohne sich bei der Verarbeitung irgendeinen Kopf über die Codierung zu machen. Lediglich bei den Schnittstellen, also beim Kontakt zu Datenbanken, Dateien und Richtung Browser muß man natürlich definierte Zustände haben. Ganz praktisch ist, dass ASP automatisch passende Ausgabeformatierungen erstellt, wenn man sagt, dass die Ausgabe als ISO-8859-1 erfolgen soll, oder eben als UTF-8. Sowas automatisches fehlt bei PHP leider noch - ein Punkt, bei dem das kommerzielle Produkt mal eindeutig dem Open-Source voraus ist.

Textpad kann UTF-8 abspeichern.
Es kann auch UTF-8 als Byte-Code anzeigen. Das gibt dann eben den "Datenmüll"

Und PHP "sieht" auch nur den Byte-Code - aber wenn das Programm den nicht verstehen muß, kann der wunderbar einfach zum Browser durchgeschleust werden, und wird dort bei der HTTP-Angabe "utf-8" korrekt interpretiert.

Bei dieser Gelgenheit: Wie kann ich dem IE6 abgewöhnen, dass er den "Quellcode" bereits durch die Decodierung jagt, bevor er ihn anzeigt? Ich würde ihn gerne als Bytecode (also 'ASCII') sehen können.

Das ist kein Bug, sondern ein Feature. Der IE nimmt gewöhnlich den Notepad als Anzeigeprogramm, und Notepad kann Unicode. Also siehst du (was schlau ist, da alles andere ja eher unlesbar wäre) die eingegebenen Zeichen.

Fragt sich nun nur, woher ich mal eben schnell einen türkischen Zeichensatz zum testen bekomme.

Türkisch dürfte, da es nicht so viele Zeichen enthält, z.B. in "Arial Unicode" mit drin sein.

Allerdings müsste die Sprachunterstützung vom Browser sowas ja mitbringen, oder?

Der Browser bringt keine Fonts mit.

Wie sieht diese BOM aus? Kann man das was nachlesen? Irgendwann hatte ich das schonmal gelsen *umpf*

Es handelt sich um das Unicode-Zeichen U+FEFF, welches in der entsprechenden Codierung (UTF-8, -16 oder -32) als erstes Zeichen in der Datei steht. Die UTF-8-Darstellung macht daraus beispielsweise 3 Bytes.

- Sven Rautenberg

[Andreas Korthaus]

Hallo Sven!

Ich kämpfe mich da gerade durch, wie man utf-8 und PHP unter einen Hut bringt.

Das ist eigentlich recht simpel, wenn man nur simple Dinge will. Wenn man kompliziertere Dinge will, muß man UTF-8-fähige oder Unicode-fähige Software einsetzen (bei PHP wäre das Stichwort "mbstring" (Multibyte-String) anzubringen).

Oder man wartet noch ein paar Tage und installiert sich todesmutig einen "Latest CVS Snapshot", um dann von der neuen umfassenden Unicode Unterstützung für PHP 6 zu profitieren ;-)

Grüße
Andreas

[dedlfix]

echo $begrüßung;

Nun bin ich also auf der Suche nach einer verlässlichen Methode, die Kodierung einer Datei auszulesen. Habt ihr einen Tipp für mich?
(Die optionale Signatur am Anfang ist kein zuverlässiges Indiz)

Aber das einzige.

Es gibt keine zuverlässige Methode, außer Rätselraten mittels Rechtschreibprüfung in allen möglichen Sprachen oder menschliche Intelligenz, die aber auch nur beim Rätselraten kann und darin möglicherweise besser ist.

Beispiel: In einer Datei stößt du auf ein Zeichen mit dem Wert 200. Selbst wenn die Anzahl der möglichen Zeichensätze auf die ISO-8859-X begrenzt wäre, hättest du die Auswahl zwischen È, Č, Ш, Θ, ...
Wie würdest du entscheiden, welches davon gemeint ist? Wie sollte eine allgemeingültige Regel aussehen, die das ermittelt?

echo "$verabschiedung $name";

[Ashura]

Hallo dedlfix.

(Die optionale Signatur am Anfang ist kein zuverlässiges Indiz)

Aber das einzige.

*grmpf* Das habe ich befürchtet.
Ich werde aber noch etwas weiter suchen.

Wie sollte eine allgemeingültige Regel aussehen, die das ermittelt?

Wenn ich dies wüsste, würde ich hier nicht fragen. ;-)

Einen schönen Sonntag noch.

Gruß, Ashura

[Ludger]

Hi,

*grmpf* Das habe ich befürchtet.
Ich werde aber noch etwas weiter suchen.

Du kannst doch mit einem kleinen Gedankenexperiment herausfinden, dass das, was Du wuenscht, nicht zuverlaessig gehen kann. Klar, Du kannst eine "Ratelogik" an den Start bringen, die vielleicht die eine oder andere Kodierung relativ zuverlaessig erkennt, aber ist das cool?

Gruss,
Ludger

[Ashura]

Hallo Ludger.

Du kannst doch mit einem kleinen Gedankenexperiment herausfinden, dass das, was Du wuenscht, nicht zuverlaessig gehen kann. Klar, Du kannst eine "Ratelogik" an den Start bringen, die vielleicht die eine oder andere Kodierung relativ zuverlaessig erkennt, aber ist das cool?

Sicher nicht.
Doch die einzige Alternative wäre, im Trial-And-Error-Verfahren beim Editieren die Zeichenkodierung manuell zu ändern, bis alle Sonderzeichen „normal“ aussehen.

Einen schönen Sonntag noch.

Gruß, Ashura

[Candid Dauth]

Heißa, Ashura,

Doch die einzige Alternative wäre, im Trial-And-Error-Verfahren beim Editieren die Zeichenkodierung manuell zu ändern, bis alle Sonderzeichen „normal“ aussehen.

Immerhin kannst du ja immer in paar Zeichensätze ausschließen, wenn zum Beispiel die Bitlänge des Strings nicht durch 8 teilbar ist, weißt du, dass es sich nicht um ein 8-bit-Charset handeln kann.

Oder du kannst überprüfen, ob es sich um UTF-8 handeln kann. UTF-8 kann zum Beispiel keine Zeichen der Binärcodes 11111000–11111111 enthalten. Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.

Es gibt also schon einige Merkmale, anhand derer man bestimmte Zeichensätze ausschließen kann. Die genaue Bestimmung zum Beispiel unterhalb der ISO-8859-Zeichensätze ist aber in der Tat sehr schwierig bis unmöglich.

Gautera!
Grüße aus Biberach Riss,
Candid Dauth

[Ashura]

Hallo Candid.

Immerhin kannst du ja immer in paar Zeichensätze ausschließen, wenn zum Beispiel die Bitlänge des Strings nicht durch 8 teilbar ist, weißt du, dass es sich nicht um ein 8-bit-Charset handeln kann.

<dummfrag>
Die Ausgabe von strlen entspricht nicht der Bitlänge?
</dummfrag>

Oder du kannst überprüfen, ob es sich um UTF-8 handeln kann.

Das versuche ich ja die ganze Zeit. ;-)

UTF-8 kann zum Beispiel keine Zeichen der Binärcodes 11111000–11111111 enthalten. Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.

Soweit habe ich das auch schon auf der Wikipedia-Seite herauslesen können.
Aber wie _genau_ kann ich dies überprüfen?
Anders gefragt: wie wandele ich einen String in seine Binärform um?

Es gibt also schon einige Merkmale, anhand derer man bestimmte Zeichensätze ausschließen kann. Die genaue Bestimmung zum Beispiel unterhalb der ISO-8859-Zeichensätze ist aber in der Tat sehr schwierig bis unmöglich.

Das brauche ich gar nicht. Ich möchte nur wissen, ob die Datei UTF-8-kodiert ist (-> entsprechende Funktionen zum Öffnen und Speichern werden aktiviert), andernfalls wird die Datei regulär geöffnet und gespeichert.

Einen schönen Sonntag noch.

Gruß, Ashura

[Candid Dauth]

Heißa, Ashura,

Immerhin kannst du ja immer in paar Zeichensätze ausschließen, wenn zum Beispiel die Bitlänge des Strings nicht durch 8 teilbar ist, weißt du, dass es sich nicht um ein 8-bit-Charset handeln kann.
<dummfrag>
Die Ausgabe von strlen entspricht nicht der Bitlänge?
</dummfrag>

Hm, ich weiß nicht so genau, wie PHP mit 7-bit-Charsets umgeht, aber wenn du sowieso nur zwischen UTF-8 und ISO-8859-1 unterscheiden willst, ist das nicht so wichtig.

Oder du kannst überprüfen, ob es sich um UTF-8 handeln kann.
Das versuche ich ja die ganze Zeit. ;-)

Na dann sag das doch! ;-)

UTF-8 kann zum Beispiel keine Zeichen der Binärcodes 11111000–11111111 enthalten. Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.
Aber wie _genau_ kann ich dies überprüfen?

Naja, binär 11111000 entspricht hexadezimal F8. 11111111 wäre FF. Das bringt die schonmal weiter, zum Beispiel in preg_match kannst du dann das Zeichen [\xf8-\xff] überprüfen. Ich hoffe, das bringt dir was.

Anders gefragt: wie wandele ich einen String in seine Binärform um?

Ein String ist ja schon in Binärform gespeichert, wenn du aber zum Beispiel den Binärwert eines Zeichens herausfinden willst, bringt dich dies vielleicht weiter:
[link:http://php.net/decbin@title=decbin]([link:http://php.net/ord@title=ord]($zeichen))

Das brauche ich gar nicht. Ich möchte nur wissen, ob die Datei UTF-8-kodiert ist

Beachte, dass obige Möglichkeit immernoch nicht sicher ist, es gibt immernoch Möglichkeiten, bei denen du UTF-8 nicht einwandfrei identifizieren kannst.

Gautera!
Grüße aus Biberach Riss,
Candid Dauth

[Ashura]

Hallo Candid.

Aber wie _genau_ kann ich dies überprüfen?

Naja, binär 11111000 entspricht hexadezimal F8. 11111111 wäre FF. Das bringt die schonmal weiter, zum Beispiel in preg_match kannst du dann das Zeichen [\xf8-\xff] überprüfen. Ich hoffe, das bringt dir was.

Ich werde darauf aufbauend ein wenig experimentieren, danke.

Anders gefragt: wie wandele ich einen String in seine Binärform um?

Ein String ist ja schon in Binärform gespeichert, wenn du aber zum Beispiel den Binärwert eines Zeichens herausfinden willst, bringt dich dies vielleicht weiter:
[link:http://php.net/decbin@title=decbin]([link:http://php.net/ord@title=ord]($zeichen))

Unter dem Bereich „Math“ habe ich natürlich nicht gesucht, noch einmal danke.

Das brauche ich gar nicht. Ich möchte nur wissen, ob die Datei UTF-8-kodiert ist

Beachte, dass obige Möglichkeit immernoch nicht sicher ist, es gibt immernoch Möglichkeiten, bei denen du UTF-8 nicht einwandfrei identifizieren kannst.

Gemach, gemach, wir werden sehen. ;-)

Einen schönen Sonntag noch.

Gruß, Ashura

[Ashura]

Hallo Candid.

Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.

Dies scheint mir eine sehr verlässliche Methode zu sein, nicht UTF-8-kodierte Zeichen von Utf-8-kodierten Zeichen zu unterscheiden.

Liege ich da richtig?

Einen schönen Montag noch.

Gruß, Ashura

[dedlfix]

echo $begrüßung;

Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.

Dies scheint mir eine sehr verlässliche Methode zu sein, nicht UTF-8-kodierte Zeichen von Utf-8-kodierten Zeichen zu unterscheiden.

Liege ich da richtig?

Du kannst nicht davon ausgehen, dass diese Zeichenfolgen in anderen Kodierungen nicht auftreten können/dürfen.

echo "$verabschiedung $name";

[Ashura]

Hallo dedlfix.

Du kannst nicht davon ausgehen, dass diese Zeichenfolgen in anderen Kodierungen nicht auftreten können/dürfen.

Aber bestimme Kombinationen kann ich sicher als Erkennungsmerkmal nutzen.
Ich probiere weiter.

Die variable Bytegröße macht die Sache in der Tat etwas komplizierter.

Einen schönen Montag noch.

Gruß, Ashura

[dedlfix]

echo $begrüßung;

Aber bestimme Kombinationen kann ich sicher als Erkennungsmerkmal nutzen.

Ich würde weiterhin auf Erraten statt Erkennen plädieren.

Solange keine UTF-8-"Syntax"-Fehler vorkommen, kann ein Text UTF-8 oder beispielsweise ISO-8859-1 sein.

Beispielsatz: Das deutsche scharfe s sieht UTF-8-kodiert so aus: ß

Beachte die Nichtverwendung des Zeichens ß. Sonst wäre der Text kein gültiges UTF-8 mehr.

echo "$verabschiedung $name";

[Ashura]

Hallo dedlfix.

Solange keine UTF-8-"Syntax"-Fehler vorkommen, kann ein Text UTF-8 oder beispielsweise ISO-8859-1 sein.

Die Bytelänge variiert aber.

Beispielsatz: Das deutsche scharfe s sieht UTF-8-kodiert so aus: ß

ANSI-Binär : 11011111

UTF-8-Binär: 11000011 10011111

Beachte die Nichtverwendung des Zeichens ß. Sonst wäre der Text kein gültiges UTF-8 mehr.

Weiß ich. Was möchtest du mir also sagen?

Einen schönen Montag noch.

Gruß, Ashura

[dedlfix]

echo $begrüßung;

Beispielsatz: Das deutsche scharfe s sieht UTF-8-kodiert so aus: ß

ANSI-Binär : 11011111

UTF-8-Binär: 11000011 10011111

Darum geht es nicht. Nicht der Inhalt ist interessant, nur die verwendeten Zeichen.

Beachte die Nichtverwendung des Zeichens ß. Sonst wäre der Text kein gültiges UTF-8 mehr.

Weiß ich. Was möchtest du mir also sagen?

Der Satz ist sowohl gültiges UTF-8 als auch ISO-8859-1.
Wenn er aber als UTF-8 gelesen wird -- nehmen wir an dieser Stelle den Inhalt wieder mit ins Boot -- ist seine Aussage verfälscht.

echo "$verabschiedung $name";

[Ashura]

Hallo dedlfix.

Beispielsatz: Das deutsche scharfe s sieht UTF-8-kodiert so aus: ß
[...]
Der Satz ist sowohl gültiges UTF-8 als auch ISO-8859-1.
Wenn er aber als UTF-8 gelesen wird -- nehmen wir an dieser Stelle den Inhalt wieder mit ins Boot -- ist seine Aussage verfälscht.

Ach, das meintest du. (Ich habe den Beispielsatz nicht als solchen wahr genommen.)

Ja, danke, ich werde dies in meine Überlegungen einfließen lassen.
(Wobei ich allmählich wirklich bezweifle, ob es sinnvoll machbar ist.)

Einen schönen Montag noch.

Gruß, Ashura

[Tom]

Hello,

Dann kannst du noch schauen, ob ein 110xxxxx wirklich von einem 10xxxxxx gefolgt wird, oder ob ein 10xxxxxx vorkommt, dessen Vorgänger eben einer ist, der in UTF-8 nicht erlaubt wäre.

Dies scheint mir eine sehr verlässliche Methode zu sein, nicht UTF-8-kodierte Zeichen von Utf-8-kodierten Zeichen zu unterscheiden.

Ich denke da gerade an meine Bemühungen, ASC-Dateien (Text-Dateien) von z.B. EXE-Dateien zu unterscheiden.
Eine echte Textdatei darf keine #0 enthalten.
Genauso könnte man also bei den  UTF-8-Dateien vorgehen. Bestimmte Zeichen oder Zeichenfolgen sind hier einfach 'verboten' und damit als "Anti-Signatur" geeignet.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Ashura]

Hallo Tom.

Genauso könnte man also bei den  UTF-8-Dateien vorgehen. Bestimmte Zeichen oder Zeichenfolgen sind hier einfach 'verboten' und damit als "Anti-Signatur" geeignet.

Und diese „Anti-Signaturen“ herauszufinden dürfte die schwierigste Aufgabe werden.
Ein dazu passendes PCRE-Suchmuster dann wahrscheinlich weniger.

Einen schönen Montag noch.

Gruß, Ashura

[Andreas Korthaus]

Hallo Ashura!

(Die optionale Signatur am Anfang ist kein zuverlässiges Indiz)

Aber das einzige.

*grmpf* Das habe ich befürchtet.
Ich werde aber noch etwas weiter suchen.

Ich wüßte auch nicht wie sowas "allgemein gültig" funktionieren könnte. Nur wenn Du bestimmte Zeichenketten mit Sonderzeichen in den Dateien hast (dessen Bedeutung eindeutig ist), könntest Du versuchen daran die Kodierung zu ermitteln. Wie das funktionieren könnte, findest Du z.B. in folgendem MySQL Artikel: http://dev.mysql.com/tech-resources/articles/4.1/unicode.html (Abschnitt "Working with UTF-8 on the Web").

Wenn Du aber Dateien mit Sonderzeichen dabei hast, wo solche Zeichenketten nicht vorkommen, oder möglicherweise mit einer anderen Bedeutung, bringt es Dir nichts.

Grüße
Andreas

[Ashura]

Hallo Andreas.

[...]
Wenn Du aber Dateien mit Sonderzeichen dabei hast, wo solche Zeichenketten nicht vorkommen, oder möglicherweise mit einer anderen Bedeutung, bringt es Dir nichts.

Ja, leider.
Ich glaube, ich werde das Ganze überdenken müssen.
Meine zwischenzeitliche Idee, einfach immer UTF-8-Output zz liefern, egal wie der Input kodiert war, ist auch nicht wirklich brauchbar, da Sonderzeichen ja nicht automatisch korrekt kodiert werden und auf Scherereien mit str_replace habe ich wenig Lust.

Dennoch danke.

Einen schönen Dienstag noch.

Gruß, Ashura

[Tom]

Hello,

Meine zwischenzeitliche Idee, einfach immer UTF-8-Output zz liefern, egal wie der Input kodiert war, ist auch nicht wirklich brauchbar, da Sonderzeichen ja nicht automatisch korrekt kodiert werden und auf Scherereien mit str_replace habe ich wenig Lust.

Und utf-8² solltest Du besser auch nicht bauen. Das war ja, worau Sven R. mich aufmerksam machte, als er empfahl, die Inhalte strikt von der Logic zu trennen. dann kann man die Inhalte _immer_ in utf-8 vorhalten und hat immer definierten Input.

Woher beziehst Du denn Deinen Input?
Kannst Du nicht den User bitten, er möge den Code-Selektor bedienen?
Der Mensch sieht dann ja noch am besten, wann die Dekodierung passt.

Es muss aber eine Lösung geben, denn z.B. Textpad erkennt utf-8 automatisch und sicher.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Ashura]

Hallo Tom.

Woher beziehst Du denn Deinen Input?

Hauptsächlich aus Webverzeichnissen.
Ich habe diesen Dateibrowser für den Fall eingerichtet, dass ich ich Modifikationen an Dateien vornehmen muss, mir aber kein FTP-Zugang zur Verfügung steht. (Login ist also möglich)

Kannst Du nicht den User bitten, er möge den Code-Selektor bedienen?
Der Mensch sieht dann ja noch am besten, wann die Dekodierung passt.

Das war die letzte Möglichkeit die mir eingefallen ist, was wahrscheinlich auch die Brauchbarste ist.
Ich werde es wahrscheinlich auch so machen.
(BTW: Der User bin vorläufig erst einmal nur ich. ;-) )

Es muss aber eine Lösung geben, denn z.B. Textpad erkennt utf-8 automatisch und sicher.

Noch ein Softwarebündel nehme ich aber nicht auseinander.

Einen schönen Mittwoch noch.

Gruß, Ashura