[Allegro] Teilfeld-Trennzeichen bei UTF-8-Datenbank

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Lehmann,

> <cit>Umstellen auf UTF-8 behebt zwar die Inkompatibilitaeten zwischen
> <cit>allegro-Zeichensaetzen und dem Rest der Welt, es bleibt aber das
> <cit>Problem der Steuerzeichen: Auch eine auf UTF-8 umgestellte
> .ald-Datei
> <cit>koennen Sie nicht in notepad editieren und "externes Editiieren"
> <cit>bedeutet ja auch, dass Feldenden in etwas handhabbares umgesetzt
> <cit>werden, so dann auch die Unterfeld-Steuerzeichen.
> <cit>
> <cit>Sie muessen zur Vorbereitung des externen Editierens also mehr
> <cit>Steuerzeichen umsetzen als nur das Kategorieende in Zeilenumbruch
> <cit>und Kategorieanfang in "#"; Zeichen 31 etwa in das
> Unicode-Zeichen, das
> <cit>wie ein Dreieck aussieht (dessen Bedeutung also das Dreieck ist),
> beim
> <cit>Zuruecklesen ist der umgekehrte Weg zu beschreiten.
> <cit>
> <cit>Praktischer fuer die Eingabe als das Dreieck sind allerdings "$"
> <cit>oder "|".
> 
> einspruch:
> 
> 1.
> das $(dec036)-zeichen kommt sehr (?) häufig z.b. in titeln vor

oder in file-URLs oder Bestelldaten ...



> 2. 
> das Pipe(dec124)-Zeichen wird für die Bildung von s.a.-Verweisungen IM
> text benutzt.
> (was ich persönlich gar nicht gut finde: IN den datensatz wird ein
> allegro-wichtiges-steuerzeichen reingeschrieben, in früheren zeiten
> hatte ich damit sehr viele index-crashs...)

Ist auch sonst unbedingt zu vermeiden, weil es die Logik auf
den Kopf stellt: Eigentlich sollte ja die Anwendung etwas ueber
die Struktur der Daten wissen. Bei #9s und #9sa hingegen wird
unterstellt, dass die Daten etwas ueber die Struktur der
Anwendung "wissen". Das ist fatal, weil damit jeder zukuenftige
Aenderung der Indexierungsvorschriften (etwa um bessere OPACs
zu bekommen) unter dem Vorbehalt steht, dass damit gewisse
adhoc-Verweise nicht mehr "funktionieren".

Aehnliches haben wir auch bei der "Texel-Technik" (irgendwann um V23),
die mit Recht in Vergessenheit geraten ist.

Ansonsten kommt "|" allerdings (eigentlich sogar als offizielle Form,
aber wer schert sich schon drum) anstelle des ":" in file:///-Urls vor:

file:///C|/windows/system32/config.nt




> wäre das sinnvoll : das Dach?  (gerade nicht eingebbar): dec094

Als Tot-Taste hoechst problematisch fuer die Eingabe


> oder tilde? (dec126)

kommt in URLs vor.


Ich habe gerade gesehen, dass Notepad bei Eingabe von Alt+31
ein sichtbares Dreieck produziert (wie die meisten
Windows-Programme erlaubt es die Eingabe von Alt-nnn fuer
DOS-Codepositionen und Alt-0nnn fuer Windows-Codepositionen).
Dieses Dreieck ist dann allerdings nicht Zeichen 31, sondern
Unicode-25BC: Hier wird also unterstellt, dass jemand nicht
*das* Zeichen 31 will, sondern ein Dreick.

Diese "Visualisierung" des Teilfeldzeichens (nebst der "small"-
Variante) wird in ucodes.apt bzw. cat.api bereits als
Surrogat fuer das Teilfeldzeichen beruecksichtigt:

u 226 150 188 031    BLACK DOWN-POINTING TRIANGLE
u 226 150 190 031    BLACK DOWN-POINTING SMALL TRIANGLE

[Betrifft die ostwest-Nutzung, bei "Unicode intern" sind sie
beim Einlesen der extern editierten Daten allerdings explizit
zurueckzuwandeln]

Insofern korrigiere ich meine Aeusserung von gestern: Mit
Alt-31 (nicht allerdings mit dem unter DOS aequivalenten
Strg+-) besteht eine halbwegs komfortable Eingabemoeglichkeit
fuer "Dreieck", insofern kann also beim vorbereitetenden
Export fuers externe Editieren Zeichen 31 auf 226 150 188
umgewandelt werden und vor dem Zuruecklesen umgekehrt.


Generell haben wir ja zwei Ebenen: Die Ebene der Anwendungszeichen
und die der Steuerzeichen. Weil in der Anwendung tendenziell alle
Zeichen benutzt werden duerfen (bzw. zumindest: Zu jedem ueber die
Tastatur eingebbare Zeichen gibt es einen Anwender, der dieses
Zeichen auch als Anwendungszeichen benutzt) wird es eng fuer
die Steuerzeichen. Sauber geht man mit dem Dilemma so um:

1. Ueber eine "Anwendung", die die Steuerzeichen interpretiert und
   dem Anwender nur Eingabemoeglichkeiten anbietet, die die
   Steuerzeichen nicht erfordern (also tendenziell pro Unterfeld
   ein Eingabefeld -> a99 mit Formularen)

2. Ueber eine Anwendung, die traditionell nicht darstellbare Zeichen
   (eben Steuerzeichen) darstellen kann (PRESTO als 16bit-Programm,
   denn unter DOS hat (fast) jedes Zeichen irgendein "Aussehen" und
   ist daher nicht nur eingebbar sondern auch darstellbar)

3. Ueber "Escapes", d.h. "$ als Dollar" ist als "$$" (oder "\$" oder
   ...) einzugeben, "$ als Steuerzeichen" als "$" (oder $ oder
   ...). Diesen Weg kann man z.B. mit VS-Sequenzen gehen (VB 164).

4. (nicht ganz so sauber bzw. in Kombination mit den vorigen
  anzuwenden) ueber "Visualisierungen": Man "weiss" etwa, dass
  kein Anwender Dreiecke als Anwendungsdaten hat und nimmt die
  dann als Surrogat fuer Eingabe und Darstellung von Steuerzeichen.
  (das geht natuerlich regelmaessig schief, vgl. die Nutzung von
  "_" in allegro oder "!" in PICA oder "$" bzw. "|" (dort jeweils
  aber nur Visualisierung) in MARC-Systemen.

Aber "1:1" geht halt nie.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSLUwz2ITJZieluOzAQIuNQP+NX1EePcfXf6NC3FVj5IGeYijThGUQTA2
1/00xDDxeSJ8gZfsT1TJbw02ldJrrpIx24V5Gj3R3OONleK19qwz40T9+K8wZnSe
i4dvzj5xeH9oCh+SBonGAMFMtx375UHSim87XGzaJaTOzkudcnJ7gaQ6mW6k6G3R
3b00SH5Tx/I=
=r4d4
-----END PGP SIGNATURE-----