flaimo: geschütztes leerzeichen (utf-8) wird von formular nicht erkannt

folgendes: valide xhtml seite im utf-8 zeichensatz gehalten. formular hat accept-charset="utf-8". datenbank und php sind auch so konfigutiert, dass sie mit utf-8 können. funktioniert auch alles soweit, sonderzeichen werden problemlos geschluckt, bis eben auf das geschützte leerzeichen. das wird komischerweise immer als einfaches leerzeichen ausgegeben.
stellt sich nun die frage ob die browser drann schuld sind, oder ob der fehler doch wo bei der db (sqlite) bzw php liegt …

  1. hi,

    folgendes: valide xhtml seite im utf-8 zeichensatz gehalten. formular hat accept-charset="utf-8". datenbank und php sind auch so konfigutiert, dass sie mit utf-8 können. funktioniert auch alles soweit, sonderzeichen werden problemlos geschluckt, bis eben auf das geschützte leerzeichen. das wird komischerweise immer als einfaches leerzeichen ausgegeben.

    das heißt ...?
    hex-code A0 an der stelle im erzeugten dokument?

    gruß,
    wahsaga

    --
    "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
    1. hex-code A0 an der stelle im erzeugten dokument?

      ja, in ultraedit werden die beiden leerzeichen ja auch unterschiedlich dargestellt und beim browser resizen dürfte er an der stelle ja nicht umbrechen.

  2. hab im vorherigen posting übrigens auch das geschützte leerzeichen verwendet und hier wurde es auch nicht genommen, die horizontale ellipse (…) allerdings schon

    1. hi,

      hab im vorherigen posting übrigens auch das geschützte leerzeichen verwendet und hier wurde es auch nicht genommen, die horizontale ellipse (…) allerdings schon

      ich würde mal sagen, xA0 ist für html nun mal einfach kein geschütztes leerzeichen, sondern einfach nur ein normales blank - wenn du ein geschütztes leerzeichen willst, dann verwende halt das entity   (oder eine seiner anderen, nummerischen schreibweisen).

      kannst ja xA0 dadurch ersetzen lassen, wenn du die anzeige geschützter leerzeichen derart möglich machen willst.

      gruß,
      wahsaga

      --
      "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
      1. aber wenn ich das unicode zeichen U+00A0 (NO-BREAK SPACE) direkt in ein html dokument reincode wirds ja auch akzeptiert und richtig dargestellt und es erfolgt kein zeilenumbruch.   is ja nur das entity wenn man einen anderen zeichensatz verwendet. und das entity will ich nicht in der datenbank haben. saubere trennung von daten und darstellung, und so.

        1. hi,

          aber wenn ich das unicode zeichen U+00A0 (NO-BREAK SPACE) direkt in ein html dokument reincode wirds ja auch akzeptiert und richtig dargestellt und es erfolgt kein zeilenumbruch.

          erscheint denn dein "geschütztes leerzeichen" vom formular als U+00A0, oder ist es nur ein A0?

          gruß,
          wahsaga

          --
          "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
          1. ich gebe das geschützte leerzeichen in das formularfeld ein und speichere es, ausgegeben wird aber das normale leerzeichen (U+0020).

            geb ich z.B. × ein wird auch ein × ausgegeben

      2. Hi,

        ich würde mal sagen, xA0 ist für html nun mal einfach kein geschütztes leerzeichen, sondern einfach nur ein normales blank

        Nö. Wenn die Kodierung ein Zeichen direkt zuläßt, sollte es egal sein, ob ein Zeichen direkt oder per Entity benutzt wird.

        In einem p-Element funktioniert es auch sowohl in Firefox, Opera und IE.
        In einer textarea macht der IE hier aber Unsinn - das non-breaking des non-breaking-Space wird ignoriert.
        Opera äfft den IE wieder mal nach.
        Firefox machts auch in der Textarea richtig und zeigt einen horizontalen Scrollbalken.

        Siehe auch Testseite dazu: http://temp.andreas-waechter.de/space.html

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
        1. um das gehts mir im prinzip nicht. das problem ist, dass das zeichen anscheinend nicht übertragen und in die datenbank geschrieben wird und irgendwo auf dem weg von einem geschützten leerzeichen in ein normales umgewandelt wird.

    2. das problem ist gelöst. schuld ist ein bug in der gecko engine. siehe:

      https://bugzilla.mozilla.org/show_bug.cgi?id=218277
      https://bugzilla.mozilla.org/show_bug.cgi?id=194498