Isotope Demo installiert - CSS fehlt anscheinend

Hallo

ich habe mal testweise lokal die Demo für Isotope installiert, auf meinem Windows PC (Win8.1-64) mit Apache 2.4 und PHP 5.5.
Die Demo enthält derzeit Contao 3.5.8 und isotope 2.3.

Das Backend schaut zwar normal aus, also die Isotope Produkte sind drin und die Einstellungen, aber im Frontend fehlt anscheinend das CSS, siehe Screenshot:

Anhang 17667

Außerdem lese ich dieses berüchtigte: "Dieses Element verwendet noch das alte Contao 2 SRC-Format. Haben Sie die Datenbank aktualisiert?"
Die DB wird im Installtool aber als aktuell angezeigt.

Hab ich da etwas übersehen?
Muss ich da noch mehr tun, als das (Dateien, DB, Installtool) ganz einfach nur installieren?

In der pathconfig.php steht auch der richtige Pfad return '/isotope'; drin.
Ich habe dann auch noch alle Erweiterungen aktualisiert ohne Änderung.
Im BE in Layouts / Themes / "Isotope Demo - DE" / CSS
sehe ich übrigens "Keine Einträge". Komisch.

Danke

franc

Langsam wird mir klar warum, grrr.
Das Einlesen des SQL-Skripts wirft ja bald einen Fehler:

Code:

---

Duplicate entry 'B?{?U\xA5\x11?(\xBC0[5g?' for key 'uuid'

---

Das Skript hatte ich dann mit Toad for MySQL dennoch weiter eingelesen, danach kommt nämlich kein Fehler mehr.
Ich dachte der überspringt dann nur einen einzigen Datensatz, aber Pustekuchen, das betrifft dann die ganze Tabelle

Code:

---

INSERT INTO `tl_files`...

---

Da ist dann nämlich nur eine Zeile drin und das ist u.a. die CSS Tabelle, da sind Bilder u.a. drin. Klar, dass das CSS dann fehlt.

Die SQL-Datei im Zip (oder die vom tar.gz genauso) von der Demoseite ist schadhaft, tolle Sache :(

Das wurde beim Speichern offenbar falsch codiert, ich hab es aber nicht hin gekriegt das zu korrigieren, habe einiges versucht. Es wurde vermutlich auf einem Mac erstellt, das ZIP, da sind die typischen Mac-Kotspuren drin.
Aber auf einem Mac konnte ich es auch nicht öffnen, direkt entpackt, also es wird gar nicht eingelesen, das Skript. Erst wenn man es kopiert und in eine neue Textdatei einfügt, aber da geht wohl der Inhalt verloren.

Dieser INSERT-Befehl funktioniert jedenfalls nicht, die Binärdaten sind beim Speichern schon verpfuscht worden offenbar.

Anscheinend wurde das dann auch nicht getestet, sonst hätte man das ja gemerkt.

Damit kann ich dieses Demo wohl vergessen.

So, ich schreib jetzt einen Bug ins github. Gibt zwar das Demo nicht im Github, schreibe es halt ins core.
Mal sehen, ob es jemand interessiert.

Hi,

keine Ahnung was du gemacht hast, ich hab die SQL gerade wunderbar ohne Fehlermeldung vollständig importieren können!
Hast du dich denn auch an die Beschreibung des Handbuchs gehalten? Die DB im utf8_general_ci Format angelegt? Und beim Import selbst die Kodierung auf utf8 gestellt, wie es in der bebilderten Anleitung zu sehen ist?

Wenn ich im aktuellen MySQLWorkbench schon allein die Datei öffnen will, erhalte ich eine Warnung:

Unknown File Encoding
The file '/Users/f/Documents/TEMP/isotope_demo_2.3.4/isotope_ecommerce.sql' is not UTF-8 encoded.

Ich denke, da liegt der Pfeffer im Hasen drin. Die DB ist schon utf8 (Default characterset), lese ich im Workbench über die DB.
Das meine ich.
Den PHPMyAdmin verwende ich lokal ja nicht.

Zitat:

---

Zitat von franc

Den PHPMyAdmin verwende ich lokal ja nicht.

---

Dann solltest du das mal machen ;-) Also ich hab die SQL ganz normal über PHPMyAdmin eingespielt, passt.

Ich hab mir jetzt extra nochmal die Demo Zip runtergeladen und die SQL entpackt. Wenn ich diese im Notepad++ öffne, wird mir ebenfalls angezeigt, dass die Datei UTF-8 ohne BOM kodiert ist. Also irgendwas ist da mit deinem MySQLWorkbench falsch.

Moment mal, wie soll Notepad++ denn wissen, wie die Datei kodiert ist? Das steht doch nirgends.
Ich verwende zwar kein Notepad++ sondern auf Windows EditPad Pro, aber das ist vermute ich gleich vom Prinzip. Ich stelle da ein, als was der mir die verschiedenen Dateitypen interpretieren soll, also z.B. SQL-Dateien als UTF-8. Dann öffnet der mir eine sql Datei als UTF-8 und zeigt an dass es eine sei.
Ob die Datei tatsächlich als UTF-8 codiert wurde, kann der aber nicht wissen.
Ist das bei Notepad++ anders?

Falls du das also grad zur Hand hast, könntest du vielleicht einfach hier mal diesen einen Insert Befehl posten, also den insert into tl_files ...
Danke!

Zitat:

---

Zitat von franc

Moment mal, wie soll Notepad++ denn wissen, wie die Datei kodiert ist? Das steht doch nirgends.

---

Das muss auch nirgends stehen, jede Datei hat von Haus aus eine Kodierung.

PHP-Code:

---

INSERT INTO `tl_files` (`id`, `pid`, `tstamp`, `uuid`, `type`, `path`, `extension`, `hash`, `found`, `name`, `meta`, `importantPartX`, `importantPartY`, `importantPartWidth`, `importantPartHeight`) VALUES
(78, 'Ȝr:ޟw㓳ܰ[5gڧ, 1393482146, 'Ȝr:ʟw㓳ܰ[5gڧ, 'file', 'files/downloads/.htaccess', 'htaccess', 'bff88aa9f255706dd1e53e330cb1a7b7', '1', '.htaccess', NULL, 0, 0, 0, 0), 


---

Irgendwas machst du jedenfalls falsch, denn ich konnte die gesamte SQL wunderbar importieren, ohne Fehler!

Im SQL File von Isotope sind die binären Felder nicht in hexadezimaler Notation exportiert worden, das kann solche Probleme verursachen. Wenn man SQL Tools in neuesten Versionen benutzt, sollte es aber funktionieren.

Auf dem Mac im Terminal hat es jetzt geklappt!
Also die entpackte Datei direkt per Kommandozeile eingelesen:

Code:

---

mysql  --user=root --password=geheimespasswort isotope < /Users/f/Documents/TEMP/isotope_demo_2.3.4/isotope_ecommerce.sql

---

Kein Fehlerauswurf.
Anscheinend habe ich nur alte Tools die sich an der Kodierung verschlucken :(

EDIT: aber auch das aktuelle Toad for Mac (und auch PC) wirft den selben Fehler. Sonderbar.
Ne, lokal will ich eigentlich kein PHPMyAdmin verwenden, wenn es nicht sein muss. Gerade dafür gibt es ja solche Tools wie Toad oder Workbench (ist auch aktuell).
Zumal es überhaupt nicht gesagt ist, dass PMA das dann kann.
Also auf Kommandozeile am PC ging es jetzt auch.
Muss ich im bugreport ergänzen.
Ich kann die DB dann aber auch mit dem MySQL Administrator sichern und dieses SQL-Skript kann ich dann aber sehr wohl ganz normal wieder einlesen. Das ist dann nicht verkorkst.
Das wird dann nämlich in Hex-Schreibsweise gesichert und nicht als irgendein UTF-X
Hier die tl_files:

Code:

---

INSERT INTO `tl_files` (`id`,`pid`,`tstamp`,`uuid`,`type`,`path`,`extension`,`hash`,`found`,`name`,`meta`,`importantPartX`,`importantPartY`,`importantPartWidth`,`importantPartHeight`) VALUES
 (78,0x870D3A9E9F7711E392F3BC305B35679A,1393482146,0x870D3A8A9F7711E392F3BC305B35679A,'file','files/downloads/.htaccess','htaccess','bff88aa9f255706dd1e53e330cb1a7b7','1','.htaccess',NULL,0,0,0,0),
 (77,NULL,1393482146,0x870D3A9E9F7711E392F3BC305B35679A,'folder','files/downloads','','5efa04a47b3827adfeb73204cd32a9d0','1','downloads',0x613A313A7B733A323A226465223B613A333A7B733A353A227469746C65223B733A303A22223B733A343A226C696E6B223B733A303A22223B733A373A2263617074696F6E223B733A303A22223B7D7D,0,0,0,0),
 (29,0x32380000000000000000000000000000,1386323030,0xE96E3AA25E5A11E39EABBC305B35679A,'file','files/contaodemo/contaodemo.css','css','3d646943a24a74a6d5a0d7a016105faa','1','contaodemo.css',NULL,0,0,0,0),
 (28,NULL,1386323030,0xE96E3AAC5E5A11E39EABBC305B35679A,'folder','files/contaodemo','','ad17a5a5d56333cc08ba15e422268379','1','contaodemo',NULL,0,0,0,0),
 (13,0xB8A1C9D6A48511E392F3BC305B35679A,1403685443,0xF3E4483A528611E38A28BC305B35679A,'file','files/isotopedemo/theme/img/isotope_placeholder_image.png','png','a9d84b0cd9f2e69fb76574844244e678','1','isotope_placeholder_image.png',NULL,0,0,0,0),
 (17,0xE56D022860D811E39EABBC305B35679A,1403685442,0x429C7BE855A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/css/font-awesome.css','css','1f9e9d1a5a1d347d945ef4b7727f2ea0','1','font-awesome.css',NULL,0,0,0,0),
 (18,0xE56D023C60D811E39EABBC305B35679A,1403685442,0x429C7BCA55A511E38A28BC305B35679A,'folder','files/font-awesome-4.0.3/fonts','','c20cb386598a810c0e523a1613d51522','1','fonts',NULL,0,0,0,0),
 (19,0x429C7BCA55A511E38A28BC305B35679A,1403685442,0x429C7BAC55A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/fonts/fontawesome-webfont.eot','eot','8b27bc96115c2d24350f0d09e6a9433f','1','fontawesome-webfont.eot',NULL,0,0,0,0),
 (20,0x429C7BCA55A511E38A28BC305B35679A,1403685442,0x429C7B8E55A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/fonts/fontawesome-webfont.svg','svg','0a799148a50bb02c6f380eabd8d97559','1','fontawesome-webfont.svg',NULL,0,0,0,0),
 (21,0x429C7BCA55A511E38A28BC305B35679A,1403685442,0x429C7B7055A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/fonts/fontawesome-webfont.ttf','ttf','dcb26c7239d850266941e80370e207c1','1','fontawesome-webfont.ttf',NULL,0,0,0,0),
 (22,0x429C7BCA55A511E38A28BC305B35679A,1403685442,0x429C7B5C55A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/fonts/fontawesome-webfont.woff','woff','3293616ec0c605c7c2db25829a0a509e','1','fontawesome-webfont.woff',NULL,0,0,0,0),
 (23,0x429C7BCA55A511E38A28BC305B35679A,1403685442,0x429C7B3E55A511E38A28BC305B35679A,'file','files/font-awesome-4.0.3/fonts/FontAwesome.otf','otf','3f3a623e88cb5c62eaa2367195e98b67','1','FontAwesome.otf',NULL,0,0,0,0),
 (30,0xE96E3AAC5E5A11E39EABBC305B35679A,1386323961,0x13FF25865E5D11E39EABBC305B35679A,'folder','files/contaodemo/theme','','e5b31711d1f29acbe675da02e9d1a425','1','theme',NULL,0,0,0,0),
 (31,0x33300000000000000000000000000000,1386323961,0x13FF25725E5D11E39EABBC305B35679A,'folder','files/contaodemo/theme/img','','93e9d2d1af501f78ea6d3bbb2c89900b','1','img',NULL,0,0,0,0),
 (32,0x33310000000000000000000000000000,1386323961,0x13FF255E5E5D11E39EABBC305B35679A,'file','files/contaodemo/theme/img/btn_search.gif','gif','a00ce18652c69678332d27bd0ef558c2','1','btn_search.gif',NULL,0,0,0,0),
 (36,NULL,1386597042,0xE56D023C60D811E39EABBC305B35679A,'folder','files/font-awesome-4.0.3','','addbac37ef9bc9c2d0dc69bfd78da3d5','1','font-awesome-4.0.3',NULL,0,0,0,0),
 (37,0x33360000000000000000000000000000,1386597043,0xE56D022860D811E39EABBC305B35679A,'folder','files/font-awesome-4.0.3/css','','8b24ec6b109695c0fba57186a3c7a7d3','1','css',NULL,0,0,0,0),
 (38,0x33370000000000000000000000000000,1386597043,0xE56D021E60D811E39EABBC305B35679A,'file','files/font-awesome-4.0.3/css/font-awesome.min.css','css','fa6868c22ceca7f65191ec25c68a9bb5','1','font-awesome.min.css',NULL,0,0,0,0),
 (39,NULL,1386624405,0x9A9B2122611811E39EABBC305B35679A,'folder','files/isotopedemo','','fe1b71f72700bb2d0019085cd4b13e07','1','isotopedemo',NULL,0,0,0,0),
 (40,0x9A9B2122611811E39EABBC305B35679A,1386624405,0x9A9B210E611811E39EABBC305B35679A,'file','files/isotopedemo/isotopedemo.css','css','20b61a17da2cfdd2df48e434f7bfaeb3','1','isotopedemo.css',NULL,0,0,0,0),
 (86,0xB8A1C9D6A48511E392F3BC305B35679A,1394037998,0xB8A1C9CCA48511E392F3BC305B35679A,'file','files/isotopedemo/theme/img/logo.png','png','0510102603154721b083abcdd6bf7b70','1','logo.png',NULL,0,0,0,0),
 (85,0xB8A1C9F4A48511E392F3BC305B35679A,1394037998,0xB8A1C9D6A48511E392F3BC305B35679A,'folder','files/isotopedemo/theme/img','','be2c5a3bfa76462ef85bc1ed55f0df3b','1','img',NULL,0,0,0,0),
 (83,0xE76BFBD89FC611E392F3BC305B35679A,1423817557,0x0A6765469FC711E392F3BC305B35679A,'file','files/downloads/contao/contao-3.2.19.zip','zip','1926cd3c153fbb2808843b11d3c05df0','1','contao-3.2.19.zip',0x613A313A7B733A323A226465223B613A333A7B733A353A227469746C65223B733A303A22223B733A343A226C696E6B223B733A303A22223B733A373A2263617074696F6E223B733A303A22223B7D7D,0,0,0,0),
 (84,0x9A9B2122611811E39EABBC305B35679A,1394037998,0xB8A1C9F4A48511E392F3BC305B35679A,'folder','files/isotopedemo/theme','','5ce700085140528500da625611e7bb45','1','theme',NULL,0,0,0,0),
 (137,0xE76BFBD89FC611E392F3BC305B35679A,1416921374,0x132C4D8CEA3011E3990ABC305B35679A,'file','files/downloads/contao/contao-3.3.7.zip','zip','1926cd3c153fbb2808843b11d3c05df0','1','contao-3.3.7.zip',0x613A313A7B733A323A226465223B613A333A7B733A353A227469746C65223B733A303A22223B733A343A226C696E6B223B733A303A22223B733A373A2263617074696F6E223B733A303A22223B7D7D,0,0,0,0),
 (80,0xE76BFBD89FC611E392F3BC305B35679A,1423817538,0x0A6765829FC711E392F3BC305B35679A,'file','files/downloads/contao/contao-3.4.4.zip','zip','6b9b27d9cedc6e9282c0623f593e3a31','1','contao-3.4.4.zip',0x613A313A7B733A323A226465223B613A333A7B733A353A227469746C65223B733A303A22223B733A343A226C696E6B223B733A303A22223B733A373A2263617074696F6E223B733A303A22223B7D7D,0,0,0,0),
 (79,0x870D3A9E9F7711E392F3BC305B35679A,1393516238,0xE76BFBD89FC611E392F3BC305B35679A,'folder','files/downloads/contao','','18f319a1ebd7aba550c47cea486f1ec0','1','contao',0x613A313A7B733A323A226465223B613A333A7B733A353A227469746C65223B733A303A22223B733A343A226C696E6B223B733A303A22223B733A373A2263617074696F6E223B733A303A22223B7D7D,0,0,0,0),
 (107,0xB8A1C9D6A48511E392F3BC305B35679A,1395330113,0x291CCFF0B04611E392F3BC305B35679A,'file','files/isotopedemo/theme/img/isotope_watermark_image.png','png','35014bf718952f35d2caa19497e839f8','1','isotope_watermark_image.png',NULL,0,0,0,0),
 (108,NULL,1395387908,0xB962E14AB0CC11E392F3BC305B35679A,'file','files/Isotope-eCommerce-Manual-DE.pdf','pdf','731b90d906db55af7a3070a37cec1443','1','Isotope-eCommerce-Manual-DE.pdf',NULL,0,0,0,0),
 (109,NULL,1395387908,0xB962E104B0CC11E392F3BC305B35679A,'file','files/Isotope-eCommerce-Manual-EN.pdf','pdf','f83ea594e0aabbdbaa8f1e24d0eb70d9','1','Isotope-eCommerce-Manual-EN.pdf',NULL,0,0,0,0),
 (191,NULL,1423817635,0xD74FD7E6B35D11E499AABC305B35679A,'folder','files/tiny_templates','','3cb25412587bbaedd9901598abd93284','1','tiny_templates',NULL,0,0,0,0),
 (192,0xD74FD7E6B35D11E499AABC305B35679A,1423817635,0xD74FD7B4B35D11E499AABC305B35679A,'file','files/tiny_templates/index.html','html','aeebec42dc0335ea1e0853f4393259b4','1','index.html',NULL,0,0,0,0),
 (138,0x13FF25725E5D11E39EABBC305B35679A,1403685442,0xED387B84FC4311E3990ABC305B35679A,'folder','files/contaodemo/theme/img/bg','','c8508efb4621934e6a223079e29ba85c','1','bg',NULL,0,0,0,0),
 (139,0xED387B84FC4311E3990ABC305B35679A,1403685442,0xED387B7AFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/bg/body.png','png','4896af3604f1842836af1babf5d89725','1','body.png',NULL,0,0,0,0),
 (140,0xED387B84FC4311E3990ABC305B35679A,1403685442,0xED387B66FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/bg/sitemap_first.png','png','648784faa178225f4d84f9ebbdc45e41','1','sitemap_first.png',NULL,0,0,0,0),
 (141,0xED387B84FC4311E3990ABC305B35679A,1403685442,0xED387B5CFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/bg/sitemap_last.png','png','41beb1ede8fca9789207fcde81365acb','1','sitemap_last.png',NULL,0,0,0,0),
 (142,0xED387B84FC4311E3990ABC305B35679A,1403685442,0xED387B52FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/bg/sitemap_normal.png','png','6919aa5f82a445da42dfca1444a46d6b','1','sitemap_normal.png',NULL,0,0,0,0),
 (143,0x13FF25725E5D11E39EABBC305B35679A,1403685442,0xED387B48FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/btn_rss.gif','gif','e633adc24026e9b093846deb09a7b33a','1','btn_rss.gif',NULL,0,0,0,0),
 (144,0x13FF25725E5D11E39EABBC305B35679A,1403685442,0xED387B3EFC4311E3990ABC305B35679A,'folder','files/contaodemo/theme/img/icons','','6228c486f2e8bbbf56b3a37313602723','1','icons',NULL,0,0,0,0),
 (145,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED387B2AFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-bottom.png','png','3eaec4cb41cf969b6f94d46ef4e53ab2','1','icon_arrow-bottom.png',NULL,0,0,0,0),
 (146,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED387B20FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-right-darkorange.png','png','1234e8a168b299fad503b255427ba2b9','1','icon_arrow-right-darkorange.png',NULL,0,0,0,0),
 (147,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED387ADAFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-right-grey.png','png','0bbc697fa88b983d35f37b763ec7f5d4','1','icon_arrow-right-grey.png',NULL,0,0,0,0),
 (148,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED437098FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-right-orange.png','png','a8b89aaf80f8f220f2eecc2b95879a50','1','icon_arrow-right-orange.png',NULL,0,0,0,0),
 (149,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED43708EFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-small.png','png','2433f5042b2565102b1ff3c32f69ddd1','1','icon_arrow-small.png',NULL,0,0,0,0),
 (150,0xED387B3EFC4311E3990ABC305B35679A,1403685442,0xED43707AFC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/icons/icon_arrow-top.png','png','15ac4e650587413df1cdc9cbe4f12b7e','1','icon_arrow-top.png',NULL,0,0,0,0),
 (151,0x13FF25725E5D11E39EABBC305B35679A,1403685442,0xED437070FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/logo.png','png','d46978d1df47864300ee2e2f02ce673e','1','logo.png',NULL,0,0,0,0),
 (152,0x13FF25725E5D11E39EABBC305B35679A,1403685442,0xED437066FC4311E3990ABC305B35679A,'file','files/contaodemo/theme/img/nav_mobile.png','png','7f546a33f7e468734a8276aaba27b42d','1','nav_mobile.png',NULL,0,0,0,0),
 (160,0xE56D023C60D811E39EABBC305B35679A,1403685442,0xED6C25F6FC4311E3990ABC305B35679A,'folder','files/font-awesome-4.0.3/less','','6eb02d5852046df8779c3789b10a8aa0','1','less',NULL,0,0,0,0),
 (161,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C25E2FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/bordered-pulled.less','less','5b3f3e1353ea7ab9d10fd7598fbd214b','1','bordered-pulled.less',NULL,0,0,0,0),
 (162,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C25CEFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/core.less','less','e0425dae16b4e10d439ef079bc75ea68','1','core.less',NULL,0,0,0,0),
 (163,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C25BAFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/fixed-width.less','less','5e07ec001f8d21bd279c12ee542813f7','1','fixed-width.less',NULL,0,0,0,0),
 (164,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C259CFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/font-awesome.less','less','4201fdd32cc7a7d2f6ed2706800faf75','1','font-awesome.less',NULL,0,0,0,0),
 (165,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C2588FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/icons.less','less','cee820602539e69d61c4dd782536e1a0','1','icons.less',NULL,0,0,0,0),
 (166,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C2574FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/larger.less','less','8cb65280c0f889daf72626c21a7c8628','1','larger.less',NULL,0,0,0,0),
 (167,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED6C24D4FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/list.less','less','291fbd1d05eb7eba6172f738837794b6','1','list.less',NULL,0,0,0,0),
 (168,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED8E9D7AFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/mixins.less','less','0193675166be1acb0da06df07c0aa14e','1','mixins.less',NULL,0,0,0,0),
 (169,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED8E9D66FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/path.less','less','baaf503b6821b49336f242445bcf26ca','1','path.less',NULL,0,0,0,0),
 (170,0xED6C25F6FC4311E3990ABC305B35679A,1403685442,0xED8E9D48FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/rotated-flipped.less','less','09a3b97189c3c320ac7a1649dd6bbad9','1','rotated-flipped.less',NULL,0,0,0,0),
 (171,0xED6C25F6FC4311E3990ABC305B35679A,1403685443,0xED8E9D34FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/spinning.less','less','c4142d6d9e832fa1f6683f19c9799c06','1','spinning.less',NULL,0,0,0,0),
 (172,0xED6C25F6FC4311E3990ABC305B35679A,1403685443,0xED8E9D20FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/stacked.less','less','518e2b2d263982d2caa1e6514b4b4eac','1','stacked.less',NULL,0,0,0,0),
 (173,0xED6C25F6FC4311E3990ABC305B35679A,1403685443,0xED8E9D0CFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/less/variables.less','less','82549d7e42c5d301b61c7a694d3a9dbd','1','variables.less',NULL,0,0,0,0),
 (174,0xE56D023C60D811E39EABBC305B35679A,1403685443,0xED8E9CF8FC4311E3990ABC305B35679A,'folder','files/font-awesome-4.0.3/scss','','83f91c4625cb3c1a27a3d0d7140e390b','1','scss',NULL,0,0,0,0),
 (175,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xED8E9CE4FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_bordered-pulled.scss','scss','e4f85472a1f6ed0e23a473b8e00ef071','1','_bordered-pulled.scss',NULL,0,0,0,0),
 (176,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xED8E9CC6FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_core.scss','scss','460139739224bc62d9957837978c4e22','1','_core.scss',NULL,0,0,0,0),
 (177,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xED8E9C26FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_fixed-width.scss','scss','9277ab6964a434d499873687b00be906','1','_fixed-width.scss',NULL,0,0,0,0),
 (178,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA931F8FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_icons.scss','scss','691e5398b8513cd310e847aae3112b27','1','_icons.scss',NULL,0,0,0,0),
 (179,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA931E4FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_larger.scss','scss','e95931566f6fc6ad5685c4fa9802e206','1','_larger.scss',NULL,0,0,0,0),
 (180,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA931D0FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_list.scss','scss','7107e80b053928271d5fcf422dc29490','1','_list.scss',NULL,0,0,0,0),
 (181,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA931BCFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_mixins.scss','scss','d6c8e2fb73d626a27dc0c816a584432a','1','_mixins.scss',NULL,0,0,0,0),
 (182,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA931A8FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_path.scss','scss','ac2a848f68cffed328272615bfca2500','1','_path.scss',NULL,0,0,0,0),
 (183,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA93194FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_rotated-flipped.scss','scss','9d894281a3b1c265abdd5abd11f9af5d','1','_rotated-flipped.scss',NULL,0,0,0,0),
 (184,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA93180FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_spinning.scss','scss','8e6c7988f40f123aedd96a668c56582a','1','_spinning.scss',NULL,0,0,0,0),
 (185,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA9316CFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_stacked.scss','scss','5594237226aedfbca2fa1c7f4604c214','1','_stacked.scss',NULL,0,0,0,0),
 (186,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA9314EFC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/_variables.scss','scss','9d4f23eacae6690aa140e51d42550e5b','1','_variables.scss',NULL,0,0,0,0),
 (187,0xED8E9CF8FC4311E3990ABC305B35679A,1403685443,0xEDA930C2FC4311E3990ABC305B35679A,'file','files/font-awesome-4.0.3/scss/font-awesome.scss','scss','4201fdd32cc7a7d2f6ed2706800faf75','1','font-awesome.scss',NULL,0,0,0,0);
/*!40000 ALTER TABLE `tl_files` ENABLE KEYS */;

---

Ja, wie gesagt, der SQL dump wurde "falsch" exportiert (eben ohne hexadecimal notation für binäre Felder). Das wird wahrscheinlich geändert.

Und jetzt geht es auch (ursprüngliches Problem):
Anhang 17673

Zitat:

---

Zitat von the_scrat

Das muss auch nirgends stehen, jede Datei hat von Haus aus eine Kodierung.

---

Bist du dir da sicher? Ich meine, dass viele Editoren Probleme haben die Codierung einer Datei zu erkennen. 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.

Keine Ahnung wie das die Editoren untereinander machen. Mag schon sein, dass ein notepad.exe etwas primitiver arbeitet als ein hochwertiger Editor wie Notepad++ oder PHPStorm etc. Letztendlich wird schon der Inhalt für die Formatbestimmung zuständig sein, wie jetzt auf Byteebene die Zeichen abgespeichert werden.

Jedenfalls zeigt mir Notepad++ das Format sauber an. Und auch in PHPStorm sehe ich sofort ob es z.B. UFT-8 oder windows-1252 oder ähnliches ist. Jedenfalls muss die kodierung nirgends explizit stehen, darum ging es in der Kernaussage eigentlich.

Das stimmt so nicht. Ein Editor kann das nicht erkennen, nur raten und das sollte er auch nur bedingt. Auch Notepad++ kann das nicht unbedingt, erkennen, welche Kodierung gemeint ist.
Das ist Sache des Benutzers, im richtigen Format abzuspeichern und das auch dann beim Öffnen einzustellen.
Außer dieser Krücke BOM oder etwa rare zuverlässige inhaltliche Hinweise wie etwa ein utf-8 Metatag gibt es keine Möglichkeit das zu erkennen.

Das BOM verwende ich tunlichst nicht. Ich will die Dateien beliebig öffnen können.
Ich speichere daher mittlerweile alles als UTF-8 ab (natürlich ohne BOM), das geht heutzutage überall.

Was hat denn BOM mit dem (beliebigen) Öffnen der Datei zu tun?

Gibt es eine BOM dann kann der Editor erkennen ob (und welches) UTF es ist.
EDIT: habe gerade mal getestet, in EditPad Pro den Text "äöü" als 1252 gespeichert und dann in Notepad++ geöffnet. Erkennt es nicht.

Ich weiß was BOM ist, ich war mir jetzt nur nicht grad sicher ob du das auch weißt, da es sich eher so anhörte, als wäre es in deinen Augen sowas wie eine Beschränkung zum Öffnen der Datei. Auch mit BOM kannst du die Datei beliebig oft öffnen. Das eine hat mit dem anderen ja überhaupt nichts zu tun.

Ich meine nicht beliebig oft, sondern auf beliebigen Systemen.
Ich hatte vorher, als ich Textdateien auf meinem PC noch als Win1252 kodiert hatte, mit dem Mac immer Probleme, wenn ich auf die selben Dateien zugriff (in Verbindung mit Subversion).
Mit UTF-8 natürlich kein Problem.

Zitat:

---

Zitat von the_scrat

Jedenfalls muss die kodierung nirgends explizit stehen, darum ging es in der Kernaussage eigentlich.

---

Ah, ok. Deine Aussage

Zitat:

---

Zitat von the_scrat

... jede Datei hat von Haus aus eine Kodierung.

---

hörte sich so an, als könnte man diese Kodierung herausfinden. Das hätte ich dann sofort dem Entwickler meines Editors mitgeteilt, aber andererseits würde er dass dann ja wahrscheinlich auch selber wissen, wie man die herausfinden kann.

Das war bezogen auf die Aussage von franc

Zitat:

---

Moment mal, wie soll Notepad++ denn wissen, wie die Datei kodiert ist? Das steht doch nirgends.

---

Die Kodierung "steht" ja auch nirgends. Jeder Editor wird eine Standardkodierung haben die man halt ändern kann. Dann werden die Zeichen (denk ich mal) in der jeweiligen Kodierung gespeichert.

Ich hab jetzt grad mal den Test gemacht.
notepad geöffnet und den String "äöüß test" reingeschrieben.
Dann abgespeichert in
- ANSI
- UFT8
- UNICODE

öffne ich jetzt z.B. die ANSI Datei in PHPStorm, der ANSI nicht öffnen kann, erhalte ich

Code:

---

���� test

---

öffne ich die UFT8/UNICODE Datei erhalte ich

Code:

---

äöüß test

---

Sehe ich mir die verschiedenen .txt Dateien mal im hexeditior an sieht man auch wie die unterschiedlichen Editoren rausfinden um welche kodierung es sich handelt.

Code:

---

ANSI
E4 F6 FC DF 20 74 65 73 74
äöüß test

UTF8 (mit BOM von notepad.exe)
EF BB BF C3 A4 C3 B6 C3 BC C3 9F 20 74 65 73 74
äöüß test

UNICODE
FF FE E4 00 F6 00 FC 00 DF 00 20 00 74 00 65 00 73 00 74 00
ÿþä.ö.ü.ß. .t.e.s.t.

---

Also ist es kein wirkliches "raten" eines Editors wie franc meint, sondern jeder Editor sollte anhand des Speicherformats erkennen welche Kodierung passt (sofern er sie überhaupt unterstützt).

Ich kenne mich leider mit HEX nicht aus. Heißt das, dass man anhand der Zeichenfolge

Code:

---

E4 F6 FC DF 20 74 65 73 74

---

bei ANSI erkennen könnte, dass es ANSI ist? Das müsste dann ja einfach sein für einen Editor die Kodierung herauszubekommen, oder?

Naja, ich vermute mal. Ich hab hier lediglich den Vergleich geführt und zumindest kann man anhand der HEX Werte einen deutlichen Unterschied feststellen.
Daher denke ich (reine Vermutung), dass die Editoren sehr wohl in der Lage sind rauszufinden welches Format die Datei hat. franc hatte das ja oben eher als "raten" beschrieben. Aber es gibt ja anscheinend klare Unterschiede im HEX Bereich den ja jeder Editor auch lesen und verarbeiten kann.

franc hat schon Recht, man kann die Enkodierung einer Datei, ohne weitere Angabe eines headers, letztendlich nur anhand des Inhalts erraten. Bei

Code:

---

E4 F6 FC DF 20 74 65 73 74

---

kann man davon ausgehen, dass es nicht einfach ASCII/ANSI ist, weil

Code:

---

E4 F6 FC DF

---

keinem Zeichen im ANSI Zeichensatz entspricht, und daher einem anderen, erweiterten Zeichensatz gehören muss - wie zB UTF-8. Wie man erkennt, ob ein String in UTF-8 enkodiert ist oder nicht, sieht man zB hier anhand eines Beispiels in plain C.

Vielleicht interpretiere ich das Wort "raten" einfach nur falsch. Aber "raten" hat ja mehr etwas mit Zufall zu tun, als mit einem anständigen Ausschlussverfahren bzw. einem Abgleich von diversen Vorgaben von Längen/Bytes oder erweiterten Zeichensätzen, oder?

Ich würde kein BOM verwenden (s.o.).
Auch wenn dann einige Editoren UTF-x damit sicher erkennen. Dann lädt man so eine Datei (versehentlich) auf ein System, das das nicht kennt oder mag und ZACK! gibt es komische Fehler die u.U. schwer zu orten sind. Nene, lieber nicht BOM nehmen.

Ich würde auch keine Textdatei, die ich anderswo noch brauche, mit Windows Notepad speichern, wo es sogar immer noch die verwirrende Vermischung von UTF-8 und Unicode (meint ja eigentlich UTF-16) gibt. Microsoft Suppe mal wieder.

Ohne BOM können einige Editoren probieren (ich nenne es raten), was für eine Kodierung die Datei wohl hat, aber sicher sagen können sie es nicht. Daran führt nichts vorbei. Weil man nämlich die (z.B.) äöüß usw Zeichen, die anders interpretiert irgendwelchen scheinbaren Mumpitz ergeben können, vielleicht ja doch anders gemeint hat, also als irgendwelche Sonderzeichen. Der Editor, der diese Entscheidung für einen abnimmt, welches Zeichen der Benutzer konkret wohl gemeint hätte, ginge eindeutig zu eigenmächtig vor. Damit wären deftige Fehler programmiert.

Daher überlasse ich es nicht meinem Editor, was für eine Kodierung er wohl erkennen mag und bestimme selbst, pro Dateityp (wie the_scrat schon angedeutet hat) wie er die de/kodiert.

Zitat:

---

Zitat von the_scrat

Vielleicht interpretiere ich das Wort "raten" einfach nur falsch. Aber "raten" hat ja mehr etwas mit Zufall zu tun, als mit einem anständigen Ausschlussverfahren bzw. einem Abgleich von diversen Vorgaben von Längen/Bytes oder erweiterten Zeichensätzen.

---

"Raten" deshalb, weil in einer Datei auch Zeichen vorkommen könnten, die eine andere Kodierung haben. In so einem Fall muss man jedes Zeichen einzeln behandeln.

Hmmm, irgendwie hab ich es noch nicht wirklich....
Nehmen wir doch nochmal das obige Beispiel (in vollem Umfang)

Code:

---

ANSI
E4 F6 FC DF 20 74 65 73 74
äöüß test

UTF8 (mit BOM von notepad.exe)
EF BB BF C3 A4 C3 B6 C3 BC C3 9F 20 74 65 73 74
äöüß test

UNICODE
FF FE E4 00 F6 00 FC 00 DF 00 20 00 74 00 65 00 73 00 74 00
ÿþä.ö.ü.ß. .t.e.s.t.

---

Hier sollte es keinen Handlungsspielraum geben, richtig? Die erweiterten Zeichen "äöüß" kann ich unterschieden:
ä = (hex) E4 = [ANSI]
ä = (hex) C3 A4 = [UTF-8]
ä = (hex) E4 00 = [UNICODE]

Generell kann ich doch UNICODE schonmal anhand von den 00 (Punkten) erkennen. Also muss ich doch lediglich 2 Hex Werte prüfen um doch relativ genau beurteilen zu können welches Format vorliegt, ohne einen Header bzw. BOM vorliegen zu haben.

Selbst wenn ich die Umlaute (erweiterte Sonderzeichen) jetzt rausstreiche und auch sogar den BOM entferne, kann ich UNICODE noch immer rausfinden (wegen den folgenden 00 Werten).
Nur die Unterscheidung von ANSI und UTF-8 ist dann nicht mehr möglich, hier gibt es ja dann den default, evtl. UTF-8. Aber wenn eh keine Sonderzeichen enthalten sind, sollte das ja eh egal sein?

Zitat:

---

Zitat von franc

Ich würde kein BOM verwenden (s.o.).

---

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 ;)

m.E. "gucken" die Editoren auf die "magic bytes" - https://en.wikipedia.org/wiki/Magic_...programming%29

Hier gehts aber um reine "Textdateien" und keine Dateiformate wie jpg,exe,zip etc.

Zitat:

---

Zitat von the_scrat

Hmmm, irgendwie hab ich es noch nicht wirklich....
Nehmen wir doch nochmal das obige Beispiel (in vollem Umfang)

Code:

---

ANSI
E4 F6 FC DF 20 74 65 73 74
äöüß test

UTF8 (mit BOM von notepad.exe)
EF BB BF C3 A4 C3 B6 C3 BC C3 9F 20 74 65 73 74
äöüß test

UNICODE
FF FE E4 00 F6 00 FC 00 DF 00 20 00 74 00 65 00 73 00 74 00
ÿþä.ö.ü.ß. .t.e.s.t.

---

Hier sollte es keinen Handlungsspielraum geben, richtig? Die erweiterten Zeichen "äöüß" kann ich unterschieden:
ä = (hex) E4 = [ANSI]
ä = (hex) C3 A4 = [UTF-8]
ä = (hex) E4 00 = [UNICODE]

Generell kann ich doch UNICODE schonmal anhand von den 00 (Punkten) erkennen. Also muss ich doch lediglich 2 Hex Werte prüfen um doch relativ genau beurteilen zu können welches Format vorliegt, ohne einen Header bzw. BOM vorliegen zu haben.

Selbst wenn ich die Umlaute (erweiterte Sonderzeichen) jetzt rausstreiche und auch sogar den BOM entferne, kann ich UNICODE noch immer rausfinden (wegen den folgenden 00 Werten).
Nur die Unterscheidung von ANSI und UTF-8 ist dann nicht mehr möglich, hier gibt es ja dann den default, evtl. UTF-8. Aber wenn eh keine Sonderzeichen enthalten sind, sollte das ja eh egal sein?

---

Und wie sieht's zB mit

Code:

---

E4 00 C3 A4 E4

---

aus? ;)

Das müsste dann ganz normales ANSI sein!
Warum?

E4 = ä

E4 00 = ä. (also evtl UNICODE) da die weiteren Zeichen jedoch kein 00 enthalten kann ich UNICODE ausschließen

und in UTF8 ist ein ä = C3 A4

edit: vielleicht auch die weiteren Hex-Werte ankucken ;-)

Ist es aber eben nicht. Es ist der String

Code:

---

äää

---

Wenn du den aber nur als ANSI interpretierst, kommt

Code:

---

ä ää

---

dabei raus.

Ja, hab ich grad selbst bemerkt. Aber wird sowas in der Praxis überhaupt vorkommen? Eine Mischung von Kodierungen wird ein Editor garnicht zulassen. Entweder ist alles

C3 A4
oder
E4 00
oder
E4

Zitat:

---

Zitat von the_scrat

Aber wird sowas in der Praxis überhaupt vorkommen?

---

Definitiv. Heutzutage wohl weniger, aber früher war das ein übliches Ärgernis, vor allem in der Web Branche. Wenn du in so eine Situation kommst, gibt es für PHP zB das praktische Encoding::toUTF8() - diese Funktion konvertiert alle Zeichen eines Strings zu UTF-8, egal wie die jeweiligen Zeichen enkodiert sind, sofern möglich. Die Library bringt auch eine Funktion zum reparieren von kaputten UTF-8 strings mit.

Vermischt du hier jetzt nicht ein paar Sachen? Es ging um Editoren nicht um Webseites. Auf ner Webseite kann ich natürlich durch bestimmte Funktionen alle möglichen Strings konvertieren, da kann ich auf einer Seite sogar mehrere Kodierungen gleichzeitig "darstellen" auch wenn es vom Browser her eine Standardkodierung gibt. Ich weiß schon auf was du hinaus möchtest. z.B. läuft die Seite auf utf8 aber die inhalte einer DB sind in einem anderen Format gespeichert, das gibt dann Quatsch. Aber das war hier ja garnicht das Thema, sondern Dateien, richtigen Dateien wie die abgespeichert sind.

Zitat:

---

Zitat von the_scrat

Vermischt du hier jetzt nicht ein paar Sachen? Es ging um Editoren nicht um Webseites.

---

Nein, ich vermische hier nichts. Die Datei, die du mit dem Editor öffnen willst, kann ja von irgendwo aus irgendeinem System kommen oder durch irgendwen mit irgendeinem Programm in irgendeinem Encoding bearbeitet worden sein. Bspw. kommt es aus einem System, wo bspw. durch schlampige Programmierung Strings mit verschiedenen Encodings ausgespuckt werden.

Die Grundaussage ist, dass man sich prinzipiell nicht darauf verlassen kann, dass zB die Strings einer Datei nur in genau einer Enkodierung vorhanden sind und man die Enkodierung aus dem Inhalt erraten muss. Wenn zB in einer Text Datei manche Umlaute in UTF-8 andere aber in LATIN1 abgespeichert sind und der Editor identifiziert die Datei als UTF-8, dann werden die Umlaute, die in der anderen Enkodierung vorliegen, falsch dargestellt.

Das mag sein, dass es sowas gibt, jedoch endet auch die schlampigste Speicherung irgendwann mal in einem konformen Format. Spätestens wenn ich so eine MischMasch-Datei (so nenn ich das jetzt mal) in einem anständigen Editor öffne und dann irgendwelche Zeichen wie � oder ä finde, dann muss es halt mal sauber konvertiert werden.

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

Zitat:

---

Zitat von Andreas

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?

Zitat:

---

Zitat von Spooky

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) ;-)

Zitat:

---

Zitat von the_scrat

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.

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 ;-)

Zitat:

---

Zitat von 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.

---

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.

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)

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.

Zitat:

---

Zitat von the_scrat

...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.

Zitat:

---

Zitat von franc

...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.

Zitat:

---

Zitat von the_scrat

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.

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?

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()).

Zitat:

---

Zitat von the_scrat

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.

Zitat:

---

Zitat von franc

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.

Zitat:

---

Zitat von Andreas

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.

[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.]

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.