Hi,
ein paar Wochen dachte ich, Leopards Spotlight sei perfekt. Gestern
stelle ich dann zuf
georg.dripmann@googlemail.com schrieb in
> Wonach könnte man schauen?
Den sog. UTIs [1] der Dateien und was Spotlight halt mit denen anfangen
will. Nachschauen kann man in Terminal.app bspw., indem man
mdimport -d2 /pfad/zur/datei
drauf losläßt [2].
> Ist das das Spotlight-Desaster unter Leopard??
Genau. Das Spotlight-Desaster, das auf drohenden Weltuntergang
hinweist... oder so...
Gruss,
Thomas
[1] <http://www.apfelwiki.de/Main/UniformTypeIdentifiers>
[2] <http://www.apfelwiki.de/Main/Spotlight#toc10>
On Mar 8, 3:11 pm, Thomas Kaiser wrote:
> > Wonach k
georg.dripmann@googlemail.com schrieb in
> Während nämlich bei den erfolgreich indizierten Files etwas
erkennbar
> Sinnvolles in kMDItemTextContent steht, steht bei einem File, das
> Spotlight nicht indizieren kann, z. B. folgendes:
>
> kMDItemTextContent = "\n\n\n\n\n\n \n \n\n [...]"
>
> "[...]" meint: es kommt noch eine Wüste voller
"\n" usw. Nochmals, das
> File ist einfach eine in Camino gesicherte Webseite, die völlig
normal
> im Browser, oder Editoren dargestellt wird.
Hmm... da könnte man nun noch bei der mdimport-Ausgabe nachgucken,
welcher MDImporter überhaupt jeweils als zuständig erachtet wird
(steht
in der ersten Zeile der Ausgabe), ob der evtl. crasht (dritte Zeile) und
falls da verschiedene MDImporter zum Zuge kommen sollten, dann welches
Suffix/FileType die betroffenen Dateien haben (kann man wiederum mittels
mdls(1) nachschauen)
Gruss,
Thomas
wrote:
> "[...]" meint: es kommt noch eine Wüste voller
"\n" usw. Nochmals, das
> File ist einfach eine in Camino gesicherte Webseite, die völlig
normal
> im Browser, oder Editoren dargestellt wird.
Eventuell guckt sich der Importer nur die ersten 256 Zeichen einer Datei
an, um zu entscheiden ob er sich dafür zuständig fühlt. Und wenn
dort
dummwerweise nur Leerzeichen und Zeilenumbrüche stehen ("\n"
wird in
vielen Programmiersprachen als Zeichenfolge genutzt, die einen
Zeilenumbruch beschreibt), sieht der Importer nichts was auf HTML
hindeutet und fühlt sich nicht zuständig.
Und HTML-Dateien mit hunderten von Leerzeilen anfangen zu lassen, machen
viele Möchtegern-"Web-Designer" als "Kopierschutz",
weil sie glauben,
viele DAUs die sich den Code ansehen würden den Code so nicht finden,
weil die nicht auf die Idee kommen zu scrollen. Allerdings finden dann
auch viele Programme den Code nicht, wenn sie sich nur die ersten X
Zeichen zur Identifikation des Formats anschauen...
--
Alexander
Alexander Clauss schrieb in
> Eventuell guckt sich der Importer nur die ersten 256 Zeichen einer
> Datei an, um zu entscheiden ob er sich dafür zuständig
fühlt.
Hmm... also meines Wissens nach hat ein MDImporter gar nicht selbst zu
entscheiden, ob er "zuständig" ist/"fühlt" -- das
wird an anderer Stelle
anhand UTI entschieden und dann an den "zuständigsten"
MDImporter
delegiert.
Und wenn der MDImporter auf halber Strecke schlapp macht anstatt das
Dateiformat korrekt zu parsen, dann würde ich ihn als kaputt einstufen.
Gruss,
Thomas
Thomas Kaiser wrote:
> Hmm... also meines Wissens nach hat ein MDImporter gar nicht selbst zu
> entscheiden, ob er "zuständig" ist/"fühlt"
-- das wird an anderer Stelle
> anhand UTI entschieden und dann an den "zuständigsten"
MDImporter
> delegiert.
Wer und wie genau da irgendwelche Entscheidungen gefällt werden,
weiß
ich nicht genau. Aber das Problem ist nicht neu und die zitierte
Ausgabe
kMDItemTextContent = "\n\n\n\n\n\n \n \n\n [...]"
deutet zumindest darauf hin, daß das HTML-Document mit vielen
Leerzeilen und Leerzeichen anfängt. Und da für die Erkennung von
Dateiformaten praktischerweise nicht unbedingt immer den kompletten
Dateiinhalt inspiziert werden sollte (aus Performace-Gründen), ist die
Vermutung naheliegend, daß hier ggfs. in den inspiziertem Inhalt nicht
genügend eindeutiger "HTML"-Code zu finden war und die Datei als
HTML zu
identifizieren.
--
Alexander
Alexander Clauss schrieb in
> Thomas Kaiser wrote:
>
>> Hmm... also meines Wissens nach hat ein MDImporter gar nicht selbst
>> zu entscheiden, ob er "zuständig"
ist/"fühlt" -- das wird an anderer
>> Stelle anhand UTI entschieden und dann an den
"zuständigsten"
>> MDImporter delegiert.
>
> Wer und wie genau da irgendwelche Entscheidungen gefällt werden,
weiß
> ich nicht genau.
Aber genau das ist für mich der springende Punkt, denn ich kenne das
von Spotlight bisher nur so, daß einzig und alleine Datei-externe Datei-
Metadaten (FileType/Suffix) dafür sorgen, welcher MDImporter mit der
Datei beglückt wird, daß es dann aber von dessen
"Intelligenz" abhängt,
was an Datei-internen Metadaten und echtem Inhalt ausgelesen wird.
Sollte sich da mit 10.5 was geändert haben, wäre mir das neu und IMO
eine echte Sensation (denn -- ggf. auch nur ergänzend -- in die Datei
reinzugucken, um den richtigen MDImporter auszuwählen, fände ich gar
nicht so blöde). Insofern interessiert mich eigentlich nur so richtig,
ob sich da was Grundsätzliches mit 10.5 geändert haben könnte.
Zum
Problem des OP kann man ja eigentlich nur was sagen, wenn er Details
(mdls- und mdimport-Ausgabe, eine gezippte HTML-Datei irgendwo zum
Download) nachliefert.
Gruss,
Thomas