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

Klaus Lehmann lehmann_klaus at t-online.de
Di Sep 27 14:12:30 CEST 2011


Guten Tag, Thomas Berger,
am Donnerstag, 22. September 2011 um 18:36 schrieben Sie:





> 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"?
das "draufklicken" ;-)




>>       beim eintragen schon(?) oder auf alle fälle beim abspeichern wurde
>> daraus: 
> wohl eher
>>       file:////test/test-freigabe/dokumentation%5Fund%5Finformation.pdf
danke für den hinweis.

>>       erstens sieht es grottenhässlich aus ;-) 
> ersetzt die d-wrtf.apr das nicht zurueck zu "_"?
nein, die d-wrtf.apr macht das nicht. dazu habe ich unten später einen
vorschlag.



>>       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 ;-).
ja, das ist einzusehen ("rückumwandlung" etc).
d.h.: wir können es uns nicht leisten, ein "_" im datensatz sehen,
welches nicht diese v14-funktion hat. habe eingesehen!

ok. nächstes problem: ich habe hunderte/tausende(?) von dateien, mit
langer pfadangabe, die haben ein oder mehrere " " drin.
(spatium/spatien). ich habe schon darüber nachgedacht, diese
maschinell umzuschreiben (unter linux gibts ein paar perl-skripte,
die wohl auch für win32 gelten dürften [nicht ausprobiert].) aber
damit verändere ich die standorte (=directories) und filenamen. nicht
gut. will ich nicht.
also: wird das leerzeichen ein problem.
ich denke, mit den nachfolgenden codes ist es zum glück gelöst:


wo müsste man was drehen?
=========================
1. cat.api.
man suche nach:
#upV +U i5,8 i6,e e0            #8e : _ ersetzen!
gehe zu #-U
dort heisst es jetzt:
#upV ,",_,%5F," ,"_ _%20_" M
#t{ "-" }
#+#
damit wird bei der eingabe von _ und LEER ein %5F bwz %20 eingetragen.
damit vermeide ich, das das originaldokument verändert wird.

2. gleichzeitig in der d-wrtf.apr sollte das eingetragen werden:
#(8
#t{ C }
  Kommt kein Punkt vor, aber vorn ein Laufwerksbuchstabe?
#cc +#8eZ i5,: c"^." e0   dann ist es ein Datenbanksatz
  sonst ist es ein Dateiname oder eine URL
      #cc e"▼" ,"_\_/_" p'x var "' P'"\ins #ucc\exec winstart.flx' =Z~
#cc e"▼" ,"_\_/_" ,",%5F,_," ,"_%20_ _" p'x var "' P'"\ins #ucc\exec winstart.flx' =Z~
usw usw.


zusammemfassend:
================
1. macht die eingabe von _ bzw einem LEER zu soetwas: %5F bzw %20.
ok, das ist brauchbar und sinnvoll, denke ich.
2. macht das aussehen (ich erwähne "grottenhässlich")[ich finde, es
ist dem normalBenutzer NICHT zu zumuten, oder?] wieder rückgängig. wir
sehen unseren gewohnte Unterstrich und das Leerzeichen.

so meine theorie.
punkt 2 klappt in der praxis nämlich nicht! ehe ich nach den gründen
dafür suche, lieber nachgefragt: ist dieser weg überhaupt gangbar?????
wenn er gangbar ist, warum -ächm- klappt es nicht?
wer meinen(?) weg (mit)gehen will, dem wird das nächste problem vor
die augen kommen: die umlaute! äöü werden nicht sauber umgesetzt (was
ist "sauber"?)


wer geht mit?


viele grüße
ihr klaus lehmann






> 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 "_".
himmel! stöhn!
das ist alles sehr problematisch. (mein) ziel ist ja: webserver und
(intranet)fileserver-bezeichnungen irgendwie parallel laufen zu
lassen. (es gibt noch keine "reinen/ausgearbeiteten" gedanken dazu...)


> (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?
das ist eine gute frage. aber ich denke, erstmal müssen die
grundlegenden strukturfragen geklärt werden. ich glaube icht, daß das
zauebrwort hierfür heisst: "webserver".?!






> viele Gruesse
> Thomas Berger





-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
* http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
* allegronet.de * Klaus Lehmann * D-01454 Radeberg * Kleinwolmsdorfer Str. 37
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8! Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Allways with allegro.
* Internetkataloge&  WebHosting für AllegroC
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)





Mehr Informationen über die Mailingliste Allegro