Fwd: Re: [Allegro] Fehlverhalten von y4 in Indexpar.-D.

[Klaus Lehmann]

On Thu, 02 Apr 2009 09:19:54 +0200, Bernhard Eversberg wrote: [zum
thema]



liebe kollegen, 


> Heinrich Allers schrieb:
> Der jüngst eingeführte Manipulationsbefehl y4 macht in 
> Indexparameterdateien nicht das, was er soll (und in 
> Exportparameterdateien auch tut):
> Er wandelt UTF-8-Codes nicht in Entitätencodes um, macht z.B. aus dem 
> 3-bytigen UTF-8-Code E4BAAC nicht \u20140?
> 
>>Das Programm  index.exe  macht das nicht, die anderen schon!
>>Nun, wir hatten einfach nicht gedacht, daß jemand auch im Index
>>Entitätenzahlen haben will! Davon war nicht die Rede gewesen!
>>Aber ok, es wurde schnell mal eben eingebaut. index.exe liegt
>>bereit.
>>B.E.




das funktioniert noch nicht so, wie eigentlich wünschenswert. 
herr allers wird mehr dazu sagen....


aber mal prinzipiell nachgefragt:
mich verwirren diese vielseitigen umsetzungen...
deshalb möchte ich eine vereinfachung hier diskutieren. 
bin immer für klare transparente lösungen, es soll auch 
nicht hierbei angedeutet werden, obiges sei nicht klar und trans. 
wahrscheinlich tue ich mich (noch) damit (zu) schwer...


also: meine überlegungen...


DAS sehe ich als problem:
====================
grundlage: es wird in die datenbank reingeschrieben. wir haben nur 255
zeichen für eine stelle zur verfügung. das reicht nicht. unicode
verlangt ca 65.000 zeichen. also erweitern wir es um die zweite stelle,
(die dritte stelle ist wohl nicht nötig: 255x255=65.025; es reichten
demnach 2 stellen). 
gut. ich sehe probleme zu erkennen, benötige ich nun platz für ein byte
oder für zwei? 
dann müssen diese zwei bytes von a99 umgesetzt werden. 
dann muss index.exe angepasst werden. 
das ganze muss mit (microsoft's)fonts/codes zusammenarbeiten. 
die quer/abhängigkeiten sind vielfältig.


WARUM geht es nicht so?
====================
wir nehmen das entitätenmodell (ist die bezeichnung korrekt?)
〹
damit kann ich alle unicodes abbilden.


vorteile: 
======
a99.exe, index.exe und evtl andere basisprogramme müssen nicht
verändert/ergänzt werden
die maximal 8 bytes sind eineindeutig definiert. die kann ich prima
auslesen, verwerten etc.
europäische sonderzeichen sind damit kein problem. bleiben uns
erhalten.


nachteile:
=======
statt maximal 2 bytes habe ich jetzt maximal 8 bytes.


das modell wird bereits seit vielen jahren erfolgreich bei einer
bio-chemischen datenbank "curcuma" angewandt. allerdings geht es da
nicht um sonderzeichen in farsi, sondern um chem.formeln...


sehe ich das zu simpel?
meine gedankenmodell ist bestimmt an http://www.allegro-c.de/unicode/
angelehnt... 
s.a. dort 2.a "Codierungen der Gestalt &#N; (sog. Entitäten..."


viele grüße
ihr klaus lehmann







-- 
Klaus Lehmann
eMail:  allegronet at t-online.de
phone:  03528-452 807(fax 809); mobil 0171-953 7843
adress: allegronet.de Klaus Lehmann
D-01454 Radeberg; Kleinwolmsdorfer Str. 37
Mitglied: Gewerbeverein und IHK Dresden seit 2005
http://allegronet.de + http://allegronetCMS.de

Die langjaehrige allegro-Werkstatt
Internetkataloge & WebHosting für AllegroC
Praesentationen auf den jaehrlichen bibliothe-
karischen Fachkongressen seit 2006 
****     "Our best ideas are born at home"     ****
****(Dave Lester: New Freedom Data Center,1995)****
**** 2008: allegro-cjk fuer China,Japan,Korea  ****
**** 2008: allegro-ivrit (hebraeisch)          ****