[Allegro] problem mit #8e: der Unterstrich _ in web/intranet-adressen wird in der cat.api durch %5F ersetzt

[Thomas Berger]

Am 22.09.2011 17:49, schrieb lehmann_klaus at t-online.de:

> 	mein problem: 
> 	ich hatte in #8e sowas wie: 
> 	file:////test-rechner/test-freigabe/dokumentation_und_information.pdf
> 
> 	eingetragen. 
> 
> 	es klappte nicht. 

was ist "es"?

> 	beim eintragen schon(?) oder auf alle fälle beim abspeichern wurde
> daraus: 
> 
> 	file:////test/test-freigabe/dokumentation5F%und5F%information.pdf 

wohl eher

> 	file:////test/test-freigabe/dokumentation%5Fund%5Finformation.pdf


> 	erstens sieht es grottenhässlich aus ;-) 

ersetzt die d-wrtf.apr das nicht zurueck zu "_"?


> 	und zweitens funktionierte der link nicht wie gewünscht. 
> 
> 	erst als ich nach einigem suchen, den "verursacher" in der cat.pi
> fand, und ihn deaktiviert, klappte alles wie gewohnt. 
> 
> 	also: wessen problem? allegro's? (m)ein verständnisproblem? 


Die eine Sache ist, dass es es auch Dateinamen wie "abt_p1.pdf"
gibt, und in solchen Faellen hat der V14-Mechanismus nachweislich
schon zugeschlagen. In allegro-Anwendungen, wo "_" ein Steuerzeichen
(v14, Entstoppung, ggfls. auch Nichtsortierzeichen) ist, dann sollte es
in Pfaden als Inhalt von #8e unschaedlich gemacht werden, d.h. es
darf da nicht drin stehen. Fuer URIs bietet sich "%5F" an, weil
das eine offizielle Ersatzdarstellung ist (zumindest der meisten
Bestandteile davon): Die Umsetzung "_" nach "%5F" ist nicht sauber
im Sinne von Transparent, denn ein ggfls. vorher vorhandenes "%5F"
wird bei der Rueckumwandlung ebenfalls zu "_", das Ergebnis ist in
dem Fall also nicht identisch. Aber immerhin aequivalent, und das
reicht (normalerweise ;-).


Die andere Sache ist die Unterstuetzung von Browsern fuer file:-URLs.
Ich habe gerade nur einmal Firefox und InternetExplorer getestet:

Klassische Pfade mit Laufwerksbuchstaben koennen beide anstandslos
sowohl als
file:///C|/allegro/flex/_new.flx
als auch escaped als
file:///C|/allegro/flex/%5Fnew.flx

Bei UNC-Namen in der file-URL sieht es anders aus, das kann FF gar
nicht und IE nur in der Form mit "_".


(Die Tests waren durch Eingabe in der Adresszeile des Browsers, wie
das in eventuellen href-Attributen von HTML-Elementen in im jeweiligen
Browser gezeigter Dokumente aussehen kann, waere gesondert zu untersuchen)

Fazit also: Nicht nur fuer die Anzeige sondern auch fuer die Generierung
des Aufrufs das %5F in "_" zurueck uebersetzen. Das gibt dann allerdings
Aerger, wenn die Datei auf der Platte wirklich
dokumentation%5Fund%5Finformation.pdf heisst.

Fuer den allgemeinen Fall ist das natuerlich keine Hilfe: Speziell das
Spatium muss ja in der URI nun wirklich als "%20" erfasst werden, und
wenn das mit UNC-Pfaden kombiniert wird, wird es eng...

Und es gibt auch andere moegliche Inkompatiblitaeten, ueber die
\\?\-Notationen kann man etwa bis zu 32k lange NTFS oder Netzwerkpfade
verarbeiten, das duerfte im Extremfall auch nicht funktionieren, weil
Browser vermutlich nur URIs beruecksichtigen, die kurz genug sind, um
ueber HTTP transportiert werden zu koennen.

Wie waere es eigentlich mit einem Webserver im lokalen Netz?

viele Gruesse
Thomas Berger