EINSCHRÄNKUNGEN | Edomi

[wintermute]

Ein LBS darf aber NICHT einen String wie $n='ma'.chr(164).'ana'; in ein KO/Ausgang/etc. schreiben.

Nur aus Interesse gefragt (denn noch kann ich das ja nicht selber ausprobieren ): was passiert wenn das trotzdem der Fall ist?

[coliflower]

Dann kann ich die Playlist, Album, Artist, usw. als Rückmeldung von iTunes an Edomi schön in einem String weiterschicken
Danke !

[gaert]

z.B. ein chr(164) würde in "?" konvertiert werden, da es kein ASCII-Zeichen ist. Das Ganze ist etwas kompliziert, da PHP auf UTF-8 einstellt ist, mySQL aber quasi auf ASCII (und bei Bedarf UTF-8). Das heisst: mySQL speichert Strings grundsätzlich als ASCII[0..127] (1 Zeichen = 1 Byte). Sonderzeichen (Umlaute, etc.) werden einzeln(!) als UTF-8 kodiert gespeichert. Das spart Platz und Ressourcen, denn ein kompletter UTF-8-String wäre ja doppelt so groß wie ein ASCII-String.

Aaaaaber: In der Praxis ist das vollkommen Wurscht, solange man ganz normal mit Strings hantiert - also z.B. $n="mañana". Nur kann/darf man keine Byte-Werte(!) wie chr(164) in einen String packen. Hintergrund ist, dass der Text-Editor mit dem man am LBS arbeitet, die LBS-Datei (hoffentlich) UTF-8-kodiert speichert (der interene LBS-Editor macht das ohnehin). Das bedeutet: Der Editor zeigt zwar $n="mañana" an, speichert aber letztlich etwas wie $n="ma\x00A4ana"

[wintermute]

check

[saegefisch]

Die Erklärung zu UTF8 kann ich nicht ganz nachvollziehen, da ja UTF8 genau für die ersten 127 Zeichen zu ascii deckungsgleich ist und nur 1byte braucht. Daher wäre es nicht doppelt so groß. Nur darüber zieht es automatisch 2bytes. Würden wir von UTF16 reden, würde ich dir zustimmen.

daher: warum nicht echtes UTF8 im MySQL? Das macht implizit genau das, was du beschreibst...

[gaert]

Es ist ja quasi echtes UTF-8 - Umlaute etc. sind durchaus möglich. Es geht hier nur um "Raw-Daten", also z.B. einen String, der die Bytes(!) x00 x01 x02 ... xFF enthält. Das macht ja kein normaler Mensch Ich habe dies nur zur Sicherheit so kompliziert veranschaulicht, damit niemand z.B. auf den Gedanken kommt, JPG-Daten oder MP3s per KO zu verarbeiten...

[saegefisch]

Oh, okay. Fairer Gedanke!

[gaert]

Die Umstellung dauert übrigens noch ein paar Tage - ist sehr viel Arbeit, da ich damals etwas derartiges nicht vorgesehen habe... Wie gesagt: Die Länge ist nicht das Problem, sondern das korrekte escapen der Sonderzeichen usw. - und das auf mehreren Ebenen (PHP, JS, HTML, mySQL).

[coliflower]

Hallo Christian,

ich sollte in meinem LBS (iTunes) folgende Zeile einfügen

$data = preg_replace("/[^A-Za-z0-9&=]/",'',$data); 

Wird das Gegenstandslos mit dem „String“ Update ?

[gaert]

Kommt drauf an, was du bezweckst... Der Code erlaubt nur Buchstaben Ziffern und & und =. Wenn das erwünscht ist, sollte der Code bleiben.

[coliflower]

Na ja, wenn ich in Zukunft auch die Albennamen, Titeln, usw. aus iTunes in der VISU darstellen möchte, dann gibe es da auch Umlaute und Sonderzeichen ... Sollte ich dann den Code anpassen oder lieber ganz weg lassen ?

Hast du auch für mich einen guten, leicht verständlichen Link zum Nachlesen wie ich so einen String mit Umlauten, Leerzeichen und Sonderzeichen via ECHO von Mac an Edomi übermitteln kann ? DANKE !