GeoGet - offline export
#1
Publikováno 05 August 2009 - 13:29
Původně jsem si myslel že to je chyba toho integrovaného prohlížeče v E51, ale pak ve mě zase začalo hlodat podezření ("když zvládne i CSS a JavaScript, tak proč by ho rozhodilo triviální HTML"), a zjístil jsem že je to chybnými odkazy které GeoGet generuje.
Zatímco v index.htm a prvních seznamech jsou odkazy správně ("href=offline/xyz.htm"), tak v jiných souborech jsou v odkazech zpětná lomítka místo normálních. Tzn. odkaz na normální cache pak vypadá jako "..\cache\H\GCKNFH.htm", místo "../cache/H/GCKNFH.htm".
Bylo by prosím možné opravit GeoGet aby generovat korektní HTML? Díky moc.
Původně jsem si myslel že to opravím sám, ale zmíněná chyba je zřejmě přímo v geoget.exe, tzn. není to záležitost pluginů.
#2
Publikováno 05 August 2009 - 13:51
#3
Publikováno 05 August 2009 - 14:02
#4
Publikováno 05 August 2009 - 14:24
Aj! Pozor na to, to je klasický omyl :)HaLuMa napsal/a:
Davam tam zpetna lomitka, protoze v pocitaci i ve windows mobile PDA se jedna o normalni lokalni souborovou cestu ve filesystemu, ktery zpetna lomitka pouziva.
Tedy musim nejdriv vyzkouset, jestli na vsech potrebnych platformach to snese i normalni lomitka...
Pokud jde o HTML, tak tam jsou platná jen a pouze normální lomítka. A je jedno jestli si ten HTML dokument prohlíží někdo ve Win, v DOSu, na mobilu, atd. Prostě, pokud si ten dokument prohlížím pomocí nějakého HTML prohlížeče (tzn. programem navrženým k prohlížení HTML stránek, ne jen textovým editorem), tak ten prohlížeč musí chápat všechny hrefy jako URL, a nemůže se rozhodovat podle nálady jestli tady povolí zpětné lomítko a tady ne. Jinak by to moc fungovat nemohlo :).
Tzn ... browser narazí na href, vezme z něj tu relativní část (../.. nebo chybně ..\..), aplikuje ji na aktuální URL (pozor, skutečně na URL, ne na cestu v rámci filesystému, tzn. u souboru prohlíženého z disku by to mělo být něco jako file:///c:/a/b/c/...), a vyrobí z toho nové URL. A až do téhle chvíle to zpracování vůbec nesouvisí s tím kde se ten nový dokument nachází (jestli na lokálním disku, na webserveru, nebo čert ví kde). Teprve když má to nové URL zkonstruované, tak se podívá co je to zač (http://, file://, atd.), pokud je to file:// URL tak si z něj vyextrahuje cestu k dokumentu v takové formě aby byla použitelná pro OS (tzn. z file:///c:/b/c si ve Windows vyrobí "C:\b\c") a načte ten dokument. Ale zpracování odkazů se řídí jen a pouze pravidly pro HTML dokumenty a pro URL, a hostitelský OS v tom nehraje žádnou roli.
Dokonce i prehistorický MSIE 3.0 bez problémů zvládal běžná lomítka při prohlížení lokálních souborů.
Věř mi, náhradou "\" za "/" se nepokazí nic, a může to všem jen pomoct :).
A vzhledem k tomu, že index.htm a spol. obsahovaly správná (obyčejná) lomítka, dá se logicky odvodit že kdyby čistě náhodou opravdu existoval tak zprasený browser pro Windows, který by uměl je backslashe, tak by vůbec neměl být schopný ten index.html správně načíst, a určitě už bys měl spoustu bugreportů od uživatelů Win*, že jim ten offline export nefunguje.
To, že se pro lokální dokumenty musí používat "\", je historický omyl který se táhne snad z roku 2000, a nebyl pravdivý ani tehdy :)
#5
Publikováno 05 August 2009 - 15:05
#7
Publikováno 05 August 2009 - 15:54
No jo, blbě se vyjadřuju. Samo že jde o formát URL. Chtěl jsem to napsat nějak jednoduše a vznikl z toho chaos. Prostě to beru tak, že program který zpracovává odkazy v HTML (což je každý který se to HTML snaží korektně zobrazit) musí podporovat URL podle standardu.HaLuMa napsal/a:
A ja si myslel, ze jde o format URL, ktery sam o sobe neni nijak vazany na HTML, protoze se tahne napric vsemi moznymi protokoly. Takze o spatne zapsanem URL prohlasit, ze jde o sprasene HTML, to mi nejak nestimuje.
Mě teď vůbec nic nenapadá .. můžeš naznačit?Samozrejme, ze to umi kazdy prohlizec ukazat, to je jasne a bez diskuzi, ale problematika saha daleko za nejaky webovy prohlizec! Coz je vec, ktera mnoha lidem casto nedojde.
Odhadoval bych, že poněvadž na PDAčkách s Windows Mobile je ten interní browser dílem Microsoftu, tak si ty backslashe automaticky nahradí normálním lomítkem a ani necekne. A běžné browsery na počítačích jsou tak rozšířené, že kdyby měly stránky s chybnými URL zobrazovat chybně, tak by se na ně snesla (neoprávněná) kritika od uživatelů, že "v MSIE mi ten web jede, tak proč ve Firefoxu ne"?Na druhou stranu, je zajimave, ze zpetna lomitka zjevne spravne interpretuje kdeco na kdejakych platformach az na tu tvoji Nokii.
No a takové ty méně rozšířené aplikace jsou nejspíš rády že zvládají všechno podle normy, a už se nezatěžují implementací různých obezliček které mají zaručit kompatibilitu s produktem X firmy Y .
Jinak, stejně jako ten interni browser na Nokii (tzn. čistě podle normy, bez automatického nahrazování zpětných lomítek těmi správnými) se chová třeba i textový prohližeč "lynx" nebo český "links" na Linuxu, tzn. není to zase taková výjimka.
Každopádně díky za opravu.
#8
Publikováno 05 August 2009 - 18:47
[quote]HaLuMa napsal/a:
Samozrejme, ze to umi kazdy prohlizec ukazat, to je jasne a bez diskuzi, ale problematika saha daleko za nejaky webovy prohlizec! Coz je vec, ktera mnoha lidem casto nedojde.
[/quote]
Mě teď vůbec nic nenapadá .. můžeš naznačit?
[quote]
Dobra, naznacim. Zpracovani listingu je spolecne jak pro offline export, tak i pro interni ukazovani. A interni zobrazovac listingu neni browser, neni to zadne nalinkovane IE nebo Firefox. (Dalsi duvod, proc GG beha tak ochotne pod Wine...) V listingu se masivne manipuluje treba s obrazky, premapovavaji se ruzne odkazy, vyrabi se tam takova specielni cache na nalinovane obrazky, atd.
Vim, problem je v indexovych souborech, kterych se toto zrovna moc netyka. Rikam to ale proto, aby bylo jasne, ze za nekterymi samozrejme vypadajicimi vecmi se obcas skryva mala věda. Myslim, ze treba mnoha lidem ani nedojde, ze treba ten listing v GG vlastne neprohlizi vubec v prohlizeci.
1 uživatel(ů) prochází toto téma
0 uživatelů, 1 návštěvníků 0 anonymních uživatelů