AW: Unicode Methode 2: UTF-8 intern

[Erwin Habisch]

Lieber Herr Eversberg,

die Situation, dass 2- bzw. 3-Byte-Kombinationen ersetzt werden sollen, ist
bei unserem Katalog gegeben. Wir arbeiten mit allegro-classico und verwenden
den Ostwest-Code, wobei Sonderzeichen als zusammengesetzte Zeichen
eingegeben werden (also diakritisches Zeichen + Grundbuchstabe), da wir
nicht nur polnischsprachige Literatur, sondern auch Literatur in anderen
Sprachen Osteuropas (Lettisch, Litauisch ...) haben, deren Sonderzeichen im
Ostwest-Font nicht als Einzelzeichen enthalten sind. 

Außer in unserer Bibliothek wird so in den am 'Verbundkatalog Östliches
Europa' beteiligten Bibliotheken verfahren. Bisher werden die Diakritika in
der Titelanzeige ausgeblendet. Die Anzeige der Ergebnisliste ist momentan
etwas unbefriedigend. Wenn man beispielsweise unter 'Personen' den
Suchbegriff 'achremczyk' eingibt sieht man, wieso: Die Ergebnisliste liefert
Zeichensalat bei den Diakritika:

http://www.ruhr-uni-bochum.de/opitz/avanti/bs.html

Eine Ersetzungstabelle für Methode 1, die 2-Byte-Kombinationen ersetzt, wäre
die für uns ideale Lösung. Es sollen nicht nur polnische Zeichen wie bei
StanisÚaw Achremczyk, sondern auch Zeichen aus den übrigen Sprachen des
östlichen Europa wie beispielsweise bei  J¯anis Z¯al¯itis  gut lesbar
darstellbar sein.


Mit freundlichen Grüßen

Erwin Habisch

Nordost-Bibliothek
Conventstr. 1
21335 Lüneburg
Tel. 04131/40059-22
Fax  04131/391143
E-Mail e.habisch at ikgn.de
URL: www.ikgn.de


-----Ursprüngliche Nachricht-----
Von: Maiser at buch.biblio.etc.tu-bs.de
[mailto:Maiser at buch.biblio.etc.tu-bs.de] Im Auftrag von Bernhard Eversberg
Gesendet: Montag, 28. April 2003 12:04
An: Diskussionsliste Allegro-C
Betreff: Unicode Methode 2: UTF-8 intern


Unicode: Methode 2 - Der zweite Ansatz
--------------------------------------
Eine Machbarkeitsstudie kam zu dem Ergebnis, dass wir noch eine 
zweite Unicode-Methode realisieren koennten:

Methode 1, realisiert in V23.1, geht davon aus, den OstWest-Code als 
interne Basis unangetastet zu lassen.
Vorteile:
  -- Keine Aenderung an bestehenden Datenbanken
  -- Keine grundlegende Aenderung an bestehenden Parameterdateien
  -- Die Verwendung zusaetzlicher Sonderzeichen erfordert
     nur geringe Eingriffe in die Parametrierung
Nachteile:
  Die Einbeziehung von griechischen, kyrillischen und weiteren
  nichtlateinischen Schriften in eine Datenbank ist zwar moeglich,
  sogar deren automatische Transliterierung fuer den Index, doch
  muss dabei die HTML4-Codierung verwendet werden. Jeder der
  nichtlateinischen Buchstaben braucht dann 6 bis 8 Byte. Fuer
  einen Einsatz im grossen Stil ist das zu unelegant.
  Eingabe und Bearbeitung der ueber OstWest hinausgehenden
  Zeichen in DOS und a99 nicht komfortabel.

Methode 2, jetzt schon im Entwurfsstadium, geht davon aus, dass
eine Datenbank intern auf UTF-8 umgestellt wird.
Vorteile: 
  -- der volle Unicode wird verfuegbar
  -- Exporte in XML-Umgebungen werden sehr einfach
  -- alle Sonderzeichen brauchen nur je 2 oder 3 Byte
Nachteile:
  -- auch die deutschen Sonderbuchstaben muessen als 2-Byte-Codes
     verschluesselt werden
  -- DOS-Programme nur noch eingeschraenkt nutzbar
  -- Eingabe und Bearbeiten ALLER Sonderzeichen 
     auch in a99 unkomfortabel. Anzeige und Indexierung korrekt.
     Nur mit Web-Formular (RuckZuck-avanti) könnte man ohne Probleme
     editieren.

Methode 2 erfordert einen Mechanismus fuer den Export, der aus
UTF-8-Codes, also 2- oder 3-Byte-Kombinationen, etwas anderes
zu machen gestattet. Bisher erlaubte die Exportsprache nur das
Ersetzen einzelner Zeichen durch (ein oder mehrere) andere: 
die p- und q-Befehle.
Es muss also eine Moeglichkeit geben, in der Exportsprache zu
sagen, welche 2- bzw. 3-Byte-Kombinationen ersetzt werden sollen
und durch was. (Kein ganz neues Desiderat.)
Die neuen u-Befehle von Methode 1 haben einen etwas anderen
Zweck: sie wandeln eine UTF-8-Eingabe um in OstWest-Codes.
Diese Funktion kann aber erweitert werden: Die Syntax ist
fast dieselbe, nur mit P oder Q statt u. Solche Befehle, eingebettet
in Export- oder Indexparameter, wirken sich dann aus an
derselben Stelle, wo bisher nur die p- und q-Befehle wirken.
WENN P/Q-Befehle vorkommen, dann wirken sich p- und q-Befehle 
nur noch auf Codes unterhalb 128 aus, denn Werte oberhalb
127 gelten dann als UTF-8 und duerfen nicht als einzelne
Bytes behandelt werden, sie muessen immer zu zweit oder
dritt umcodiert werden.
Z.B. koennte in Export-Parametern stehen:
P 208 143 65         kyr. A
P 208 144 B          kyr. B
P 226 130 172 "EUR"    Euro-Symbol
Man sieht hier drei verschiedene Moeglichkeiten.

Die noetigen Listen (Dezimalcodes!) koennten mit unserem UTF-8-JavaScript-
Prograemmchen schnell erstellt werden.



Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de  
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : winmail.dat
Dateityp    : application/ms-tnef
Dateigröße  : 6524 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20030428/553ba8a0/attachment.bin>