robinson crusoe: strings in sonderzeichen?

moin,

ich habe einen string mit sonderzeichen, der an php übergeben wird, sagen wir "24 Ω". in der datenbank habe ich ihn als 24 &#8486; gespeichert. jetzt möchte ich die beiden vergleichen. dafür fange ich Ω ab und ersetze es mit str_replace("&#8486;", "Ω", $correctarray); durch &#8486; und vergleiche dann "24 &#8486;" mit "24 &#8486;", was auch super funktioniert, dachte ich, weil die seite ja <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> und so ist.

wie dem auch sei. bei genauerer betrachtung stellt sich heraus, dass manche browser/betriebssystem/kombinationen-daraus die "24 Ω" nicht wirklich als "24 Ω", sondern als "24 Ω" übergeben. sieht lustig aus, bringt aber mein system arg ins wanken, weil ich das Ω dann nicht mehr durch &#8486; ersetzen kann und foglich "24 &#8486;" nicht mehr gleich "24 &#8486;" ist. kurzum, eine lösung muss her und hier seid ihr mal gefragt, denn mein latein ist am ende.

mein browser, als der safari, übergibt es übrigens so, dass am ende 24 Ω in der datenbank steht. ist nicht 24 Ω und schon gar nicht 24 Ω aber funktioniert wenigstens für den teil "24 &#8486;" = "24 &#8486;".

gruß und danke

  1. ich habe einen string mit sonderzeichen, der an php übergeben wird, sagen wir "24 Ω". in der datenbank habe ich ihn als 24 &#8486; gespeichert. jetzt möchte ich die beiden vergleichen. dafür fange ich Ω ab und ersetze es mit str_replace("&#8486;", "Ω", $correctarray); durch &#8486; und vergleiche dann "24 &#8486;" mit "24 &#8486;", was auch super funktioniert, dachte ich, weil die seite ja <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> und so ist.

    Warum speicherst du entities in der Datenbank? Das hat keinen SInn.

    wie dem auch sei. bei genauerer betrachtung stellt sich heraus, dass manche browser/betriebssystem/kombinationen-daraus die "24 Ω" nicht wirklich als "24 Ω", sondern als "24 Ω" übergeben.

    Diese Systeme raten vermutlich schlechter als andere - du gibst vermutlich gar keine Zeichenkodierung an, die einen Sinn ergibt und damits wenigstens halbwegs passt, drehen das ein paar Browser wieder um.

    Sieht jedenfalls so aus als hättest du UTF-8-codierte Daten vorliegen, überträgst sie aber in einer Single-Byte-Kodierung.

    sieht lustig aus, bringt aber mein system arg ins wanken, weil ich das Ω dann nicht mehr durch &#8486; ersetzen kann und foglich "24 &#8486;" nicht mehr gleich "24 &#8486;" ist. kurzum, eine lösung muss her und hier seid ihr mal gefragt, denn mein latein ist am ende.

    Verwende konsequent UTF-8 und mache dich mit dem Konzept eines Kontextwechsels vertraut.

    mein browser, als der safari, übergibt es übrigens so, dass am ende 24 Ω in der datenbank steht. ist nicht 24 Ω und schon gar nicht 24 Ω aber funktioniert wenigstens für den teil "24 &#8486;" = "24 &#8486;".

    Schei? Encoding ;)

    1. gut, ich merke, dass hier raum für verbesserungen ist. aber für den moment, bis ich die alle implementiert habe, bleibt die frage im raum, ob ich das problem eindämmen kann, wenn ich die werte, also zum beispiel 24 Ω vorab mit htmlentities() bearbeite und dann die 24 &#8486;, die übergeben werden mit meinen 24 &#8486; aus der datenbank vergleiche.

      könnte das funktionieren oder wäre das zufall, wenn es das in meinem browser gerade mal tut?

      gruß

      1. könnte das funktionieren oder wäre das zufall, wenn es das in meinem browser gerade mal tut?

        Zufall nicht - jeder Browser hat irgend einen algorithmischen Weg um die Zeichnkodierung im Fehlerfall zu bestimmen - und der ist vermutlich bei jedem Browser anders.

        Wie gesagt: ich gehe davon aus, dass du schlichtweg keine ordentliche Angabe zur Kodierung machst.

        1. Wie gesagt: ich gehe davon aus, dass du schlichtweg keine ordentliche Angabe zur Kodierung machst.

          ok, wo und wie gebe ich eine ordentliche Kodierung an?

          1. Wie gesagt: ich gehe davon aus, dass du schlichtweg keine ordentliche Angabe zur Kodierung machst.

            ok, wo und wie gebe ich eine ordentliche Kodierung an?

            Idealweise im HTTP-Header.

            http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung

            1. Wie gesagt: ich gehe davon aus, dass du schlichtweg keine ordentliche Angabe zur Kodierung machst.

              ok, wo und wie gebe ich eine ordentliche Kodierung an?

              Idealweise im HTTP-Header.

              http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung

              dort hab ich <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, auf der formularseite und auf der zielseite.

              1. Hast du das String-Feld in der DB als utf8_unicode_ci definiert?

                Beginnt dein PHP-Programm mit

                @mysql_query( "SET NAMES 'utf8'", $conn_id );  
                mb_internal_encoding("UTF-8");  
                header('content-type: text/html; charset=utf-8'); // hinter cookies
                
                1. Hi!

                  @mysql_query( "SET NAMES 'utf8'", $conn_id );

                  In aktuellen PHP-Versionen (>=5.2.3) kann man die Funktion mysql_set_charset('utf8') verwenden.

                  mb_internal_encoding("UTF-8");

                  Und das braucht man nur, wenn man auch alle anderen Stringfunktionen gegen ihr MB-Pendant tauscht, so vorhanden. Wenn du das einfach nur so allein aufführst, hat das keine weitere Wirkung. Notwendig ist die Verwendung der MB-Funktionen nicht, wenn man die Daten nur durchreicht und keine Stringverarbeitung in PHP macht.

                  Lo!

              2. Lieber robinson,

                Idealweise im HTTP-Header.

                dort hab ich <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

                das ist nicht der Header. Das ist eine Zeile Deines Dokuments, die vom Browser berücksichtigt werden kann, aber nicht muss. Sendet der Webserver einen Header, der von obiger Meta-Angabe abweichende Inhalte hat, dann ignoriert der Browser laut Spezifikation diese Angabe und berücksichtigt die Information des Webservers.

                Du suchst offensichtlich header('content-type: text/html; charset=utf-8').

                Liebe Grüße,

                Felix Riesterer.

                --
                ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
          2. @@robinson crusoe:

            nuqneH

            ok, wo und wie gebe ich eine ordentliche Kodierung an?

            An mehreren Stellen. Siehe [qa-changing-encoding] und dortige Links.

            Qapla'

            --
            Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
            (Mark Twain)
      2. @@robinson crusoe:

        nuqneH

        wenn ich die werte, also zum beispiel 24 Ω vorab mit htmlentities() bearbeite

        … dann machst du etwas falsch. htmlentities() gehört zu den PHP-Funktionen, die man nie einsetzen sollte. Und wenn man meint, man bräuchte die Funktion doch, sollte man besser den eigentlichen Fehler beheben.

        Qapla'

        --
        Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
        (Mark Twain)
  2. Hallo,

    ich habe einen string mit sonderzeichen, der an php übergeben wird, sagen wir "24 Ω". in der datenbank habe ich ihn als 24 &#8486; gespeichert.

    warum verfälschst Du Deine Daten vor dem Abspeichern?
    Speichere doch einfach

    24 Ω

    Dein Datenbankmanagementsystem kann das ganz bestimmt.

    Freundliche Grüße

    Vinzenz

    1. das problem, auf das ich gerade komme, ist, das, der wert 24 &#8486; zu 24 Ω umgewandelt wird. nur darum werden die 24 Ω überhaupt also solche übergeben. was mich zu der frage bringt, wie ich php dazu bringe, die 24 &#8486; nicht als 24 Ω als wert einzutragen. denn wenn es wirklich 24 &#8486; wären, die übergeben werden würden, hätte ich das ganze problem mit dem zurückwandeln nicht. gibt es da einen php befehl, der mir nicht einfallen will?

      1. das problem, auf das ich gerade komme, ist, das, der wert 24 &#8486; zu 24 Ω umgewandelt wird. nur darum werden die 24 Ω überhaupt also solche übergeben. was mich zu der frage bringt, wie ich php dazu bringe, die 24 &#8486; nicht als 24 Ω als wert einzutragen. denn wenn es wirklich 24 &#8486; wären, die übergeben werden würden, hätte ich das ganze problem mit dem zurückwandeln nicht. gibt es da einen php befehl, der mir nicht einfallen will?

        PHP konvertiert nicht von selbst numerische Referenzen in Klartext - das machst du in irgend einer Form schon selbst.

        1. PHP konvertiert nicht von selbst numerische Referenzen in Klartext - das machst du in irgend einer Form schon selbst.

          gut möglich. php nimmt aber den wert "24 &#8486;" aus der datenbank und schriebt ihn als value="24 &#8486;" in ein formularfeld und wenn ich das formular mit post übergebe, kommt auf der zielseite 24 Ω als ergebnis an. eventuell aber auch irgendein sonderzeichengeschwurbel dazwischen.

          1. PHP konvertiert nicht von selbst numerische Referenzen in Klartext - das machst du in irgend einer Form schon selbst.

            gut möglich. php nimmt aber den wert "24 &#8486;" aus der datenbank

            Das ist ein Fehler, aus der Datenbank sollte "24 Ω" kommen.

            und schriebt ihn als value="24 &#8486;"

            Das ist Unsinn, hier sollte "24 Ω" stehen - in diesem Fall ist lediglich ein htmlspecialchars() angebracht (Kontext HTML). Jegliche Entities (nebst der 5 "Special Chars") sind bei konsequenter Verwendung von UTF-8 nicht nötig.

            in ein formularfeld und wenn ich das formular mit post übergebe, kommt auf der zielseite 24 Ω als ergebnis an.

            So soll es auch sein.

            eventuell aber auch irgendein sonderzeichengeschwurbel dazwischen.

            Wie schon gesagt: ich gehe davon aus, dass die die Zeichenkodierung nicht angibst:

            http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset

            Wenn du im HTTP-Header ordentlich angibst, dass es sich um UTF-8 handelt, wird auch implizit UTF-8 zur Übermittlung des Formulars verwandt.

            1. Das ist Unsinn, hier sollte "24 Ω" stehen - in diesem Fall ist lediglich ein htmlspecialchars() angebracht (Kontext HTML). Jegliche Entities (nebst der 5 "Special Chars") sind bei konsequenter Verwendung von UTF-8 nicht nötig.

              ok, wenn ich also alle &#8684; in der datenbank suche und in Ω (und alle anderen zeichen in die entsprechenden gegenüber) ändere, kann ich dann davon ausgehen, dass die abfrage in allen gängigen browsern klappt?

              1. Lieber robinson,

                ok, wenn ich also alle &#8684; in der datenbank suche und in Ω (und alle anderen zeichen in die entsprechenden gegenüber) ändere, kann ich dann davon ausgehen, dass die abfrage in allen gängigen browsern klappt?

                ja.

                Liebe Grüße,

                Felix Riesterer.

                --
                ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
              2. Hi!

                ok, wenn ich also alle &#8684; in der datenbank suche und in Ω (und alle anderen zeichen in die entsprechenden gegenüber) ändere, kann ich dann davon ausgehen, dass die abfrage in allen gängigen browsern klappt?

                Nein, von selbst geht da nichts - höchstens per Zufall. Du musst dir insgesamt klar werden, wie Zeichenkodierung überhaupt funktioniert, welche Systeme an deinem Bearbeitungsprozess alle beteiligt sind, und wie man jedem einzelnen zum einen den Umgang mit einer gewählten Kodierung beibringt und zum anderen dem jeweils nachfolgenden System in der Verarbeitungskette die verwendete Zeichenkodierung der zu ihm übertragenen Daten mitteilt. All das kannst du zu großen Teilen in dem bereits verlinkten Themenschwerpunkt Zeichenkodierung nachlesen.

                Lo!

            2. Hello,

              in ein formularfeld und wenn ich das formular mit post übergebe, kommt auf der zielseite 24 Ω als ergebnis an.

              So soll es auch sein.

              Nein, so ist es aber nicht!
              Wir sollten uns endlich mal angewöhnen, das anders darzustellen!
              Beim Server kommt beim Request ein Bytestream an, der entsprechend der Codierung zu behandeln. ist.

              Bildlich dargestellt wird am Server gar nichts. Also bleibt es für das Script entweder bei der Bytefolge, die bei Benutzung von ISO-8859-1 im Browser als "24 &#8486" dargestellt werden würde, oder aber bei derjenigen, die bei Benutzung von ISO-8859-1 im Browser als "24 Ω" dargestellt werden würde.

              Der Server behandelt aber nur diese Bytefolgen.

              Um sie vergleichen zu können, benötigt er eine passende Transformationsvorschrift. Die könnte man nun mit den Umwandlungsfunktionen der Multibyte-Funktionen erzeugen/verwenden.

              siehe http://de2.php.net/manual/de/function.mb-convert-encoding.php

              Und hier möchte ich Vinzenz mal frei interpretieren.
              https://forum.selfhtml.org/?t=203609&m=1377086 (Zitat beachten)

              "Dein Datenbankmanagementsystem kann das ganz bestimmt."

              Robinson Crusoe sollte daher, wenn sein DBMS in der betroffenen Tabelle sowieso UTF-8 verwendet, die numerischen Referenzen dort einfach mal konvertieren lassen.

              Ob MySQL nun selber eine Konvertierungsfunktion dafür hat, vermag ich auf die Schnelle jetzt nicht zu sagen. strcmp() ist schon ziemlich dicht dran, wenn es um den Vergleich geht,
              http://dev.mysql.com/doc/refman/5.1/en/string-functions.html
              wir wollen ja aber umwandeln :-)

              Liebe Grüße aus dem schönen Oberharz

              Tom vom Berg

              --
               ☻_
              /▌
              / \ Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de
              1. Hi!

                Wir sollten uns endlich mal angewöhnen, das anders darzustellen!
                Beim Server kommt beim Request ein Bytestream an, der entsprechend der Codierung zu behandeln. ist.
                Bildlich dargestellt wird am Server gar nichts. Also bleibt es für das Script entweder bei der Bytefolge, die bei Benutzung von ISO-8859-1 im Browser als "24 &#8486" dargestellt werden würde, oder aber bei derjenigen, die bei Benutzung von ISO-8859-1 im Browser als "24 Ω" dargestellt werden würde.

                Schön und gut, aber wenn du schon Bytefolgen propagierst, dann stell doch besser auch Bytes (als hex) und nicht nach Kodierung XY interpretierte Zeichen dar. Zum besseren Vorstellen kannst du ja zusätzlich die Interpretation gemäß diverser Kodierungen dazuschreiben.

                32 34 20 26 23 38 34 38 36 3B
                2  4     &  #  8  4  8  6  ;   ASCII

                vs.

                32 34 20 e2 84 a6
                2  4     â  „  ¦  ISO-8859-1
                         └──┬───┘
                2  4        Ω     UTF-8

                Lo!

                1. moin,

                  ich fürchte, mich überfordert die ganze angelegenheit etwas. ich kann verstehen, dass die vorgänge komplexer sind, als ich bislang dachte, aber ich hab eventuell nicht die zeit, mich da einzufühlen.

                  daher brauche ich eine lösung, die funktioniert. ich scheitere schon daran, die sonderzeichen automatisch in der datenbank zu ändern, kann das aber eventuell in mühevoller kleinarbeit per hand tun.

                  schöner wäre es daher, wenn man mit den besagten einträgen, in meinem fall als entity kodiert, irgendwie fortfahren könnte.

                  es scheint aber zu funktionieren, wenn ich den wert in value="" zuvor mit htmlentities bearbeite, weil ich es dann hinten wieder mit eben diesen vergleiche, die aus der datenbank kommen.

                  gruß

                  1. Hi!

                    ich fürchte, mich überfordert die ganze angelegenheit etwas. ich kann verstehen, dass die vorgänge komplexer sind, als ich bislang dachte, aber ich hab eventuell nicht die zeit, mich da einzufühlen.

                    Kann ich gut verstehen, aber soo komplex ist es nun auch wieder nicht. Wichtig sind zwei Punkte: 1. Ein System muss mit der gewählten Kodierung umgehen können, wenn es nicht nur als Datendurchreicher arbeitet. 2. Beim Weitergeben an ein anderes System muss die Zeichenkodierung ausgehandelt oder angegeben werden. Die Zeichen müssen dann auch in dieser Kodierung gesendet werden.

                    Die DBMSe und die Browser sind eigentlich UTF-8-fähig. Dazwischen vermittelt PHP, der Webserver selbst spielt keine große Rolle. PHP ist noch nicht UTF-8-fähig, muss es aber nicht unbedingt sein, wenn du keine Stringfunktionen benötigst. Ansonsten gibt es die Funktionen der MultibyteExtension (mb_*).

                    Für die Browser musst du nichts weiter einstellen. Sie benötigen nur die Angabe im HTTP-Header und als Fallback im Meta-Element. (In Richtung Client) Den Content-Type-HTTP-Header stellst du in der Serverkonfiguration ein oder mit PHPs Funktion header().

                    Für das DBMS (MySQL angenommen) brauchst du den Anfang von Zeichencodierung/MySQL zu beachten.

                    Kommt noch hinzu das Korrigieren der bisherigen Daten.

                    daher brauche ich eine lösung, die funktioniert. ich scheitere schon daran, die sonderzeichen automatisch in der datenbank zu ändern, kann das aber eventuell in mühevoller kleinarbeit per hand tun.

                    UPDATE table SET feld=REPLACE(feld, '&#8486;', 'Ω')

                    wäre eine Möglichkeit für das Ω. Das müsstest du mit jedem Übeltäter einzeln durchführen. Zum Finden kannst du sowas wie feld LIKE '%&#%' verwenden.

                    schöner wäre es daher, wenn man mit den besagten einträgen, in meinem fall als entity kodiert, irgendwie fortfahren könnte.

                    Das ist wirklich nicht zu empfehlen, weil du damit weitere Probleme ungelöst hast, die dir irgendwann auf die Füße fallen. Du scheinst bisher auch noch nicht das Thema Kontextwechsel zu beachten, denn dann würden dir schon diese NCRs (Entitys sind die Dinger mit den Namen (&foo;), NCRs heißen sie, wenn sie Zahlenwerte sind (&#0815;)) Probleme bereiten, weil sie zwar bereits HTML-notiert sind, aber die HTML-eigenen Zeichen <>&" noch nicht. Damit kommt dann eine Eingabe wie

                    24&48 Ω <script>...</script>

                    als

                    24&48 &#8486; <script>...</script>

                    bei dir an. Und wie willst du jetzt die das erste & und die <> behandeln, das NCR-& aber auslassen?

                    es scheint aber zu funktionieren, wenn ich [...]

                    Mach es lieber richtig. Die Folgen der falschen Lösung abzuschätzen, um sie guten Gewissens einsetzen zu können, ist noch schwerer, als sich richtig ins Thema einzuarbeiten.

                    Lo!

                    1. Hello,

                      daher brauche ich eine lösung, die funktioniert. ich scheitere schon daran, die sonderzeichen automatisch in der datenbank zu ändern, kann das aber eventuell in mühevoller kleinarbeit per hand tun.

                      UPDATE table SET feld=REPLACE(feld, '&#8486;', 'Ω')

                      Aber Achtung!

                      Hier kommt es wieder darauf an, mit welchem Editor in welcher Einstellung Du das Statement eingibst/speicherst. Schließlich bedeutet die Darstellung auf dem Bildschirm auch nur eine Interpretation irgendwelcher Bytefolgen aus dem Speicher.

                      Das sollte dann also in der UTF-8-Einstellung des Editors stattfinden.

                      Liebe Grüße aus dem schönen Oberharz

                      Tom vom Berg

                      --
                       ☻_
                      /▌
                      / \ Nur selber lernen macht schlau
                      http://bergpost.annerschbarrich.de
                      1. Hi!

                        UPDATE table SET feld=REPLACE(feld, '&#8486;', 'Ω')
                        Aber Achtung!
                        Hier kommt es wieder darauf an, mit welchem Editor in welcher Einstellung Du das Statement eingibst/speicherst. Schließlich bedeutet die Darstellung auf dem Bildschirm auch nur eine Interpretation irgendwelcher Bytefolgen aus dem Speicher.

                        phpMyAdmin - der weiß, was er tut / zu tun hat. Alternativ geht jedes andere namhafte Verwaltungstool, zum Beispiel die MySQL Workbench.

                        Lo!

                  2. Hello,

                    ich fürchte, mich überfordert die ganze angelegenheit etwas. ich kann verstehen, dass die vorgänge komplexer sind, als ich bislang dachte, aber ich hab eventuell nicht die zeit, mich da einzufühlen.

                    Also einfacher kann man das nicht vorgekaut bekommen.

                    Jetzt gib Dir noch einen kleinen Ruck, und denk nochmal drüber nach. Und sonst frag nochmal. Du bist kurz vor dem Durchbruch mit dem Verständnis dafür, was wann wo passiert :-)

                    Liebe Grüße aus dem schönen Oberharz

                    Tom vom Berg

                    --
                     ☻_
                    /▌
                    / \ Nur selber lernen macht schlau
                    http://bergpost.annerschbarrich.de
                2. Hello,

                  Wir sollten uns endlich mal angewöhnen, das anders darzustellen!
                  Beim Server kommt beim Request ein Bytestream an, der entsprechend der Codierung zu behandeln. ist.
                  Bildlich dargestellt wird am Server gar nichts. Also bleibt es für das Script entweder bei der Bytefolge, die bei Benutzung von ISO-8859-1 im Browser als "24 &#8486" dargestellt werden würde, oder aber bei derjenigen, die bei Benutzung von ISO-8859-1 im Browser als "24 Ω" dargestellt werden würde.

                  Schön und gut, aber wenn du schon Bytefolgen propagierst, dann stell doch besser auch Bytes (als hex) und nicht nach Kodierung XY interpretierte Zeichen dar. Zum besseren Vorstellen kannst du ja zusätzlich die Interpretation gemäß diverser Kodierungen dazuschreiben.

                  Ich danke Dir für die Unterstützung. Ich wollte das vorhin auch machen, hatte aber nicht genug Zeit. Glegentlich klingelt bei mir das Telefon und dann muss ich springen :-)

                  32 34 20 26 23 38 34 38 36 3B
                  2  4     &  #  8  4  8  6  ;   ASCII

                  vs.

                  32 34 20 e2 84 a6
                  2  4     â  „  ¦  ISO-8859-1
                           └──┬───┘
                  2  4        Ω     UTF-8

                  So gefällt mir das schon fast :-)

                  Liebe Grüße aus dem schönen Oberharz

                  Tom vom Berg

                  --
                   ☻_
                  /▌
                  / \ Nur selber lernen macht schlau
                  http://bergpost.annerschbarrich.de
                  1. @@Tom:

                    nuqneH

                    So gefällt mir das schon fast :-)

                    Etwas hübscher in [articles-definitions-characters]

                    Qapla'

                    --
                    Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
                    (Mark Twain)
          2. hi,

            gut möglich. php nimmt aber den wert "24 &#8486;" aus der datenbank und schriebt ihn als value="24 &#8486;" in ein formularfeld und wenn ich das formular mit post übergebe, kommt auf der zielseite 24 Ω als ergebnis an.

            Logisch, im Formular steht dann ein Omega und das sendet der Browser auch.

            eventuell aber auch irgendein sonderzeichengeschwurbel dazwischen.

            Wenn das Formular utf-8-kodiert zum Browser kam und der Benutzer die Kodierung vor dem Absenden nicht umstellt, wird das Omega auch utf-8-kodiert zum Server gesendet.

            Hotti

            --
            Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
          3. Hello,

            PHP konvertiert nicht von selbst numerische Referenzen in Klartext - das machst du in irgend einer Form schon selbst.

            gut möglich. php nimmt aber den wert "24 &#8486;" aus der datenbank und schriebt ihn als value="24 &#8486;" in ein formularfeld und wenn ich das formular mit post übergebe, kommt auf der zielseite 24 Ω als ergebnis an.

            Definiere "Zielseite".

            Beim Client kommt dann nämlich nach wie vor "24 &#8486" an. Erste der Browser macht dann "Klartext" daraus, lässt also die HTML-Referenz im HTML-Kontext als "Ω" anzeigen.

            In ISO 8859-1 gibt es auch kein Ohm-Zeichen, sodass es beim nächsten Request auch wieder dabei bleiben müsste.
            http://de.wikipedia.org/wiki/ISO_8859-1

            Wenn die Ressource allerdings in der Codierung UTF-8 ausgeliefert würde, der Client daher annehmen darf, dass auch der nächste Request in UTF-8 codiert gesendet werden darf, dann findet (in Eingabefeldern, wo auch sonst?) eine Ersetzung statt. Intern behandelt der Browser die Zeichen ohnehin in UTF-8-Codierung.

            Soweit jedenfalls mein Verständnis nach ein paar eigenen Tests. Man möge mich bitte korrigieren, wenn es nicht stimmt, was ich hier von mir gebe. Ich will auch keinen Dr. dafür haben ;-P

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
            1. Hi!

              Beim Client kommt dann nämlich nach wie vor "24 &#8486" an. Erste der Browser macht dann "Klartext" daraus, lässt also die HTML-Referenz im HTML-Kontext als "Ω" anzeigen.
              In ISO 8859-1 gibt es auch kein Ohm-Zeichen, sodass es beim nächsten Request auch wieder [eine NCR werden] müsste.

              Das ist nicht gesagt, denn es gibt keine Vorschrift, was bei mit der für das Senden zum Server verwendeten Kodierung nicht darstellbaren Zeichen passieren soll, die da ein Anwedender eingibt. Einige Browser machen NCRs draus, andere was anderes. Und diese NCRs sind weder zu unterscheiden von händisch eingegebenen NCRs noch werden die HTMLeigenen Zeichen als NCR oder Entity versendet. Man bekommt dann Mischmasch und weder reine Zeichen noch ordentliches HTML. Wenn man diesen Mischmasch wieder ausgeben will, bekommt man bei kontextgerechter Verwendung von htmlspecialchars() die NCRs angezeigt, weil sie nun als &amp;#8486; an den Browser gehen. Oder man lässt die Maskierung und hat sich eine HTML-Injection-Lücke. Kurz: Das Verhalten der Browser ist kontraproduktiv - lieber UTF-8 durchgängig verwenden.

              Wenn die Ressource allerdings in der Codierung UTF-8 ausgeliefert würde, der Client daher annehmen darf, dass auch der nächste Request in UTF-8 codiert gesendet werden darf, dann findet (in Eingabefeldern, wo auch sonst?) eine Ersetzung statt. Intern behandelt der Browser die Zeichen ohnehin in UTF-8-Codierung.

              Wenn ich Browser wäre, würde ich lieber UTF-32/UCS-4 mit konstant 4 Byte pro Zeichen verwenden, da kann man besser zum Beispiel Positionen von Zeichen berechnen als bei UTF-8 mit der unterschiedlichen Anzahl an Bytes pro Zeichen. Aber egal - was der Browser intern macht, ist nicht weiter wichtig. Wichtig ist nur, dass er den kompletten Unicode-Zeichenvorrat verarbeiten kann.

              Dass der Browser zum Kodieren des Formularrequests die Kodierung der Seite verwendet, in der das Formular steht, scheint von allen Browsern eingehalten zu werden [1]. Es gibt zwar das accept-charset-Attribut für das Formular, aber nicht alle noch relevanten Browser halten sich an einen dort angegebenen Wunsch. Zudem kann man da zwar mehrere Werte eintragen, der Browser sagt einem aber nicht, welchen er verwendet hat. Lieber weglassen, dann hat wenigstens die HTML-Spezifikation eine Darf-Aussage: The default value for this attribute is the reserved string "UNKNOWN". User agents may interpret this value as the character encoding that was used to transmit the document containing this FORM element.

              Die Kodierung passiert jedenfalls nicht in den Eingabefeldern - als Browser-Benutzer sieht man davon nichts -, sondern irgendwo zwischen Auslösung des Formular-Submits und dem Absenden des Requests an den Server - ist aber auch nebensächlich.

              [1] Aussage gemäß Sarrazin-Methode: Augenscheinliche Beobachtung und niemand hat es bisher widerlegt.

              Lo!

        2. Hello,

          das problem, auf das ich gerade komme, ist, das, der wert 24 &#8486; zu 24 Ω umgewandelt wird. nur darum werden die 24 Ω überhaupt also solche übergeben. was mich zu der frage bringt, wie ich php dazu bringe, die 24 &#8486; nicht als 24 Ω als wert einzutragen. denn wenn es wirklich 24 &#8486; wären, die übergeben werden würden, hätte ich das ganze problem mit dem zurückwandeln nicht. gibt es da einen php befehl, der mir nicht einfallen will?

          PHP konvertiert nicht von selbst numerische Referenzen in Klartext - das machst du in irgend einer Form schon selbst.

          Du meinst, PHP konvertiert nicht automatisch kryptische numerische Refernezen in kryptische Bytefolgen nach UTF-Regeln?

          Von "Klartext" hat PHP sowieso keine Ahnung.

          Liebe Grüße aus dem schönen Oberharz

          Tom vom Berg

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de