utf-8 detection

[Dieter Raber]

Hallo Forum,

wie kann man mit PHP bei einer Datei, oder besser noch bei einem beliebigen String herausfinden, ob sie/er utf-8-encoded ist (kein BOM vorhanden).

Gruß,

Dieter

[Siechfred]

Hell-O!

wie kann man mit PHP bei einer Datei, oder besser noch bei einem beliebigen String herausfinden, ob sie/er utf-8-encoded ist (kein BOM vorhanden).

Da gibt es einen RegExp vom W3C, und hier gibt es Hinweise zum Einbau in PHP.

Siechfred

[Tom]

Hello,

Da gibt es einen RegExp vom W3C, und hier gibt es Hinweise zum Einbau in PHP.

Die regular expression hat den Nachteil, dass sie so keine qualifizierte Aussage gibt, welche utf-8 Stufe erreicht wurde. Wäre schöner, wenn man das auch wüsste.

Non utf-8
ASCII (127)
utf-8 2 bytes
utf-8 3 bytes
utf-8 4 bytes

Das würde einem auch Rückschlüsse auf die verwendeten Zeichen(sätze) ermöglichen
ASCII-Stndard sollte jedes Ausgabe-Device heute darstellen können.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Siechfred]

Hell-O!

Die regular expression hat den Nachteil, dass sie so keine qualifizierte Aussage gibt, welche utf-8 Stufe erreicht wurde. Wäre schöner, wenn man das auch wüsste.

Ist ja auch nur die "Ratiopharm-Lösung" ;-)

Siechfred

[Cybaer]

Hi,

Die regular expression hat den Nachteil, dass sie so keine qualifizierte Aussage gibt, welche utf-8 Stufe erreicht wurde. Wäre schöner, wenn man das auch wüsste.

  
/* Ist String korrektes UTF-8? */  
function valid_utf8($string) {  
 $result=1;  
 $len=strlen($string);  
 $i=0;  
 while($i<$len) {  
  $char=ord($string{$i++});  
  if(valid_1byte($char)) { // continue  
   continue;  
  } elseif(valid_2byte($char)) { // check 1 byte  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
   $result=max($result,2);  
  } elseif(valid_3byte($char)) { // check 2 bytes  
   $result=max($result,3);  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
  } elseif(valid_4byte($char)) { // check 3 bytes  
   $result=max($result,4);  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
   if(!valid_nextbyte(ord($string{$i++}))) return FALSE;  
  } else {  
   return FALSE; // 10xxxxxx occuring alone  
  } // goto next char  
 }  
 return $result; // done  
}  
  
function valid_1byte($char) {  
 if(!is_int($char)) return FALSE;  
 return ($char & 0x80)==0x00;  
}  
  
function valid_2byte($char) {  
 if(!is_int($char)) return FALSE;  
 return ($char & 0xE0)==0xC0;  
}  
function valid_3byte($char) {  
 if(!is_int($char)) return FALSE;  
 return ($char & 0xF0)==0xE0;  
}  
function valid_4byte($char) {  
 if(!is_int($char)) return FALSE;  
 return ($char & 0xF8)==0xF0;  
}  
function valid_nextbyte($char) {  
 if(!is_int($char)) return FALSE;  
 return ($char & 0xC0)==0x80;  
}  
  

valid_utf8("Text") liefert 1, 2, 3, 4 oder FALSE zurück.

Gruß, Cybaer

[Tom]

Hello,

muss ich mir gleich bunkern :-)

Eigentlich braucht man für UTF-8 eine vollständig eigenständige Zeichenklasse.
Versuch doch mal, die Position eines Zeichens im UTF-8-codierten Text mit den herkömmlichen PHP-Funktionen zu bestimmen. Und da gibt's ja noch mehr, was man mit Strings tun könnte.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Versuch doch mal, die Position eines Zeichens im UTF-8-codierten Text mit den herkömmlichen PHP-Funktionen zu bestimmen. Und da gibt's ja noch mehr, was man mit Strings tun könnte.

Warte auf PHP6. :-)
Die Multibyte String Functions kennst du sicher schon.

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

echo "$verabschiedung $name";

[Tom]

Hello,

Warte auf PHP6. :-)
Die Multibyte String Functions kennst du sicher schon.

Ja, aber leider habe ich ohne sie compiliert.
Da nun sowieso endlich ein Upgrade durchgeführt werden muss, nehm ich das mit auf den Zettel.

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

Lies Dir http://de.wikipedia.org/wiki/UTF-8 aufmerksam durch, und schau vor allem, ob Du im Abschnitt "Beispiele" den Violinschlüssel angezeigt bekommst.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

Lies Dir http://de.wikipedia.org/wiki/UTF-8 aufmerksam durch, und schau vor allem, ob Du im Abschnitt "Beispiele" den Violinschlüssel angezeigt bekommst.

Da steht, wie aus Unicode UTF-8 gemacht wird.
Das Violinschlüsselzeichen ist ein Ersatzzeichen, weil mein Browser keine Glyphe für das Zeichen finden konnte. Er zeigt aber immerhin ein 01D11E im Kästchen an, so wie er das mit allen glyphenlosen Zeichen macht.
Für den Text in diesem Wikipedia-Artikel wird also eine 4 ermittelt. Ich weiß aber immer noch nicht, was ich nun mit dieser 4 anstellen kann.

echo "$verabschiedung $name";

[Tom]

Hello,

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

Lies Dir http://de.wikipedia.org/wiki/UTF-8 aufmerksam durch, und schau vor allem, ob Du im Abschnitt "Beispiele" den Violinschlüssel angezeigt bekommst.

Da steht, wie aus Unicode UTF-8 gemacht wird.
Das Violinschlüsselzeichen ist ein Ersatzzeichen, weil mein Browser keine Glyphe für das Zeichen finden konnte. Er zeigt aber immerhin ein 01D11E im Kästchen an, so wie er das mit allen glyphenlosen Zeichen macht.
Für den Text in diesem Wikipedia-Artikel wird also eine 4 ermittelt. Ich weiß aber immer noch nicht, was ich nun mit dieser 4 anstellen kann.

Du als Besucher dieser Webseite kannst damit gar nichts anfangen, es sei denn, Du überschreibst den von Wikipedia vorgeschlagenen Font mit einem, der eine Darstellung für den Zeichencode kennt.

Dieter geht es aber um die Klassifizierung vorhandener Sourcen. Diese Klassifizierung wird i.d.R. nicht vom Browser eines Clients durchgeführt, sondern vom Planer/Administrator/Programmierer. Und für den ist es sehr hilfreich, wenn man er für die Planung der späteren Anzeige bereits weiß, ob das Dokument Probleme bereiten kann, oder aber z.B. mit einer UTF-8-"1" klassifiziert werden konnte, also mit normalen ASCII-fähigen Fonts angezeigt werden kann.

Irgendwie verstehe ich Sven und Dich nicht, wo Ihr das Problem damit habt, einer Funktion eine Zusatzinformation zu entlocken, die sie eigentlich auch zur Verfügung stellen kann, anstatt diese Information versickern zu lassen. Zumal die Funktion mit

false  entspricht[1]  0  für:  ist garantiert kein valides UTF-8      # [1] bei passendem Operator
                      1  für:  ist reines ASCII (127) und somit UTF-8
                      2  für:  ist UTF-8 2 Bytes  (können die meisten Fonts heute)
                      3  für:  ...                können nur die erweiterten Fonts
                      4  für:  ...                enthält garantiert Spezialzeichen

auch weitgehend Kompatibel mit einer reinen JA/NEIN Aussage ist.

Diese Einteilung gilt ziemlich genau aus der Sicht des ASCII-Glyphenraumes

In wieweit man das auch aus der Sicht Chinesischer Fonts usw. sagen kann, weiß ich nicht. Ich bezweifele das sogar, dass es ginge, da das Divergenzspektrum seinen Wurzelpunkt in der Menge der "ASCII-Glyphen" hat. Mit denen werden die Chinesen dann eher zwangsweise konfrontiert, oder funktioniert HTML in China anders?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Du als Besucher dieser Webseite kannst damit gar nichts anfangen, es sei denn, Du überschreibst den von Wikipedia vorgeschlagenen Font mit einem, der eine Darstellung für den Zeichencode kennt.

Nein. Du installierst einfach einen Font, der für dieses Zeichen eine Glyphe kennt, und schon siehst du den Violinschlüssel. Die Darstellung regelt dein Betriebssystem von alleine.

Irgendwie verstehe ich Sven und Dich nicht, wo Ihr das Problem damit habt, einer Funktion eine Zusatzinformation zu entlocken, die sie eigentlich auch zur Verfügung stellen kann, anstatt diese Information versickern zu lassen.

Weil diese Zusatzinformation keinen Nutzen hat. Es ist vollkommen egal, ob ich dem Font-Subsystem sage "schreibe mir Unicode-Zeichen 64 auf den Bildschirm" oder ob ich sage "schreibe Unicode-Zeichen 119070 auf den Bildschirm".

Für den Latin-1-Bereich macht es ja auch Sinn, zusätzlich den "Wunschfont" anzugeben, z.B. "Arial". Ich denke auch, dass es in jeder Sprache soetwas wie "Fonts" gibt, also die optisch unterschiedliche Darstellung der Schriftzeichen.

Allerdings halte ich es für relativ sinnlos, Arabisch oder Chinesisch in "Arial" oder "Times New Roman" darzustellen, um nur mal die zwei Klassiker für "sans serif" und "serif" zu nennen. Denn "Serifen" sind kennzeichnend für die westeuropäischen Schriften - andere Schriftsysteme messen diesen kleinen Strichelchen hingegen wichtige Bedeutung bei, weil man sonst ein ganz anderes Zeichen erhielte.

1  für:  ist reines ASCII (127) und somit UTF-8
                      2  für:  ist UTF-8 2 Bytes  (können die meisten Fonts heute)

Mein Arial-Font hat 1674 Glyphen (und 909 Kerning-Paare). Mit ein und zwei Byte breiten UTF-8-Zeichen können 2174 Zeichen (0x00 - 0x7FF) beschrieben werden - da fehlt also schon was.

Enthalten ist:
Basic Latin        U+0041 - U+007A
Latin-1 Supplement U+00C0 - U+00FF
Latin Extended-A   U+0100 - U+017F
Greek              U+0370 - U+03FF
Cyrillic           U+0400 - U+04FF
Hebrew             U+0590 - U+05FF
Arabic             U+0600 - U+06FF
Arabic Presentation Forms-A  U+FB50 - U+FDFF
Arabic Presentation Forms-B  U+FE70 - U+FEFF

Verdana hingegen hat nur diese Bereiche:
Basic Latin        U+0041 - U+007A
Latin-1 Supplement U+00C0 - U+00FF
Latin Extended-A   U+0100 - U+017F
Greek              U+0370 - U+03FF
Cyrillic           U+0400 - U+04FF

Das ist im Vergleich zum riesigen Bereich U+0000 bis U+07FF nicht mal die Hälfte.

Deine Argumentation "Zwei-Byte-UTF-8 können die meisten Fonts" ist also falsch. Im Gegenteil: Die Codierungslänge in Byte hat nicht die geringste Aussagekraft, die für eine Sprache üblicherweise benötigten Zeichen können durchaus weit verteilt liegen - das Eurozeichen ist beispielsweise U+20AC, kommt in deutschen Texten häufig vor - und würde deine gesamte Überlegung hier:

3  für:  ...                können nur die erweiterten Fonts

ad absurdum führen, denn wenn es etwas gibt, was die meisten westeuropäischen Fonts können, dann ist es das Eurozeichen.

Und die BOM nicht zu vergessen, die ja auch gelegentlich auftaucht.

Diese Einteilung gilt ziemlich genau aus der Sicht des ASCII-Glyphenraumes

In deiner Phantasie vielleicht, in der Realität nicht.

- Sven Rautenberg

[Tom]

Hello,

erstmal Dank für den Input.
So ganz vollständig ist das Bild allerdings noch nicht.
Damit werde ich mal mein Wochenende verbringen.

Unsere geläufigen Fonts liegen bezüglich ihrer UTF-8-Codes doch eher übereinander als nebeneinander. Sie haben also Schnittmengen. Wie wird da nun das "richtige" Zeichen ausgewählt?
Wird dafür die Font-Family verwendet?

Kann ich mir das jetzt so vorstellen, dass, wenn in meinem ersten Wunschfont genau ein Zeichen fehlt, dass aber im zweiten enthalten ist, dieses ersatzweise benutzt wird?

lexikalischer Platz im UTF-Code

Font 1         X  X  X  X  X  X  X  X  -  X  -  -  -  -  -  -  -  -  -
Font 2         -  -  -  -  Y  Y  -  -  Y  -  -  -  -  Y  Y  Y  -  -  Y
Font 3         Z  Z  Z  Z  -  Z  -  -  -  -  -  Z  Z  Z  -  -  -  -  -

Zeichenkette   a  a  a        a        a        a     a

Anzeige        X  X  X        X        Y        Z     Y

-             nicht belegt
X,Y,Z         Belegungen für den UTF-Code im jeweiligen Font
Zeichenkette  Code-Sequenz in UTF-8
Anzeige       Font der angezigten Glyphe

Für heute reicht mir da ein Ja oder Nein :-)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Dieter geht es aber um die Klassifizierung vorhandener Sourcen. Diese Klassifizierung wird i.d.R. nicht vom Browser eines Clients durchgeführt, sondern vom Planer/Administrator/Programmierer. Und für den ist es sehr hilfreich, wenn man er für die Planung der späteren Anzeige bereits weiß, ob das Dokument Probleme bereiten kann, oder aber z.B. mit einer UTF-8-"1" klassifiziert werden konnte, also mit normalen ASCII-fähigen Fonts angezeigt werden kann.

Dieses "Darum-Wissen" erscheint mir doch recht vage. Das ist nicht besser als den Durchschnittswert der Tiefe eines Sees zu kennen. Aus diesem Wert ist es unmöglich vorherzusagen, ob die Kuh unbeschadet durchläuft oder nicht. Und was passiert, wenn die Kuh genau so wie dieses Beispiel hinkt?

Irgendwie verstehe ich Sven und Dich nicht, wo Ihr das Problem damit habt, einer Funktion eine Zusatzinformation zu entlocken, die sie eigentlich auch zur Verfügung stellen kann, anstatt diese Information versickern zu lassen.

Diese Information ist in meinen Augen nutzlos. Dein erster Bereich enthält 128 Zeichen. Dein zweiter Bereich 1920 Zeichen. Darunter ist noch nicht mal das Zeichen für den Euro. Der dritte Bereich enthält gar 63488 Zeichen, unter anderem das Euro-Zeichen. Du empfiehlst also, dass man sich einen Font für "aller Welt Zeichen" installieren soll, nur damit man das Eurozeichen darstellen kann?

UTF-8 ist eine Form, Unicode zu kodieren, die sich (außer den Kompatibilitätsgründen im ASCII-Bereich) nicht weiter an einer Wichtigkeit bestimmter Zeichengruppen orientiert.

Du musst noch etwas mehr Überzeugungskraft aufbieten, damit ich in der Information einen praktischen Nutzen erkennen kann.

echo "$verabschiedung $name";

[Tom]

Hello,

Diese Information ist in meinen Augen nutzlos. Dein erster Bereich enthält 128 Zeichen. Dein zweiter Bereich 1920 Zeichen.

Nur BTW:
Ich verstehe die 1920 im Moment nicht.
Ich komme da immer auf 2176 verschiedene Möglichkeiten
Bereich 2 könnte ja 1 Byte _undoder_ 2 Bytes zur Codierung verwenden.

Die Sache mit dem Eurozeichen ist genau ein häufiges Problem bei eMails.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Diese Information ist in meinen Augen nutzlos. Dein erster Bereich enthält 128 Zeichen. Dein zweiter Bereich 1920 Zeichen.

Nur BTW:
Ich verstehe die 1920 im Moment nicht.
Ich komme da immer auf 2176 verschiedene Möglichkeiten
Bereich 2 könnte ja 1 Byte _undoder_ 2 Bytes zur Codierung verwenden.

Auf der von dir vorgeschlagenen Wikipediaseite steht die Lösung. :-)

Die Darstellung der 1-Byte-Zeichen ist zwar mit der 2-Byte-Kodierung (und 3-Byte-, und 4-Byte, ...) möglich aber nicht erlaubt. Die 2-Byte-Kodierung wird nur für die Zeichen von 80h bis 7FFh verwendet. Zitat Wikipedia: "Das gleiche Zeichen kann theoretisch auf verschiedene Weise kodiert werden. Jedoch ist nur die jeweils kürzestmögliche Kodierung erlaubt."

Somit müssen von den 2^11 Möglichkeiten bei 2-Byte-Kodierung die 2^7 Möglichkeiten der 1-Byte-Kodierung abgezogen werden, usw. Ergibt 1920. Wenn du die 128 Zeichen der 1-Byte-Kodierung hinzurechnest ergibt das aber auch nur 2048.

echo "$verabschiedung $name";

[Tom]

Hello,

Diese Information ist in meinen Augen nutzlos. Dein erster Bereich enthält 128 Zeichen. Dein zweiter Bereich 1920 Zeichen.

Nur BTW:
Ich verstehe die 1920 im Moment nicht.
Ich komme da immer auf 2176 verschiedene Möglichkeiten
Bereich 2 könnte ja 1 Byte _undoder_ 2 Bytes zur Codierung verwenden.

Auf der von dir vorgeschlagenen Wikipediaseite steht die Lösung. :-)

Die muss ja nicht bis ins Detail stimmen. Das wäre nicht das erste Mal.
Und es wäre auch keine Schande, denn Wikipedia ist von Menschen gemacht (hoffe ich).
Vielleicht hätte man addieren müssen, anstatt su subtrahieren.

Die Darstellung der 1-Byte-Zeichen ist zwar mit der 2-Byte-Kodierung (und 3-Byte-, und 4-Byte, ...) möglich aber nicht erlaubt. Die 2-Byte-Kodierung wird nur für die Zeichen von 80h bis 7FFh verwendet. Zitat Wikipedia: "Das gleiche Zeichen kann theoretisch auf verschiedene Weise kodiert werden. Jedoch ist nur die jeweils kürzestmögliche Kodierung erlaubt."

Wenn der Codierungsalgorithmus Redundanzen enthält, die nicht gewollt und nun auch ungenutzt beleiben müssen, ist er Schrott. Das kann ich mir nicht wirklich vorstellen. Ich denke eher, dass die Wiki-Seite hier einen Denkfehler enthält. Aber das könnte ja ggf. die RFC beantworten.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Die Darstellung der 1-Byte-Zeichen ist zwar mit der 2-Byte-Kodierung (und 3-Byte-, und 4-Byte, ...) möglich aber nicht erlaubt. Die 2-Byte-Kodierung wird nur für die Zeichen von 80h bis 7FFh verwendet. Zitat Wikipedia: "Das gleiche Zeichen kann theoretisch auf verschiedene Weise kodiert werden. Jedoch ist nur die jeweils kürzestmögliche Kodierung erlaubt."

Wenn der Codierungsalgorithmus Redundanzen enthält, die nicht gewollt und nun auch ungenutzt beleiben müssen, ist er Schrott.

Der Algorithmus enthält keine Redundanzen. Definiert ist, dass man von mehreren theoretisch möglichen Codierungsformen immer die kürzeste verwenden muß.

Wenn man z.B. das @-Zeichen codieren will, muß man den Codepoint U+0040 codieren. Aber je nachdem, wieviele Nullen man voranstellt, kann man durchaus eine so lange Zahl generieren, dass man (zumindest theoretisch) - praktisch ist das ja verboten) auch mehr als ein Byte verwenden könnte.

Das kann ich mir nicht wirklich vorstellen. Ich denke eher, dass die Wiki-Seite hier einen Denkfehler enthält. Aber das könnte ja ggf. die RFC beantworten.

Du solltest nicht nur Vorstellungen entwickeln, sondern auch Vertrauen in Aussagen anderer. :) Oder selbst nachprüfen, was andere sagen. Aber die Kombination aus "kann ich mir nicht vorstellen, gucke ich aber auch nicht selbst nach" ist für das Erreichen von Diskussionsergebnissen eher hinderlich.

- Sven Rautenberg

[Tom]

Hello,

Du solltest nicht nur Vorstellungen entwickeln, sondern auch Vertrauen in Aussagen anderer. :) Oder selbst nachprüfen, was andere sagen. Aber die Kombination aus "kann ich mir nicht vorstellen, gucke ich aber auch nicht selbst nach" ist für das Erreichen von Diskussionsergebnissen eher hinderlich.

Das ist jetzt eine boshafte[1] Unterstellung von Dir. :-)
Ich hatte nur eigentlich auch noch eine eigene Aufgabe zu erledigen und nicht sofort die Zeit, die RFC durchzuackern.

[1] Ich nehm an, Du willst mich jetzt mal fordern und dadurch fördern *gg*

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cybaer]

Hi,

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

Ich denke, das ist *prinzipiell* die falsche Herangehensweise! Tom hatte eine Idee, du & ich hatten sie nicht. Mag sein, daß diese Idee im Endeffekt sinnlos ist, aber ein Nachteil entsteht aus der Idee nicht - und aus deren Umsetzung auch nicht. Vielleicht mangelt es uns, und vielleicht sogar Tom, an weiteren Ideen, wie man diese Grundidee nutzen kann. Vielleicht hat aber ein anderer der sieht "die Funktion gibt mir zusätzlich die 'UTF-8-Stufe' zurück" eine neue Idee, wie man es sinnvoll nutzen kann.

Gruß, Cy-"auch Einstein hat nicht bei null angefangen"-baer

[dedlfix]

echo $begrüßung;

Ich denke, das ist *prinzipiell* die falsche Herangehensweise! Tom hatte eine Idee, du & ich hatten sie nicht. Mag sein, daß diese Idee im Endeffekt sinnlos ist, aber ein Nachteil entsteht aus der Idee nicht - und aus deren Umsetzung auch nicht. Vielleicht mangelt es uns, und vielleicht sogar Tom, an weiteren Ideen, wie man diese Grundidee nutzen kann. Vielleicht hat aber ein anderer der sieht "die Funktion gibt mir zusätzlich die 'UTF-8-Stufe' zurück" eine neue Idee, wie man es sinnvoll nutzen kann.

Nicht dass du mich falsch verstehst. Die Idee an sich begrüße ich. Und nun geht es darum, Anwendungsfälle zu suchen. Dabei möchte ich aber die auf falschen Vermutungen basierenden Schlussfolgerungen ausschließen. Überzeugt mich und ich propagiere zukünftig die Nützlichkeit dieser Information.

Aktueller Stand aus meiner Sicht ist, dass die Idee mit der "UTF-8-Stufe" schon auf einer anderen nicht immer anwendbaren Vermutung ansetzt. Bisher hat noch keiner hier den nicht widerlagbaren Beweis angeführt, dass man mit zweifelsfrei erkennen kann, dass ein Text UTF-8-kodiert ist. Momentan kann man nur sagen, dass ein Text den Regeln der UTF-8-Kodierung entspricht. Eine Aussage, ob der Autor wirklich UTF-8 verwendet hat oder eine Kodierung, die nur zufällig UTF-8-kompatibel ist, lässt sich nicht treffen.

Nächste von mir und Sven angezweifelte Vermutung: Orientierte sich die Vergabe der Codeblöcke an einer bestimmten Vorgehensweise, oder sind sie mehr nach dem "Wer zuerst kommt mahlt zuerst"-Prinzip vergeben? Ob die UTF-8-Kodierung eines bestimmten Unicode-Zeichens 1, 2, 3 oder 4 Byte verwendet ist von dieser, aus meiner Sicht, zufälligen Zuweisung zu einem der Codeblöcke abhängig. Momentan sehe ich da keine Schlussfolgerungen, die man daraus ziehen kann.

echo "$verabschiedung $name";

[Tom]

Hello,

Bisher hat noch keiner hier den nicht widerlagbaren Beweis angeführt, dass man mit zweifelsfrei erkennen kann, dass ein Text UTF-8-kodiert ist. Momentan kann man nur sagen, dass ein Text den Regeln der UTF-8-Kodierung entspricht. Eine Aussage, ob der Autor wirklich UTF-8 verwendet hat oder eine Kodierung, die nur zufällig UTF-8-kompatibel ist, lässt sich nicht treffen.

Das ist dann der Unterschied zwischen "Unfall", "Totschlag", "Mord" und "vorsätzlichem Mord", stimmts?

Aber tot ist tot.

Ich erinnere nochmals an die Intention von Dieter, der lokal verfügbare Dateien klassifizieren wollte u.a. nach ihrer Codierung. Da gibt es ja nicht nur UTF-8

Die sinnvolle Klassifizierung sollte Aufschluss über den Aufwand bei der weiteren Ver-/Bearbeitung geben können. Ich würde es daher begrüßen, wenn auch Du nicht nur gegenhältst, sondern vielleicht auch ein paar Untersuchungen in Richtung "wie könnte man das zweckmäßig umsetzen" machen würdest. Sven hat bei aller Kritik, die er bisher geübt hat, doch eine Menge Fakten beigetragen, die zu einer (anderen) Lösung führen könnten(, als er vielleicht selber dachte).

Vielleicht kommt am Ende dabei heraus, dass die RFC 3629 eigentlich eine von der Qualität der RFC 1925 ist ;-)  und daher dringend neu gefasst werden müsste.

---- only philosophy ----
Das Vorhaben habe ich als äußerst sinnvoll eingestuft, da unser Babylon schließlich auf vielen getrennten Wegen unaufhaltsam näher rückt, und eines Tages unbarmherzig zuschlagen wird.

Ob es die immer kompliziertere Codierung von Information oder die Zwei-Schritte-vor-einen-zurück-(Un-)Rechtschreibreform ist, oder Gesetze, die durch Ihre Ergänzung vom ... und die Anwendungsbestimmungen von ... usw. zum gegenteil verkehrt werden. Alles zielt darauf ab, dass die Menschheit sich nicht besser, sondern immer schlechter ohne hohen technischen Aufwand zurechtfinden wird.
-------------------------

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Bisher hat noch keiner hier den nicht widerlagbaren Beweis angeführt, dass man mit zweifelsfrei erkennen kann, dass ein Text UTF-8-kodiert ist. Momentan kann man nur sagen, dass ein Text den Regeln der UTF-8-Kodierung entspricht. Eine Aussage, ob der Autor wirklich UTF-8 verwendet hat oder eine Kodierung, die nur zufällig UTF-8-kompatibel ist, lässt sich nicht treffen.

Das ist dann der Unterschied zwischen "Unfall", "Totschlag", "Mord" und "vorsätzlichem Mord", stimmts?

Aber tot ist tot.

Das siehe ich anders. Unser Text ist noch nicht tot. Er wird erst dann verstümmelt, wenn du ihn aufgrund der Annahme, es handele sich um UTF-8-Text, als solchen behandelst.
Du siehst Symptome und behandelst daraufhin. Das kann gut gehen, kann aber auch zu einem Kunstfehler führen.

Die sinnvolle Klassifizierung sollte Aufschluss über den Aufwand bei der weiteren Ver-/Bearbeitung geben können. Ich würde es daher begrüßen, wenn auch Du nicht nur gegenhältst, sondern vielleicht auch ein paar Untersuchungen in Richtung "wie könnte man das zweckmäßig umsetzen" machen würdest.

Es tut mir leid, aber ich sehe am Ende dieser Sackgasse kein Licht. Und ich weiß auch nicht, in welche Richtung ich laufen oder zeigen soll, weil ich die genaue Definition deines Ziels nicht kenne.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Ich erinnere nochmals an die Intention von Dieter, der lokal verfügbare Dateien klassifizieren wollte u.a. nach ihrer Codierung. Da gibt es ja nicht nur UTF-8

Richtig, aber die Welt der Zeichencodierung zerfällt - zumindest in der Welt von (X)HTML - sehr eindeutig in zwei Teile:
1. Codierungen, die den gesamten Bereich der Unicode-Zeichen abdecken.
2. Codierungen, die nur eine Teilmenge der Unicode-Zeichen abdecken.

Zur Gruppe 1 gehören Codierungen wie UTF-7, UTF-8, UTF-16 und UTF-32.

Zur Gruppe 2 gehören Codierungen wie US_ASCII, ISO-8859-1, ISO-8859-15, Windows-1252 (für den westeuropäischen Bedarf), Big5, ISO-2022-CN (für Chinesisch), ISO-8859-6, Windows-1256 (für Arabisch) - und so weiter.

Kennzeichnend für alle Codierungen der zweiten Gruppe ist, dass sie für sich genommen keinerlei Methode bieten, Unicode-Zeichen, die nicht enthalten sind, doch irgendwie zu codieren. Als Hilfsmittel ist deshalb für HTML der Umweg über Entities (ä = ä, Α = griechisches Alpha) und numerische Zeichenreferenzen (𝄞 für den Violinenschlüssel).

Die sinnvolle Klassifizierung sollte Aufschluss über den Aufwand bei der weiteren Ver-/Bearbeitung geben können.

Meine Praxiserfahrung: Der Aufwand des Weiterverarbeitens von "echtem UTF-8" (bzw. dem, was man als solches einfach mal nimmt) ist ziemlich gering, solange man nicht versucht, aus dem UTF-8 irgendwas anderes zu machen, z.B. das Encoding zu wechseln.

Will man das Encoding wechseln, setzt man (was auch sehr geringen Aufwand verursacht) entsprechende Bibliotheken ein, die das erledigen. Kann man entsprechende Bibliotheken nicht einsetzen, so hat man automatisch großen Aufwand, weil man mindestens mal eine Codetabelle (256 Zeichencodierungen z.B. von ISO-8859-1) mit deren Unicode-Entsprechungen definieren muß.

Hat man diese Codierung aber definiert, so benötigt man die Information "ist ein Zeichen mit 2 Bytes in UTF-8" nicht, sondern man erstellt ganz simpel einen Mechanismus, der jedes Unicode-Zeichen (auch die mit 3 und mehr Bytes) komplett dekodiert und somit den Unicode-Codepoint ermittelt, um damit dann das umcodierte Zeichen des Ziel-Encodings zu finden. Dabei gehen unter Umständen große Teile des im String enthaltenen Zeichenraumes verloren, weil es keine Entsprechung gibt, und man in irgendeiner Form gegensteuern muß.

Aber zu keiner Zeit in diesen Mechanismen ist es von irgendeiner Relevanz, wieviele Byte tatsächlich zur Bildung eines UTF-8-Zeichens benötigt werden. Es klassifiziert jedenfalls nichts, was bei der Problemstellung irgendwie hilfreich sein könnte.

Ich würde es daher begrüßen, wenn auch Du nicht nur gegenhältst, sondern vielleicht auch ein paar Untersuchungen in Richtung "wie könnte man das zweckmäßig umsetzen" machen würdest.

Vielleicht solltest du auch nicht nur gegenhalten, sondern mal deutlich machen, wo du denkst, dass man deine "UTF-8-Stufe" denn tatsächlich benötigt.

---- only philosophy ----
Das Vorhaben habe ich als äußerst sinnvoll eingestuft, da unser Babylon schließlich auf vielen getrennten Wegen unaufhaltsam näher rückt, und eines Tages unbarmherzig zuschlagen wird.

Unicode hilft dabei. Alle Anwendungen, die heutzutage neu erstellt werden, insbesondere webbasierte Lösungen, sollten unbedingt unicodefähig sein - entweder als einzige Codierungsform, oder mindestens alternativ.

Word beispielsweise macht in deutscher Einstellung sehr heftigen Gebrauch von Unicode - Gedankenstriche, Anführungszeichen - sind alles Zeichen, die in ISO-8859-1 nicht darstellbar sind, und immer wieder zu Problemen führen.

---

- Sven Rautenberg

[Cybaer]

Hi,

Vielleicht solltest du auch nicht nur gegenhalten, sondern mal deutlich machen, wo du denkst, dass man deine "UTF-8-Stufe" denn tatsächlich benötigt.

Schrieb ich doch: muß er nicht. Ist doch nur 'ne Info, dié man hat und niemanden stört. Wenn sie jemand braucht, ist gut; wenn nicht, auch gut. Warum sich dann um ggf. anderer (Nicht-)Ideen Gedanken machen, wenn man jetzt auch 'n Pils trinken kann? ;-))

Gruß, Cybaer

[Tom]

Hello,

bitte um Entschuldigung, wenn ich nicht geantwortet habe. Aber 1&1 hatte mich von Samstag 4:00 bis heute Mittag ausgesperrt. Bei der Umstellung von DSL3000 auf DSL6000 haben sie leider auch die Kontonummer umgestellt auf unser altes Konto (schon seit fünf Einzügen umgestellt) und konnten da natürlich nichts mehr abbuchen.
Freundlicherweise hat der Banker mich angerufen.
Hab ich ihnen auch sofort geschrieben und per eMail die Bestätigung bekommen, dass sie "kulanterweise" die ca. 9,00 Euro Rücklastgebühren nicht berechenen würden, sondern nochmal abbuchen würden (ich nahm an, diesmal wieder vom richtigen Konto).

Haben sie aber doch nicht gemacht, sondern stattdessen win paar Tage später das Login disabled. Die müssen eine Supersoftware[1] haben. :-((

Jetzt haben wir einen Auftrag versaut und einen Kunden weniger. Wirklich schade, dass man da wohl keinen Schadenersatz durchbekommt.

Vielleicht solltest du auch nicht nur gegenhalten, sondern mal deutlich machen, wo du denkst, dass man deine "UTF-8-Stufe" denn tatsächlich benötigt.

Ja, die Intention war einfach, etwas über die bevorstehende Komplexität der Darstellung aussagen zu können. Da ASCII (127) in den Bereich von UTF-8 fällt, wäre die Aussage "is_utf8()" nicht wirklich hilfreich. ASCII ist eine einfache (lineare) Codierung und lässt sich deshalb mit geringen Mitteln lesen, drucken, weiterverarbeiten. UTF-8 einer höheren Stufe macht da schon mehr Probleme.

Für sinnvoll halte ich daher auch nach unserer Diskussion immer noch die Unterscheidung

kein UTF-8
  ASCII (127) und damit UTF-8 1Byte
  UTF-8 mit Folgebyte(s)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Für sinnvoll halte ich daher auch nach unserer Diskussion immer noch die Unterscheidung

kein UTF-8
  ASCII (127) und damit UTF-8 1Byte
  UTF-8 mit Folgebyte(s)

Und ich halte die Unterscheidung nicht für sinnvoll.

Wenn ich auf UTF-8 teste, dann benötige ich vollkommen unabhängig davon, wie lang die einzelnen Zeichen in Byte sind, so oder so eine vollständige Behandlungsmöglichkeit für UTF-8.

Das heißt: Entweder meine Bytefolge paßt in das Muster "UTF-8" hinein - oder nicht.

Wenn zufällig in der Bytefolge nur Bytes kleiner 128 auftauchen - kein Unterschied. Wenn ich in der Lage sein muß, UTF-8 verarbeiten zu können, bringt mir dieser Sonderfall absolut nichts, weil er nichts erleichtert, denn den Code für Multibyte-Zeichenbehandlung (wenn denn erforderlich) muß ich auch dann haben, wenn nur Einzelbytes vorkommen - ansonsten wäre die Verarbeitung nicht UTF-8-fähig.

Umgekehrt: Wenn ich nur in der Lage sein muß, ASCII zu verarbeiten (wohlgemerkt nach der strengen Auslegung, also nur 7 Bit!), wird sicher vieles leichter, aber dann fehlen für normale westeuropäische Texte schlicht die Umlaute und sonstigen diakritischen Zeichen, die im Bereich >128 stecken. Dann muß ich aber auch nichts von UTF-8 wissen, sondern checke einfach nur jedes Byte, ob es kleiner 128 ist, und fertig.

- Sven Rautenberg

[Cybaer]

Hi,

Mir ist auch noch nicht klar, welche Anwendungsfälle es für die Aussage, wieviel Bytes das "längste" im Text enthaltene UTF-8-Zeichen verwendet, gibt. Könntest du mir einen oder mehrere nennen?

Ich denke, das ist *prinzipiell* die falsche Herangehensweise! Tom hatte eine Idee, du & ich hatten sie nicht. Mag sein, daß diese Idee im Endeffekt sinnlos ist, aber ein Nachteil entsteht aus der Idee nicht - und aus deren Umsetzung auch nicht. Vielleicht mangelt es uns, und vielleicht sogar Tom, an weiteren Ideen, wie man diese Grundidee nutzen kann. Vielleicht hat aber ein anderer der sieht "die Funktion gibt mir zusätzlich die 'UTF-8-Stufe' zurück" eine neue Idee, wie man es sinnvoll nutzen kann.

Gruß, Cybaer

[Cybaer]

Hi,

muss ich mir gleich bunkern :-)

:) Ich hatte die Funktion schon mal gepostet (Codierung einer XML Datei herausfinden und korrigieren) - ich mußte sie nur ein wenig ergänzen. :-)

Denn ich sehe es wie Du: Selbst scheinbar nutzlose Information (ich weiß mom. auch nicht, wofür das konkret zu gebrauchen wäre ;-)) ziehe ich einer Nicht-Info vor, wenn sie sonst nichts beeinträchtig. Und da die Funktion abwärtskompatibel blieb ... ;-)

Gruß, Cybaer

[Sven Rautenberg]

Moin!

Die regular expression hat den Nachteil, dass sie so keine qualifizierte Aussage gibt, welche utf-8 Stufe erreicht wurde. Wäre schöner, wenn man das auch wüsste.

Was ist denn eine "UTF-8-Stufe"? Wozu sollte man die wissen wollen?

- Sven Rautenberg

[Tom]

Hello,

Die regular expression hat den Nachteil, dass sie so keine qualifizierte Aussage gibt, welche utf-8 Stufe erreicht wurde. Wäre schöner, wenn man das auch wüsste.

Was ist denn eine "UTF-8-Stufe"? Wozu sollte man die wissen wollen?

Steht da eigentlich schon in meinem ersten Posting zu diesem Thema.
Lies einfach nochmal. :-)

Die Zeichensätze sind noch nicht alle vollständig mit allen Zeichen benutzbar/belegt.
Kommen in einem Dokument also UTF-8 codierte Zeichen mit mehr als einem Folgebyte vor, dann muss man den Zeichensatz entsprechend wählen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Was ist denn eine "UTF-8-Stufe"? Wozu sollte man die wissen wollen?

Steht da eigentlich schon in meinem ersten Posting zu diesem Thema.
Lies einfach nochmal. :-)

Du rezitierst die Codierungsvorschriften, wie man aus Unicode-Codepoints gültige Bytefolgen für UTF-8 generiert. Und nun?

Die Zeichensätze sind noch nicht alle vollständig mit allen Zeichen benutzbar/belegt.

Was meinst du mit "die Zeichensätze"?

Kommen in einem Dokument also UTF-8 codierte Zeichen mit mehr als einem Folgebyte vor, dann muss man den Zeichensatz entsprechend wählen.

Man muß "UTF-8" wählen, wenn man UTF-8 hat. Andere Wahlmöglichkeiten hat man nicht.

- Sven Rautenberg

[Tom]

Hello,

Man muß "UTF-8" wählen, wenn man UTF-8 hat. Andere Wahlmöglichkeiten hat man nicht.

Wo kann ich den Font (engl. für 'grafischer Zeichensatz') "UTF-8" herunterladen?
Könntest Du mir da bitte einen Tipp geben?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Man muß "UTF-8" wählen, wenn man UTF-8 hat. Andere Wahlmöglichkeiten hat man nicht.

Wo kann ich den Font (engl. für 'grafischer Zeichensatz') "UTF-8" herunterladen?
Könntest Du mir da bitte einen Tipp geben?

Die korrekte Darstellung der Unicode-Zeichen ist Aufgabe des Font-Subsystems.

Es gibt keinen Zeichensatz, der für den kompletten Umfang an Unicode-Zeichen Glyphen enthält. Es gibt also immer "Stückwerk".

Deshalb enthalten Fonts die Information, für welchen Unicode-Bereich sie Glyphen enthalten, und das Betriebssystem reagiert dann so, dass für Zeichen, die im gewünschten Font nicht enthalten sind, ein anderer Font genutzt wird, in dem die Zeichen enthalten sind.

Bestes Beispiel ist CK's Chinesisch hier im Forum. Diese Zeichen sind ganz sicher nicht in "Courier New" enthalten, trotzdem kann ich sie bei mir sehen, weil ich die von ihm vorgeschlagenen chinesischen Fonts installiert habe, die stattdessen genutzt werden.

Welches Unicodezeichen codiert ist, hat mit dessen optischer Darstellung also nichts zu tun.

- Sven Rautenberg

[Tom]

Hello,

Wo kann ich den Font (engl. für 'grafischer Zeichensatz') "UTF-8" herunterladen?
Könntest Du mir da bitte einen Tipp geben?

Die korrekte Darstellung der Unicode-Zeichen ist Aufgabe des Font-Subsystems.

Das ist mir klar. Hast Du Deinen Detektor versehentlich patched oder ausgeschaltet?

Es gibt keinen Zeichensatz, der für den kompletten Umfang an Unicode-Zeichen Glyphen enthält. Es gibt also immer "Stückwerk".

Das ist mir auch klar.

Deshalb enthalten Fonts die Information, für welchen Unicode-Bereich sie Glyphen enthalten, und das Betriebssystem reagiert dann so, dass für Zeichen, die im gewünschten Font nicht enthalten sind, ein anderer Font genutzt wird, in dem die Zeichen enthalten sind.

Das steht sinngemäß auch so in der Wiki-Seite. Es kommt dann z.B. das Kästchen als Platzhalter.

Bestes Beispiel ist CK's Chinesisch hier im Forum. Diese Zeichen sind ganz sicher nicht in "Courier New" enthalten, trotzdem kann ich sie bei mir sehen, weil ich die von ihm vorgeschlagenen chinesischen Fonts installiert habe, die stattdessen genutzt werden.

Das ist nun wiederum ein interessanter Aspekt. Was geschieht da genau wo? Wer sucht die Code-Übersetzung in weldhen Glyphen, wenn sie im eigentlich erbetenen Font nicht enthalten sind?
Geschieht da automatisch ein Ersatz durch die Symbole anderer Fonts?

Welches Unicodezeichen codiert ist, hat mit dessen optischer Darstellung also nichts zu tun.

Naja, das System ist eben mehrdimensional und es sollte, wenn keine Fehler vorliegen, einen verlässlichen Pfad durch das System geben. Das heißt, wenn ein Font mit ASCII-Glyphen benutzt wird, und UTF-8 (1 Byte, keine Folgebytes) benutzt wird, sollten schon die uns geläufigen ASCII-Zeichen dargestellt werden, auch bei einem Chinesen auf dem Monitor. Oder sehe ich das falsch?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Bestes Beispiel ist CK's Chinesisch hier im Forum. Diese Zeichen sind ganz sicher nicht in "Courier New" enthalten, trotzdem kann ich sie bei mir sehen, weil ich die von ihm vorgeschlagenen chinesischen Fonts installiert habe, die stattdessen genutzt werden.

Das ist nun wiederum ein interessanter Aspekt. Was geschieht da genau wo? Wer sucht die Code-Übersetzung in weldhen Glyphen, wenn sie im eigentlich erbetenen Font nicht enthalten sind?
Geschieht da automatisch ein Ersatz durch die Symbole anderer Fonts?

In Browsern kann man da was einstellen (nachgesehen: Opera und Firefox).

Naja, das System ist eben mehrdimensional und es sollte, wenn keine Fehler vorliegen, einen verlässlichen Pfad durch das System geben. Das heißt, wenn ein Font mit ASCII-Glyphen benutzt wird, und UTF-8 (1 Byte, keine Folgebytes) benutzt wird, sollten schon die uns geläufigen ASCII-Zeichen dargestellt werden, auch bei einem Chinesen auf dem Monitor. Oder sehe ich das falsch?

Die bei mir installierten Chinesischen Fonts haben zwar grob 26.000 Glyphen - aber auch Basic Latin. Umlaute sieht man damit also nicht, aber das, was du als "ASCII" bezeichnest, paßt.

- Sven Rautenberg

[Cybaer]

Hi,

Das heißt, wenn ein Font mit ASCII-Glyphen benutzt wird, und UTF-8 (1 Byte, keine Folgebytes) benutzt wird, sollten schon die uns geläufigen ASCII-Zeichen dargestellt werden, auch bei einem Chinesen auf dem Monitor. Oder sehe ich das falsch?

Zumindest hat man als Verarbeiter von Daten eine ziemlich hohe Sicherheit, daß der Empfänger alle Zeichen des UTF-8-Textes darstellen kann, wenn nur "UTF-8/Stufe 1" vorliegt - selbst wenn er überhaupt keinen UTF-8-Zeichensatz hat. :-)

Auch müßte man in diesem Fall das Dokument überhaupt nicht mit einer Headerkennung für UTF-8 ausgeben.

Auch könnte man sich bei einer höheren Stufe eventuell Gedanken darüber machen, Zeichen höherer Stufen auszutauschen.

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Auch müßte man in diesem Fall ["UTF-8/Stufe 1"] das Dokument überhaupt nicht mit einer Headerkennung für UTF-8 ausgeben.

Das ist mir viel zu spekulativ. Wenn ich mal weiter spekuliere, könnte dann das zu verarbeitende Programm auf die Idee kommen, bei Eingabe von "Stufe-n"-Zeichen (mit n > 1) auf eine ihm genehme Kodierung zu schalten statt das bevorzugte UTF-8 zu nutzen. Infolge dessen könnte man sich im späteren Verlauf Unannehmlichkeiten einhandeln, wenn Zeichen hinzukommen, die in der gewählten Kodierung nicht darstellbar sind. Aber wie gesagt, das ist nur Spekulation. Es kann so kommen, oder so, oder auch ganz anders.

echo "$verabschiedung $name";

[Cybaer]

Hi,

Wenn ich mal weiter spekuliere, (...)

Wenn *ich* mal "weiter spekuliere", dann spekuliere ich auf einen netten Abend in der Stammkneipe mit 'nem frischen Pils.

Allerdings neige ich nicht zu Spekulationen.

Aber *wenn* der *Fakt* eintritt, heute Abend in der Kneipe zu sitzen, *dann* bestell ich auch 'n Pils! ;-)

Gruß, Cybaer

PS: Zumindest rein hypothetisch - da ich kaum Alkohol (und überhaupt kein Bier) trinke, sitze ich auch selten in Kneipen. ;)

[Christian Seiler]

Hallo Dieter,

wie kann man mit PHP bei einer Datei, oder besser noch bei einem beliebigen String herausfinden, ob sie/er utf-8-encoded ist (kein BOM vorhanden).

So ohne weiteres gar nicht. Wenn keine Bytes (bzw. besserer Begriff wäre hier Oktets) mit Binärwert > 127 und keine Bytes mit < 32 vorkommen, dann hast du eine Zeichenkette, die sowohl gültiges US-ASCII, als auch gültiges UTF-8 als auch gültiges ISO-8859-1 als auch gültiges ISO-8859-2 als auch ... ist. Da hast Du keine Möglichkeit, irgend etwas festzustellen.

Wenn Bytewerte > 127 vorkommen, kannst Du überprüfen, ob korrekte UTF-Kodierung dieser Zeichen vorliegt. Dazu gibt's zahlreiche Routinen im Internet. Aber selbst dann könnte das trotzdem noch z.B. gültiges ISO-8859-1 sein, bei dem zufälligerweise eine derartige Zeichenfolge vorkommt.

Du kannst also nur feststellen, ob ein String *nicht* UTF-8 ist, d.h. sobald Du ungültige kodierte Zeichen entdeckst, kann es schonmal nicht UTF-8 sein. Falls solche Zeichen jedoch nicht vorhanden sind, d.h. alles gültiges UTF-8 wäre, dann kannst Du trotzdem nicht mit Sicherheit sagen, ob der String jetzt wirklich in UTF-8 vorliegt oder nur zufälligerweise so aussieht.

Du könntest höchstens etwas tun, wenn Du die Sprache kennst, in der das ganze geschrieben wird, dann könntest Du nach Wörtern suchen, die in der Sprache vorkommen und Multibyte-UTF8-Sequenzen enthalten, z.B. könntest Du nach »können«, »Fuß«, etc. im Deutschen suchen (natürlich mit entsprechender UTF-8-Kodierung von »ö« und »ß«) und falls so ein Wort vorhanden ist und der ganze String nicht ungültig im UTF8-Sinne ist, dann ist die Wahrscheinlichkeit sehr hoch, dass es Tatsächlich UTF-8 ist. Wenn aber jemand aus Prinzip Umlaute als ae schreibt, dann nützt das natürlich gar nichts.

Was genau willst Du denn erreichen, vielleicht gibt's ja einen anderen Weg?

Viele Grüße,
Christian

[Dieter Raber]

Hallo Christian,

Danke fuer die ausfuehrliche Antwort. Ich will Texte indizieren, die in verschiedenen Formaten vorliegen, zB. Text, HTML, OpenDocument etc. Die Texte koennten auch aus einer Datenbank kommen. Mir geht es nur um den reinen Text, ich koennte also durchaus herausfinden, ob es, platt gesagt, Buchstaben mit Akzenten gibt und ob diese richtig kodiert sind. Wenn die Erkennnung nicht immer 100%ig ist, waere das auch nicht das Ende der Welt. Deshalb werde ich mir erstmal die Loesung mit regulaeren Ausdruck anschauen.

Gruß,

Dieter

[Tom]

Hello,

wie kann man mit PHP bei einer Datei, oder besser noch bei einem beliebigen String herausfinden, ob sie/er utf-8-encoded ist (kein BOM vorhanden).

Da müsste man mal eine Funktion schreiben :-)
http://de.wikipedia.org/wiki/Utf-8

wenn jedes Byte des Strings nur Bit 0 bis 6 benutzt, hast Du die kleinstmögliche UTF-8 Codierung vorliegen, nämlich ASCII.

Wenn dann ein Byte das 7. Bit benutzt, muss auch das 6. benutzt sein, das 5. darf nicht gesetzt sein und beim Folgebyte muss eben 10xx xxxx vorliegen.

Man muss also eigentlich nur die Bytes raussuchen, die ein gesetztes Bit 7 haben und dann frei nach Eratostenes die darauffolgenden prüfen und überspringen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Da müsste man mal eine Funktion schreiben :-)

Hat schon jemand: bmorel at ssi dot fr. Die Funktion heißt dort auch richtigerweise seems_utf8() (seems = scheint zu sein) und arbeitet nach dem von Christian erwähnten Prinzip (ohne Sprachanalyse). Es gibt noch einige Userkommentare, die behaupten eine Funktion Namens is_utf8() (is = es ist so) geschrieben zu haben, aber die sind nicht richtig und zwar sowohl mit dem Namen als auch mit der Implementation. Ich untersuchte das neulich mal.

echo "$verabschiedung $name";

[Dieter Raber]

Erstmal vielen Dank fuer alle Antworten, da waren schon einige sehr brauchbare Sachen dabei.

Noch eine Zusatzfrage:
Auf welche Dateitypen kann man problemlos zugreifen, um den Text zu extrahieren. Ich habe bis jetzt html, odt, rtf, swx txt, xml, sowie einige ander Textformate. Auf doc und solche Sachen will ich eigentlich verzichten, da ist mir der Aufwand im Moment einfach zu gross. Mir geht es nur um solche Dokumente, die

• in der Regel textuelle Information enthalten
• mit PHP unter 'normalen Umstaenden' ziemlich einfach einzulesen sind.

Gruß,

Dieter

[Tom]

Hello,

Auf welche Dateitypen kann man problemlos zugreifen, um den Text zu extrahieren. Ich habe bis jetzt html, odt, rtf, swx txt, xml, sowie einige ander Textformate. Auf doc und solche Sachen will ich eigentlich verzichten, da ist mir der Aufwand im Moment einfach zu gross. Mir geht es nur um solche Dokumente, die

• in der Regel textuelle Information enthalten
• mit PHP unter 'normalen Umstaenden' ziemlich einfach einzulesen sind.

Dann solltest Du die üblichen "Mail-Formate" nicht auslassen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Dieter Raber]

Hallo Tom,

Dann solltest Du die üblichen "Mail-Formate" nicht auslassen.

Guter Tipp, danke.

Gruß,

Dieter