Vor dem Umwandeln zählen

Gute Idee ;o)

Nee, mal im Ernst. Die Daten werden in die Datenbank gepackt.
Und ich muss zum späteren Zeitpunkt die Daten wieder auslesen und die Länge genauso ermitteln können.

Aber für einen Moment hatte ich gedacht, das es eine gute Idee ist ;o)

Originaldaten in die DB schreiben und immer erst bei Ausgabe durch die Funktion schicken? Alles andere würde ich als unpraktikabel einstufen. Was du an Geschwindigkeit durch das kodierte Speichern gewinnst, verlierst du wieder durch komplizierte Funktionen zur Berechnung der Characterlänge.

Meine seite soll aber weltweit nutzbar sein, dh. auch chinesische Schriftzeichen sollen einwandfrei gespreichet werden.
Um Codierungsprobleme zu vermeinden ist dieses Vorgehen nicht schlecht.
Außerdem, einmal in der Datenbank als Unicode, kann man auf jedem Browser, der die Anzeige unterstützt, immer das leich Zeichen sehen. Immer und überall auf dieser Welt. und das alles ohne hin und hercodoeren. Einfach gleich richtig in die Datenbank.

Ich zumindenst finde das nicht übel.

Grüße

Vici

Dann zähle die Zeichen vor dem Codieren und speichere die Anzahl mit in die Datenbank

Ich arbeite seit einigen Jahren (wegen UTF- ausschließlich mit MbString:

PHP: Multibyte String
--> PHP: mb_strlen - Manual


Ohne vorherige Initialisierung des Charsets auf UTF-8 würde es dann so funktionieren:


MfG,
Sascha

Mir fällt da nur die folgende Lösung ein:

Die Länge eines Strings ermittelst du mit [MAN]strlen[/MAN]. Strlen Versteht aber keine Multibytezeichen (Unicode sind Multibyte zeichen mit 1-3 Bytes). Versuche mal [MAN]mb_strlen[/MAN]

// Zu langsam ^^

Dagegen, Unicode in die Datenbank zu speichern, sage ich ja gar nichts. Aber um das zu erreichen, was du da beschreibst, reicht es, das DB-Feld einfach auf UTF-8 oder so zu setzen und die Originalstrings einzutragen. Die von dir angesprochene "Kachel-Funktion" hat damit gar nichts zu tun. Bei der geht es darum, XSS bei der Ausgabe zu verhindern.

Bitte nicht.

@mermshaus
ja, du hast völlig recht. ich habe mich da etwas unglücklich ausgedrückt. natürlich verbinde ich beide Vorteile (so dachte ich zumindenst). Die Verarbeitung von Unicodezeichen und das Vehindern von XSS.

Aber mal was anderes: Was ist das denn für ein Unicode, der bei der Kachel-Funktion da rauskommt: ü = ü

Das ist doch nicht UTF-8 ??? Oder doch. Zumindenst sah UTF-8 in der Datenback anders aus.

Ich frage deshalb, weil die gute Idee von Sascha Ahlers
Leider nicht funktioniert. Es werden trotzden 12 Zeichen ausgegeben. Wenn das UTF-8 wäre, müsste es doch klappen???

Was für eien Unicode-Vesion ist das denn??

Grüße

vici

Korrektur: Mein String auf der Datenbank sieht natürlich so aus: Hütte
Also mb_strlen('Hütte', 'utf-8'); wäre richtiger.

Müßte ascii sein. Einfach mal googlen.

grüße

Hmm, speicherst Du etwa den String erst nachdem Du ein HTML-Entity durchgeführt hast?

Ergo musste auch einen Charset wählen der damit umgehen kann, oder die Zeichen in die Datenbank speichern ohne vorher einen HTML-Entity zu machen, sondern erst vor der Ausgabe, damit umgehst Du auch Probleme mit der größer Deiner Datenfelder in der Datenbanktabelle.


Versuch doch mal das (kann hier aber keine Garantien für vergeben, ist nur so ein Einfall):
Ansonsten kann Dir das noch viel Spass bieten:
PHP: mb_decode_numericentity - Manual
PHP: mb_encode_numericentity - Manual


Ich würde Dir aber grundsätzlich eher empfehlen in der Datenbank keine Strings zu speichern, die bereits mittels HTML-Entity bearbeitet worden sind, wenn Du mit diesen noch Prüfungen oder ähnliches anstellen möchtest. Nachher möchtest Du ein Regex darüber laufen lassen, oder bei MySQL-MyISAM eine Volltextsuche. Nach meiner Erfahrung stellt man sich dann irgendwann selber ein Bein und darst dann alles umstellen.


Gruß,
Sascha

@Sascha Ahlers
Ich glaube du hast recht.
Ich verzettele mich zu sehr und dann kommt der große Knall.

Also, dann mal Frage um Tip:
Ich will eine Seite machen (wie erwähnt), die alle UTF8 Zeichen speichern und auch überall ausgeben kann.

Grundsätzlich (und abgesehen davon) habe ich header() und <meta> und mySQL auf UTF-8 gestellt.

Nun Frage ich ganz normal Input-Felder ab.

Direkt nach dem Absenden (Submit) behandele ich Sie wie Folgt:
In der Datenbank steht dann sowas wie "Müller" für "Müller".

Die Ausgabe im Browser (also das Einlesen a.d. Datenbank erfolgt über
Soweit sogut.

Wenn das der gängige weg ist, eine "globale" Seite zu gestalten, dann bleibe ich dabei und mache das so weiter.

Gebt mir Eure Meinung.

Grüße

Vici

Ich glaube hier reden einige von Unicode, obwohl sie einen Character Entity meinen und nicht direkt Unicode. Unicode ist ein Zeichensatz, den ich, wenn ich einen unicodefähigen Editor habe auch entsprechend anzeigt, da steht dann halt auch Hütte. Einziger Unterschied ist, dass die Zeichen eine andere Kodierung haben, was in menschlich vorstellbarer Form wie folgt aussehen kann U+xHHHH (Unicode Point Code; Bsp. "ü": U+x00FC).

H&#x00fc;tte hingegen ist die schreibweise, wenn das "ü" durch einen Character Entity läuft. Es wird also keine reine Unicode Speicherung durchgeführt, sondern es wird eher ein String gespeichert, der durch einen Entity lief.

List of XML and HTML character entity references - Wikipedia, the free encyclopedia



Dann ist vermutlich Deine Datenbank, Deine Datenbanktabelle oder das Datenbanktabellenfeld nicht auf Unicode eingestellt, sondern Du schreibst wohl in einen anderen Zeichensatz rein. Das Beispiel sieht z.B. typisch dafür aus, dass Du ein UTF-8 String in ISO-8859-1 oder ISO-8859-15 zu quätschen.

Wie ist denn Deine Tabelle aufgebaut und welcher Charset wird dort verwendet?

Auch auf die Gefahr hin, dass das hier mittlerweile etwas redundant ist...

@vici:

Du scheinst da in Sachen Unicode leicht auf dem falschen Dampfer zu sein.

&#x00fc; ist eine HTML-Entity-Darstellung (sowas wie &auml;), eine HTML-spezifische ASCII-kompatible Repräsentation des Unicode Codepoints U+00FC ("ü").

In UTF-8 wird das "ü" durch die beiden Bytes C3 BC kodiert. Entscheidend ist nun, wie das darstellende Programm diese beiden Bytes interpretiert. Wenn es weiß, dass ein String in UTF-8 vorliegt, kann es C3 BC korrekt als ein Zeichen entschlüssen und ein "ü" rendern.

Die meisten Datenbank-Administrationsprogramme und Browser sind in der Lage, die Zeichen entsprechend korrekt zu interpretieren und darzustellen. Das heißt, du wirst nie etwas Anderes sehen als "ü" oder meinetwegen auch "シ" (E3 82 B7), um mal einen komplizierteren Charakter zu wählen.

Wenn du in deinem Editor das Encoding einer Datei auf UTF-8 umstellst und dann ein "ü" tippst und speicherst, ist der Inhalt passend "konvertiert". Geschrieben werden die beiden Bytes C3 BC, dargestellt wird "ü". Änderst du das Encoding nun auf ISO-8859-1, werden C3 BC als zwei einzelne Zeichen interpretiert: "ü".

Das heißt, ein UTF-8-String kann in "Reinschrift" in die DB geschrieben und direkt unverändert ausgegeben werden, wenn der Code als UTF-8 an den Browser gesendet wird (zu empfehlen).

Irgendwie ist das schwierig zu erklären. Wikipedia kann das bestimmt besser.

@vici (neuer Post):

Das Umkonvertieren sollte völlig unnötig sein. Hier mal ein grober Umriss, da an dem Code noch ein paar andere Sachen angemerkt werden könnten (mysql_real_escape_string usw. nicht vergessen!):