Isotope Demo installiert - CSS fehlt anscheinend

[franc]

Ja, das war hier in dem Thread nie Thema. Das hat sich rumgesprochen, dass wir ohne BOM speichern und auch dass ein Entwickler keinen notepad.exe verwendet

Was sollte denn dann das Beispiel?

[the_scrat]

Natürlich. Aber bei einem Misch-Masch muss der Editor im Endeffekt einfach erraten, was das "richtige" Encoding ist.

Das stimmt, aber im Ursprungspost gab es kein MischMasch ;-) Die Aussage die ich für falsch hielt und halte ist, dass ein Editor immer "raten" müsse, was er ja nicht muss, wenn eine Datei in Ordnung ist. Kommt natürlich eine MischMasch Datei mit unterschiedlichen Kodierungen (was in der Praxis eigentlich nicht passieren dürfte) dann muss natürlich geraten bzw. hardcore "entschieden" und nachträgliche konvertiert werden. Ich glaub wir steuern hier in eine Theoriewolke aus der wir nicht mehr rauskommen.
Fakt ist: Die mysql Datei von isotope war/ist und wird utf-8 kodiert sein. Fakt ist, spielt man die Datei mit utf-8 ein, funktioniert der Import (mit oder ohne hex-werten) ;-)

[Spooky]

Das stimmt, aber im Ursprungspost gab es kein MischMasch ;-) Die Aussage die ich für falsch hielt und halte ist, dass ein Editor immer "raten" müsse, was er ja nicht muss, wenn eine Datei in Ordnung ist. Kommt natürlich eine MischMasch Datei mit unterschiedlichen Kodierungen (was in der Praxis eigentlich nicht passieren dürfte) dann muss natürlich geraten bzw. hardcore "entschieden" und nachträgliche konvertiert werden.

Doch, der Editor muss es "erraten", weil die Kodierung einer Datei nicht vorgegeben ist. Es ergibt sich aus dem Inhalt, und der Inhalt kann praktisch irgendwas sein.

[the_scrat]

Wir drehen uns im Kreis! Wenn eine Datei sauber abgespeichert wurde (ohne BOM) dann hat doch das herausfinden der dazugehörigen Kodierung nichts mit "raten" zu tun, sondern es werden diverse Regeln durchgetestet auf welche der Inhalt passt.
Wenn der Inhalt nur 1 Zeichen ist (z.B. ein "a") dann kann es rein theoretisch mehrere Kodierungen sein, dann wird halt der default vom Editior genommen. Meist jedoch wohl utf-8. Ist aber -selbst- bei einem Zeichen erkennbar (z.B. durch das folgende 00 Hex) kann es schon kein utf-8 sein, sondern UNICODE. Für mich hat das nicht mit raten zu tun, sondern Regeln/Vorgaben.

Wahrscheinlich meinen wir das gleiche, hängen uns aber am Begriff "raten" auf ;-)

[Spooky]

Wir drehen uns im Kreis! Wenn eine Datei sauber abgespeichert wurde (ohne BOM) dann hat doch das herausfinden der dazugehörigen Kodierung nichts mit "raten" zu tun, sondern es werden diverse Regeln durchgetestet auf welche der Inhalt passt.

Ob der Inhalt "sauber" abgespeichert wurde oder nicht weiß der Editor ja nicht. Beim öffnen einer Datei muss der Editor daher aufgrund des Inhalts "erraten", welche Kodierung vorliegt. Deutet alles bspw. auf UTF-8 hin, nimmt er UTF-8 - könnte aber trotzdem vermeintlich falsch sein.

[the_scrat]

Ja gut, dann "errät" auch jeder Kompass die Richtung. Norden mag zu 99,9% Norden sein, es sei denn ich halte mich in einer Metallspule auf die unter Strom steht.
Ich weiß was du meinst, dennoch wird es in der Praxis, gerade bei generierten Dateien (wie einem sql-export) wohl eher selten bis garnicht vorkommen, dass unterschiedliche Kodierungen vorliegen. Und der Standard dürfte ja mittlerweile bei jedem Editior sowieso utf-8 sein. Demnach müsste jeder Editor nur prüfen (gibt es irgendwas, was gegen utf-8 spricht (z.B. bestimmte HEX-Werte), ansonsten nehm ich utf-8)

[franc]

Zum Thread-Problem: der Bug wurde geschlossen, "netzarbeiter" hat eine SQL-Datei mit HEX-Import (statt UTF8) hochgeladen, ich vermute die wird oder wurde schon in das Demopaket verbaut.

...dennoch wird es in der Praxis, gerade bei generierten Dateien (wie einem sql-export) wohl eher selten bis garnicht vorkommen, dass unterschiedliche Kodierungen vorliegen...

Und bei mir im Besonderen lag es dann also wohl an den Tools, die allesamt kein UTF-8 geraten/gelesen hatten. Ich hab die Datei ja in drei verschiedenen MySQL Tools (Toad, MySQLWorkbench, MySQL Query Browser) sowohl auf Mac als auch auf PC offenbar nicht richtig einlesen können. Das verblüfft mich immer noch.
Aber im Terminal ging es auf Mac und PC problemlos, da war ja kein Editor dazwischen.
Ich bin jetzt ggü. diesen Tools etwas verunsichert. MySQL Query Browser ist ja längst veraltet, aber Toad oder Workbench sind aktuell, werden weiter entwickelt.

Auch wundert mich, dass ich hier im Thread anscheinend der einzige bin, der diese Tools verwendet, obwohl die doch praktisch (schneller als pma) sind.

[the_scrat]

...mit HEX-Import (statt UTF8) hochgeladen

Das eine hat doch mit dem anderen überhaupt nichts zu tun. UTF8 ist die Datei nach wie vor!! Nur dass die Werte in der Spalte nun sauber in HEX gespeichert wurden.

[Spooky]

Ich weiß was du meinst, dennoch wird es in der Praxis, gerade bei generierten Dateien (wie einem sql-export) wohl eher selten bis garnicht vorkommen, dass unterschiedliche Kodierungen vorliegen.

Doch, genau hier haben wir ja so einen Fall. Das ursprünglich generierte SQL file ist zwar generell in UTF-8 kodiert, die Daten der binären Felder wurden aber nicht als Hex Notation exportiert. Daher sind dort einfach irgendwelche binären Daten. Du hast also in dem SQL file einen Misch Masch aus UTF-8 und undefinierten binären Daten. Wenn der Editor entscheidet, dass er zum dekodieren der Daten UTF-8 verwendet, wendet er das auf die kompletten Daten der Datei an, inkl. den binären Feldern. Daher siehst du dort auch irgendwelche seltsamen Zeichen.

Und die interpretation dieser Zeichen ist dann auch der Grund, warum es bei einem Import dann zu einem "duplicate entry" Fehler kommen kann. Weil die binären Daten als String interpretiert werden und es da dann zufällig zu gleichen Zeichenfolgen kommt - je nach Interpretation, also je nachdem was der jeweilige Parser für diese Daten "geraten" hat.

[the_scrat]

Achso, ok, ja das macht tatsächlich sinn..... hmmmmm ja. Trotzdem komisch, dass ich die Datei dann dennoch importieren konnte. Der Fehler lag dann im Editor (Workbench) der hier versucht hat ne eigene Interpretation zu starten und diesen MischMasch dann zu verarbeiten, richtig?

[Spooky]

Ja, wie die einzelnen Tools in solchen Fällen dann genau vorgehen kann ich auch nicht sagen. Aber es ist definitv möglich, dass das Tool die Daten des jeweiligen Feldes zuerst als String reinterpretiert und dann in die Datenbank speichern will - anstatt die binären Daten direkt in die Datenbank zu speichern.

Bei PHP musst du ja auch aufpassen, wenn du in irgendeiner Form mit binären Daten hantierst (siehe zB pack()/unpack()).

[franc]

UTF8 ist die Datei nach wie vor...

Klar ist die Dateikodierung immer noch UTF-8, aber ich meinte die Binären Daten der Blob Felder. Die sind jetzt im HEX-Format, wie es sich gehört (ich glaube wenigstens, dass es sich so gehört).
EDIT: hat sich grad überschnitten
Es ist auf jeden Fall immer wieder gut und nützlich, das Thema Kodierung zu vertiefen bzw. sich wieder zu vergegenwärtigen. Ich vergesse es teils immer wieder, teils lerne ich da neu hinzu.

[Andreas]

Was sollte denn dann das Beispiel?

Wieso Beispiel? Das war der Versuch einer Auflistung woran ein Editor erkennen könnte wie eine Datei kodiert ist und der BOM gehört dazu.

AFAIK wird mehr oder weniger versucht den BOM auszulesen (falls vorhanden), eine Anweisung in der Datei zu finden, z.B. in HTML, oder zu raten.

Aber hier in unserem Umfeld speichern wir keine Dateien mit BOM, weil PHP den BOM beim Einlesen als Inhalt erkennt oder so ähnlich. Kann sein, dass es irgendeine Sparte gibt, wo man Dateien mit BOM speichert (speichern muss), keine Ahnung.

[lucina]

[Moderation: Seid doch bitte so gut und sagt mir, wohin ich Euer Gespräch auslagern soll. Mit dem Ursprungsthema hat das ja nun nichts mehr zu tun. Danke.]

[Spooky]

Einfach ins Off Topic unter dem Titel Encoding Shenanigans oder so . Teile davon sind aber für das Ursprungsthema relevant, also insbesondere die Erklärung warum es zu dem Fehler kommt.