4 Zeichensätze

1. Der Zoo
2. Die Realisierung
3. Overrides

4.1 Der Zoo

Browser und Webserver kommunizieren heutzutage mittels ISO 8859-1 als verabredetem Zeichensatz, sofern nicht UTF-8. Benutzereingaben und Werte aus Formularen sind dabei URL-encodiert, d.h. 7bittig, andere Zeichen sind als %xy codiert. Der Server liefert an den Browser HTML, 8bittige Zeichen aus ISO 8859-1 sind im Prinzip legal, bevorzugt werden aber die HTML-Entitäten dafür, fast alle Browser verstehen aber auch die Angabe von Unicode-Zeichen als &#nnnn;, wobei nnnn auch größer als 255 sein darf.

allegro-Datenbanken sind typischerweise im proprietären OSTWEST-Zeichensatz codiert, die Umsetzungstabelle o.apt in den gleichfalls proprietären Zeichensatz allegro-Windows („allegro.ttf“) wird von Avanti standardmäßig eingesetzt, wenn etwa Eingaben bearbeitet werden oder eine Kurzliste gezeigt wird. Die für die Vollanzeige von Datensätzen eingesetzten Parameterdateien produzieren HTML (bzw. ISO-8859-Zeichen mit HTML-Markup).

Wir haben nun also in folgenden Situationen folgende Zeichencodierungen, die geeignet umzusetzen sind:

Benutzereingaben via Browser:

ISO 8859-1, URL-encodiert

Texte aus dem Konfigurationsskript:

Undefiniert, vorzugsweise HTML oder ISO 8859-1 oder allegro-Windows.

Direkt gelesene Kurzzeileneinträge:

OSTWEST

Unumcodierte Parameterausgabe mit y0:

OSTWEST

von Avanti gelieferte Kurzzeilen und Registerabschnitte:

allegro-Windows

von Avanti erwartete Suchbegriffe:

allegro-Windows

für Sortierungen zu benutzen:

Kleinbuchstaben und Ziffern

von Parameterdateien gelieferte Ausgabe:

HTML oder ISO 8859-1

für den Browser produzierte Werte von Formularfeldern:

HTML oder ISO 8859-1

zu produzierende Hyperlinks:

ISO 8859-1, URL-encodiert

von Parameterdateien gelieferte Werte für populo-Hooks:

OSTWEST oder HTML oder ISO 8859-1.

4.2 Die Realisierung

Interner Zeichensatz von populo ist Unicode. Von Avanti wird unterstellt, dass er in Unicode operiert ($LegacyCharset = 0) oder im Zeichensatz allegro-Windows ($LegacyCharset != 0), im folgenden „win“ genannt.

HTTP-Felder (CGI-Übergabeparameter) werden stets von Unicode nach „win“ konvertiert, dies regelt das interne Unterprogramm iso2win. Dieses Verhalten betrifft die Funktionen PO!IniVar()!, PO!Collect()! und PO!INP()!. Für im Konfigurationsscript oder im Job angegebene Defaults von Eingabefeldern wird keine Umsetzung gemacht, hier wird erwartet, daß sie bereits im Zeichensatz win codiert sind.

Die Funktion PO!Htm()! konvertiert von win nach HTML 4.0, dies regelt das interne Unterprogramm win2htm.

Direkt gelesene Kurzlisteneinträge aus der .STL-Datei (warum nicht von avanti liefern lassen?) werden automatisch mittels des internen Unterprogramms dos2win, das der allegro-Umcodierung durch o.apt entspricht, nach win umgewandelt. Dieselbe Umwandlung führt auch die Funktion PO!AHtm()! durch (deprecated).

Von Avanti gelieferte Kurzlisteneinträge, erweiterte oder nicht erweiterte Registerabschnitte werden nicht umgewandelt (im Ausgabetemplate ist möglichst PO!Htm()! auf die Bestandteile anzuwenden).

Von Avanti gelieferterte Parametrierte Ausgabe wird 1:1 durchgereicht, sollte also möglichst echtes HTML sein.

Die Funktion PO!Lin()! für die Produktion von Hyperlinks wandelt ihr Argument mittles des internen Unterprogramms win2iso nach ISO 8859-1 um und URL-encodiert das Resultat (PO!LinkIni()! hingegen codiert nicht um, da es direkt die übergebenen Felder benutzt).

Vorgaben für Formularfelder (auch Hidden Fields) sollten im Template möglichst mittels Behandlung durch PO!Htm()! vorbereitet werden, das löst auch das Problem mit aufeinandertreffenden Doppelanführungszeichen aus Template (Einschliessende Anführungszeichen für das Element-Attribut) und Daten (Anführungszeichen als Bestandteil der Daten).

Ein besonderes Problem sind die aus den in die Ausgabe eingebetteten Konstruktionen der Form LI!…!…! zu produzierenden Hyperlinks, die vom internen Unterprogramm lnkescp aufbereitet werden für die Weiterverarbeitung durch das vom Konfigurationsscript zu liefernde Unterprogramm LinkEscape. Der erste Bestandteil dieser Konstruktion ist ein optionaler Suchbegriff, der zweite Bestandteil die Präsentationsform des Hyperlinks. Dieser zweite Bestandteil wird von populo nie modifiziert, es wird erwartet, dass er durch die Parameterdatei bereits als HTML formatiert ist.

1. In der ausführlichen Form werden zwei Bestandteile angegeben, der erste Bestandteil ist ein Suchbegriff, der durch die Parameterdatei typischerweise nicht umcodiert (y0) erzeugt wird. populo wandelt den Suchbegriff zunächst mittles des internen Unterprogramms dos2iso nach ISO 8859-1, und URL-encodiert das Resultat anschliessend.

2. In der verkürzten Form muß populo den Suchbegriff aus der HTML-Darstellung des anzuzeigenden Textes zurückcodieren, dafür wird das interne Unterprogramm htm2iso benutzt, das berücksichtigt, dass die Parameterdatei HTML-Entitäten (wie &) erzeugt hat und (in manchen Fällen berücksichtigt, daß die Parameterdatei) evtl. auch numerische HTML-Codes für Zeichen ausserhalb des Bereichs von ISO 8859-1 (etwa ă für ein a mit Macron) produziert: Diese werden auf den Grundbuchstaben reduziert, um halbwegs verwertbare Suchbegriffe zu gewährleisten.

Schließlich wird für Sortierungen der Kurztitelliste das interne Unterprogramm iso2sor eingesetzt.

Direkt in die Templates eingebettete Zeichen werden 1:1 ausgegeben, populo gibt folgende Zeichensatz-Information in den HTTP-Content-Type-Header:

$HeaderContentType gesetzt

Der Wert von $HeaderContentType wird als Content-Type-Header ausgegeeben

$HeaderCharset definiert, aber

Content-Type ist text/html ohne charset-Angabe

$HeaderCharset gesetzt

Content-Type ist text/html, charset der Wert von $HeaderCharset

$LegacyCharset gesetzt

Content-Type ist text/html ohne charset-Angabe

sonst / default

Content-Type ist text/html ohne charset ist UTF-8

Benutzereingaben via Browser:] ISO 8859-1, URL-encodiert

4.3 Overrides

Bei einem anderen internen Zeichensatz als dem OSTWEST-Font von allegro müssen tendenziell alle internen Umcodierungsvorschriften ausgetauscht werden, im einzelnen sind dies:

1. win2htm für die „reguläre“ Aufbereitung durch PO!Htm()!

2. iso2win für das Einlesen der Benutzereingaben

3. win2iso als Grundlage für Hyperlinks PO!Lin()!

4. iso2sor für Kurzlistensortierungen (wird nicht automatisch benutzt, sie muss durch &STLmap im Konfigurationsskript aufgerufen werden).

5. dos2iso als Grundlage für die Hyperlinks aus der Langform der LI!…!…!-Konstruktionen

6. htm2iso als Grundlage für die Hyperlinks aus der Kurzform der LI!…!…!-Konstruktionen

7. dos2win für direkte Kurztitelzugriffe und die (überflüssige!) Funktion PO!AHtm()!

Es ist also in diesem Jargon:

dos

der zugrundeliegende Zeichensatz der Anwendung von allegro.

win

der mit o.apt aus dos gemappte Arbeitszeichensatz von Avanti, gleichzeitig der Arbeitszeichensatz von populo.

iso

ISO 8859-1 als Kommunikationszeichensatz mit dem Benutzer

htm

ISO 8859-1 und/oder HTML-Entitäten

Diese Routinen werden während der Laufzeit von populo definiert und können im Konfigurationsskript wie folgt umdefiniert werden:

%CustomTR ist ein Hash, dessen Werte anonyme Subroutinen sind, dabei ist der „Grundzustand“ theoretisch:

%CustomTR = (
   'win2htm' => \&tr_i1_ht,
   'iso2win' => \&tr_i1_al,
   'win2iso' => \&tr_al_i1,
   'iso2sor' => \&tr_is_so,
   'dos2iso' => \&tr_ow_i1,
   'htm2iso' => \&tr_ht_i1,
   'dos2win' => \&tr_ow_al,
);