nicht angemeldet
discouraged characters
Moin,
wenn man sich den Quelltext bspw. dieser Seite ansieht:
http://www.chineseetymology.org/Etymology.aspx?characterInput=妙&submitButton=Analyze+Character
und ganz nach unten scrollt, findet man einige Quadrate. Diese Quadrate sind "eigentlich" chin. Schriftzeichen. Das Forum hat mir schon von sich aus insofern weitergeholfen, dass es sich dabei um "discouraged characters" handelt.
Wenn ich ein solches Quadrat in Outlook-Express kopiere und als Encoding "Westeuropäisch (ISO)" wähle, mir dann (in Outlook) den Quelltext ansehe, wurden die Quadrate in Unicode umgewandelt.
Ich möchte aber diese Datenbank über PHP auslesen, d.h. ich nutze dies hier:
$fe = "http://www.chineseetymology.org/Etymology.aspx?characterInput=$e[11]&submitButton=Analyze+Character";
@ $byte = file($fe);
zerlege dann die eingelesene Seite und extrahiere daraus, was ich brauche (das ist vom Betreiber dieses Lexikons auch abgesegnet).
Mache ich das, wird aus den Quadraten - kurz gesagt - Mist, nämlich jeweils zwei Sonderzeichen (è€) und schon wieder so ein Quadrat.
Jetzt kommt auch schon die Frage:
Ist es denn möglich, das irgendwie zu vermeiden? Und sei es nur so, dass diese beknackten Quadrate unverändert erhalten bleiben? Dann könnte ich sie ja in Outlook schnell umwandeln. Sonst müsste ich Seite für Seite in Outlook kopieren und so weiter..
Weiß jemand Rat?
Schönen Gruß,
Mike
-
Moin!
wenn man sich den Quelltext bspw. dieser Seite ansieht:
und ganz nach unten scrollt, findet man einige Quadrate.
Ich finde keine Quadrate. Alles, was ich auf der HTML-Seite im Browser sehe, sieht sehr gut aus, die Seite wird als UTF-8 ausgeliefert, und mein Zeichensatz (den ich mir aufgrund von CK's chinesischen Grüßen installiert habe) zeigt alles offenbar korrekt an.
Auch im Quelltext sind alle Zeichen "typisch UTF-8", d.h. da mein Weaverslave kein UTF-8 kennt, werden die Zeichen in ihren "extended ASCII"-Äquivalenten mehrbytig angezeigt.
Diese Quadrate sind "eigentlich" chin. Schriftzeichen. Das Forum hat mir schon von sich aus insofern weitergeholfen, dass es sich dabei um "discouraged characters" handelt.
Inwiefern kommst du zu diesem Schluß? Wenn dein Editor UTF-8 versteht, dein Zeichensatz dafür aber keine Zeichnungsvorschrift hat, kommen eben die Quadrate. Allein aus der Darstellung "Quadrat" kann man nicht auf "discouraged character" schließen, dazu müßte man den Unicode des Zeichens feststellen und in den Unicode-Tabellen nachschlagen.
Wenn ich ein solches Quadrat in Outlook-Express kopiere und als Encoding "Westeuropäisch (ISO)" wähle, mir dann (in Outlook) den Quelltext ansehe, wurden die Quadrate in Unicode umgewandelt.
Das kann ja nun eigentlich komplett gar nicht sein. Was meinst du denn mit "in Unicode gewandelt"? In die numerischen Zeichenreferenzen der Marke 〹? Das ist kein Unicode. Unicode kommt in den Ausprägungen UTF-7, UTF-8, UTF-16 oder UTF-32 daher - und paßt keinesfalls in die Zeichencodierung ISO-8859-1.
Ich möchte aber diese Datenbank über PHP auslesen, d.h. ich nutze dies hier:
$fe = "http://www.chineseetymology.org/Etymology.aspx?characterInput=$e[11]&submitButton=Analyze+Character";
@ $byte = file($fe);zerlege dann die eingelesene Seite und extrahiere daraus, was ich brauche (das ist vom Betreiber dieses Lexikons auch abgesegnet).
Mache ich das, wird aus den Quadraten - kurz gesagt - Mist, nämlich jeweils zwei Sonderzeichen (è€) und schon wieder so ein Quadrat.
Dann gibst du die Resultatseite nicht als UTF-8 aus.
Jetzt kommt auch schon die Frage:
Ist es denn möglich, das irgendwie zu vermeiden? Und sei es nur so, dass diese beknackten Quadrate unverändert erhalten bleiben? Dann könnte ich sie ja in Outlook schnell umwandeln. Sonst müsste ich Seite für Seite in Outlook kopieren und so weiter..
Weiß jemand Rat?
Lies dich in die Verwendung von UTF-8 bzw. Unicode allgemein ein. Verwende durchgehend UTF-8 - damit kannst du, auch wenn deine Editoren, Skriptsprachen und Datenbanken allesamt unfähig sind, UTF-8 zu verstehen, zumindest die Strings einlesen, speichern und wieder ausgeben. Selbst die Verarbeitung ist in gewissen Grenzen mit PHP möglich, bedeutet aber tatsächlich einen gewissen Mehraufwand (beispielsweise, wenn es darum geht, einen Text nach X Zeichen zu umbrechen).
Für weitergehende Informationen und Hilfe werden aber mehr Details benötigt.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hallo,
In die numerischen Zeichenreferenzen der Marke 〹? Das ist kein Unicode.
Doch, das ist eine mögliche Auszeichnungsform von Unicode bzw. UCS, genau wie 〹 oder U+3039 oder \u3039 ... Es bezeichnet den Speicherwert [00110000 00111001].
Unicode kommt in den Ausprägungen UTF-7, UTF-8, UTF-16 oder UTF-32 daher
Nein, es wird so übertragen und gespeichert. UTF ist aber nicht Unicode, sondern bezeichnet ein Unicode Transformation Format. Nur UTF-16 und UTF-32 sind in Teilen mit UCS identisch.
viele Grüße
Axel
-
Moin Sven, globe und Axel,
die Sache hat sich eigentlich schon erledigt, nachdem ich nämlich im Browser die Codierung auf UTF-8 gesetzt habe, kann ich wenigstens meine Ausgabe vernünftig sehen und dann den Outlook-Konvertierungs-Trick anwenden.
Bemerkenswert ist: Die verlinkte Seite sehe ich auch mit der normalen westeuropäischen Kodierung quadratlos. In meiner PHP-Plünder-Seite habe ich auch den gleichen (kompletten) <head> der Quellseite angegeben, sehe aber beschriebenen Mist. Im Quelltext findet sich dieser Mist auch, aber sobald ich eben die Browser-Codierung ändere, wird er wenigstens im Browser korrekt angezeigt.
Mit "Unicode per Outlook" meine ich in der Tat die dezimale Schreibweise, von der ich - hallo Axel - auch meine, dass es sich dabei um Unicode handelt, ist es doch lediglich die dezimale Schreibweise der hexadezimalen UTF-16-Darstellung. Siehe dazu:
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=5999
Werde aber dem Rat folgen, mich mal in Unicode-Gesetze reinzulesen, derzeit referenziere ich nämlich über diesen dezimalen Code, u.U. wäre es besser, mich an UTF-8 oder -16 zu halten.
Diese Quadrate sind "eigentlich" chin. Schriftzeichen. Das Forum hat mir schon von sich aus insofern weitergeholfen, dass es sich dabei um "discouraged characters" handelt.
Inwiefern kommst du zu diesem Schluß? Wenn dein Editor UTF-8 versteht, dein Zeichensatz dafür aber keine Zeichnungsvorschrift hat, kommen eben die Quadrate. Allein aus der Darstellung "Quadrat" kann man nicht auf "discouraged character" schließen, dazu müßte man den Unicode des Zeichens feststellen und in den Unicode-Tabellen nachschlagen.
Wenn ich den in meiner Ausgabe verkrüppelten Mist ins Forum kopieren will, kommt diese Ansage:
Sie haben ein Zeichen eingegeben, dass vom W3C als „discouraged character“ gekennzeichnet ist. Leider können solche Zeichen nicht verarbeitet werden. Zu der Gruppe von Zeichen gehören z. B. alle Steuerzeichen ausser dem Zeilenumbruch, dem Zeilenvorschub und dem Tabulator-Zeichen.
<<Das gilt aber tatsächlich nicht für die Quadrate im Quelltext der Ursprungsseite..
Da wird also vom PHP oder während der Übertragung was vermurkst - der Tipp von globe wäre sicher der Umsetzung wert, wenn ich das Script nicht nur flugs zum Ausschlachten jener Seite bräuchte. :)
Wie immer aber meinen besten Dank,
Mike
-
Hallo,
die Sache hat sich eigentlich schon erledigt, nachdem ich nämlich im Browser die Codierung auf UTF-8 gesetzt habe, kann ich wenigstens meine Ausgabe vernünftig sehen und dann den Outlook-Konvertierungs-Trick anwenden.
Bemerkenswert ist: Die verlinkte Seite sehe ich auch mit der normalen westeuropäischen Kodierung quadratlos.
Wie quadratlos? Mit den korrekten chinesischen Schriftzeichen? Das wäre wirklich seltsam. Wie ermittelst Du, ob der Browser die "normale westeuropäische Kodierung" verwendet?
In meiner PHP-Plünder-Seite habe ich auch den gleichen (kompletten) <head> der Quellseite angegeben, sehe aber beschriebenen Mist.
Mit welchem Betrachter? Wenn mit dem Browser, dann sendet Dein Server die falsche Angabe für charset. Da die vom Server gesendete Angabe schwerer wiegt, als ein
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
im HTML, kannst Du diese dort auch nicht korrigieren bzw.überschreiben. Der Server muss
Content-Type: text/html; charset=UTF-8
senden. Er sendet aber offensichtlich bei allen HTML-Ressourcen
Content-Type: text/html; charset=iso-8859-1
Das würde auch erklären, warum Du im Browser die Codierung manuell auf UTF-8 setzen musst.
Im Quelltext findet sich dieser Mist auch,
Dann kann der Editor, mit dem Du den Quelltext bearbeitest auch kein UTF-8.
viele Grüße
Axel
-
Moin Axel,
Bemerkenswert ist: Die verlinkte Seite sehe ich auch mit der normalen westeuropäischen Kodierung quadratlos.
Wie quadratlos? Mit den korrekten chinesischen Schriftzeichen?Genau so.
Das wäre wirklich seltsam. Wie ermittelst Du, ob der Browser die "normale westeuropäische Kodierung" verwendet?
Ich spreche von der Einstellung unter "Encoding".
In meiner PHP-Plünder-Seite habe ich auch den gleichen (kompletten) <head> der Quellseite angegeben, sehe aber beschriebenen Mist.
Mit welchem Betrachter?
Nochmal im Detail:
Die Quellseite http://www.chineseetymology.org/Etymology.aspx?characterInput=妙&submitButton=Analyze+Character sehe ich im Browser auch mit der Encoding-Einstellung "Westeuropäisch (ISO)" korrekt, also die chin. Schriftzeichen, alles wie es sein sollte.
Den Quelltext der Quellseite sehe ich im Text-Editor quadratisch.
Die mit meinem PHP-Script extrahierten unicodierten Zeichen sehe ich
- im Browser mit der Encoding-Einstellung "Westeuropäisch (ISO)" als Murks
- im Editor als Murks
- im Browser mit der Encoding-Einstellung "Unicode (UTF-8)" wie es sein soll
Erstaunlich ist das, weil die Zeichen im generierten Quelltext gegenüber den Zeichen im Quelltext der Ursprungseite verändert sind, in diese beschriebene Kombination aus Sonderzeichen und nem Quadrat, das eben hier vom Forum als "discouraged character" verpönt wird.
Wenn mit dem Browser, dann sendet Dein Server die falsche Angabe für charset. Da die vom Server gesendete Angabe schwerer wiegt, als ein
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
im HTML, kannst Du diese dort auch nicht korrigieren bzw.überschreiben. Der Server muss
Content-Type: text/html; charset=UTF-8
senden. Er sendet aber offensichtlich bei allen HTML-Ressourcen
Content-Type: text/html; charset=iso-8859-1
Das würde auch erklären, warum Du im Browser die Codierung manuell auf UTF-8 setzen musst.
Ok, ich glaube, zu verstehen. :-D Auf die Sendung des Servers habe ich aber nur dann Einfluss, wenn ich den Server selbst betreibe, richtig? Das Script läuft auch auf meinem persönlichen Festplatten-Server, allerdings wäre so eine Funktion (Extraktion von Daten aus externen Seiten) auch für die online-Site interessant - müsste ich mir das also direkt abschminken..?
Im Quelltext findet sich dieser Mist auch,
Dann kann der Editor, mit dem Du den Quelltext bearbeitest auch kein UTF-8.Ja, davon gehe ich auch aus.
Mittlerweile hab ich das aber auch fertig und hat alles zu meiner Zufriedenheit funktioniert.
Schönen Gruß,
Mike
-
Moin!
Das wäre wirklich seltsam. Wie ermittelst Du, ob der Browser die "normale westeuropäische Kodierung" verwendet?
Ich spreche von der Einstellung unter "Encoding".
Im IE? Das erklärt vieles!
Die Encoding-Einstellung im IE wirkt nur dann, wenn das HTML-Dokument wirklich keinerlei Encoding-Angabe selbst mitbringt. Wenn der Benutzer das nämlich sonst fest auf "Westeuropäisch (ISO)" (oder "(Windows)") einstellen würde, dann würde er mit Sicherheit bei grob der Hälfte aller besuchten Seiten Umlaut- und/oder Sonderzeichenmurks sehen, weil UTF-8 durchaus schon sehr verbreitet ist und genutzt wird - und auch der Rest der Webseiten sich mitnichten auf ISO-8859-1 oder Windows-1252 als Encoding beschränkt.
Wenn du also "Westeuropäisch" wählst, dann ist das eine Hilfsauswahl, wenn der Server oder das Dokument keine Angaben machen. Und nur dann kann man im IE mit dem Ändern dieser Auswahl auch irgendwas bei der Anzeige der Umlaute ändern. Mit Angabe tut sich beim Umstellen auf beliebige andere Encodings absolut nichts.
Die Quellseite http://www.chineseetymology.org/Etymology.aspx?characterInput=%E5%A6%99&submitButton=Analyze+Character sehe ich im Browser auch mit der Encoding-Einstellung "Westeuropäisch (ISO)" korrekt, also die chin. Schriftzeichen, alles wie es sein sollte.
Das liegt, wie beschrieben, daran, dass UTF-8 als Encoding angegeben ist, die Browserauswahl also wirkungslos bleibt (wohlgemerkt im IE - in meinem Opera beispielsweise MUSS ich "automatic selection" wählen, wählte ich manuell ein anderes Encoding, würde Opera die Seitenbytes sofort mit diesem anderen Encoding interpretieren und darstellen. Ein Feature, was man nur äußerst selten wirklich benötigt, wenn sich Seitenautoren oder (wohl häufiger) Webserver beim Encoding irren).
Wenn deine eigenen Seiten nun keine Encoding-Angaben machen, dann plötzlich wirkt deine Menüauswahl - und "Westeuropäisch" ist natürlich die falsche Wahl für UTF-8-Zeichen. :) Und außerdem wirkt das Umstellen.
Ok, ich glaube, zu verstehen. :-D Auf die Sendung des Servers habe ich aber nur dann Einfluss, wenn ich den Server selbst betreibe, richtig?
Nein, nicht richtig. Erstens gibt es .htaccess, mit dem sich der weitverbreitete Apache-Server durchaus sehr weitgehend konfigurieren läßt.
Und außerdem benutzt du PHP, welches ebenfalls wunderbar (mit dem Befehl header()) in der Lage ist, HTTP-Zusatzangaben an den Browser zu senden. Das würde sich hier sogar noch deutlicher anbieten, da es die Problematik "Encoding-Angabe" unlöschbar und unwegkonfigurierbar an das Skript bindet - die .htaccess-Lösung kann vom Server-Admin nämlich auch abgeschaltet werden.
- Sven Rautenberg
--
My sssignature, my preciousssss!
-
-
hi,
die Sache hat sich eigentlich schon erledigt, nachdem ich nämlich im Browser die Codierung auf UTF-8 gesetzt habe, kann ich wenigstens meine Ausgabe vernünftig sehen und dann den Outlook-Konvertierungs-Trick anwenden.
Dann hat dein browser erst jetzt gemerkt, dass er dieses Dokument als UTF-8 interpretieren soll - vermutlich, weil im Response Header der Serverantwort eine andere Zeichenkodierung angegeben wurde.
Bemerkenswert ist: Die verlinkte Seite sehe ich auch mit der normalen westeuropäischen Kodierung quadratlos.
Dann liefert diese vermutlich die passendeZeichenkodierung im Response.
In meiner PHP-Plünder-Seite habe ich auch den gleichen (kompletten) <head> der Quellseite angegeben, sehe aber beschriebenen Mist.
Die Angabe der Zeichenkodierung per <meta> in der Seite ist "schwächer" also eine per HTTP-Header gemachte.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }
-
-
-
n'abend,
Ist es denn möglich, das irgendwie zu vermeiden? Und sei es nur so, dass diese beknackten Quadrate unverändert erhalten bleiben? Dann könnte ich sie ja in Outlook schnell umwandeln. Sonst müsste ich Seite für Seite in Outlook kopieren und so weiter..
ich saß stundenlang am rätsel dran, warum ich in meiner datei lauter komische zeichen drin hatte. bis mich dedlfix darauf hinwies, dass es sich bei der datei um utf-16 handelt - nicht um latin1.
um das problem zu lösen hab ich iconv eingebunden... vielleicht hilft dir das in deinem zeichensatz-djungel weiter...
weiterhin schönen abend...
--
wer braucht schon großbuchstaben?
sh:( fo:# ch:# rl:° br:> n4:& ie:{ mo:} va:) de:] zu:} fl:{ ss:? ls:[ js:| -
Hallo,
Ich möchte aber diese Datenbank über PHP auslesen, d.h. ich nutze dies hier:
$fe = "http://www.chineseetymology.org/Etymology.aspx?characterInput=$e[11]&submitButton=Analyze+Character";
@ $byte = file($fe);
zerlege dann die eingelesene Seite und extrahiere daraus, was ich brauche (das ist vom Betreiber dieses Lexikons auch abgesegnet).
Mache ich das, wird aus den Quadraten - kurz gesagt - Mist, nämlich jeweils zwei Sonderzeichen (è€) und schon wieder so ein Quadrat.Wie extrahiersrt Du? Wie gibst Du das extrahierte wieder aus?
Du musst beachten, dass die eingelesenen Daten UTF-8 codiert sind. Das Zeichen "續" U+7E8C besteht also aus _drei_ Bytes. Solange Du das bei Deiner Verarbeitung berücksichtigst und nicht auseinanderreißt und die Ausgabe auch wieder als UTF-8 kenntlich machst, sollte es funktionieren.
viele Grüße
Axel