[Allegro] Umcodiertabellen umbenennen?
Thomas Berger
ThB at Gymel.com
Mo Jan 14 10:39:24 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lieber Herr Eversberg, liebe Liste,
| Oder sieht jemand noch andere Probleme?
"Umcodierung" ist nicht alles, wie Sie weiter oben ja bereits
bezueglich "Steuerbedeutung" angemerkt hatten:
- - RTF-Dateien koennen 7-bittig sein oder 8-bittig, welche Bedeutung
~ (im Sinne vom Zeichensatz) die Codes oder Escapes haben, wird
~ wiederum im Dateikopf erst festgelegt.
- - HTML-Dateien koennen 7-bittig sein mit Zeichen als numerischen
~ Entitaeten, hexadezimalen Entitaeten, SGML-Entitaeten, oder
~ 8-bittig mit Zeichen in einem ISO-Zeichensatz plus den obigen
~ Entitaeten, oder 8-bittig mit UTF8-codierten Zeichen.
~ (und in href-Attributen muss es stets die URL-encodierung der
~ UTF8-Codierung sein...)
- - Andersherum: Wenn ich die Ausgabe UTF-8 codiere, kann es sein,
~ dass ich zusaetzlich ein Escapen von "&", '"', "<" und ">"
~ benoetige (da HTML oder XML intendiert ist), oder gerade nicht
~ (da "echter" Text herauskommen soll).
Wir haben also stets neben der Um-Codierung vom Zeichensatz der
Datenbank in den des Zielformats noch die nachgesetzte Codierung
fuer ein bestimmtes "Transportformat" zu beruecksichtigen.
Die Frage ist, ob man diese verschiedenen Ebenen der Codier-
Problematik so sauber voneinander getrennt bekommt, dass man
zwei Include-Befehle nacheinander einsetzt, etwa
ti-utf8 (liefert reines UTF-8)
tp-xml (escapt "&", "<" etc.)
(das geht, weil hier quasi nachtraeglich 4 Umcodierungen
einfach umgebogen werden).
I.A.aber nicht, denn fuer RTF waere z.B. zunaechst eine Umcodierung
von (Byte)werten OSTWEST->CP1252 notwendig, etwa ("ü")
Zeichen 129 -> Zeichen 252, anschliessend dann das RTF-spezifische
Escape: Zeichen 252 -> Text "\'fc"
D.h. solange nicht allegro ein mehrstufiges Codier-Paradigma
implementiert, braucht man kombinierte Codiertabellen, die aber
in ihrer Namensgebung sowohl Zielzeichencodierung als auch Zielformat
reflektieren.
| Kollege Berger hat ja eine Sammlung von umfassend kommentierten Dateien:
| http://www.gymel.com/charsets/crosstabs.html
Die eigentlichen Tabellen jedoch lieber dem SVN entnehmen:
http://svn.extra.gymel.com/repos/allegro/charsets/trunk/
(bzw. zum Browsen:
http://svn.extra.gymel.com/viewvc/allegro/charsets/trunk/ )
sie werden staendig von mir gepflegt, bald z.B. steht der Abgleich
mit Unicode 5.0 auf der Agenda. Die Dateien hier sind uebrigens nur
die Datensammlungen (mit Alternativsyntax fuer Export und Import),
konkrete Parameterdateien (z.B. i-*.apt bzw. Codefragmente zum
Einsetzen in .aim-Dateien, vielleicht koennte man hier kurzfristig
auch Includes erlauben?) muessen daraus (maschinell) generiert werden.
Wenn Bedarf besteht (und die Namensfrage geklaert ist), kann ich
gerne auch taeglich automatisch aktualisierte, "fertige"
Parameterdateien bereitstellen, etwa im Stil von
< http://svn.extra.gymel.com/tubscheck/produkt/ >, vgl. etwa auch
< http://svn.extra.gymel.com/capriccio/produkt/impdir/ >.
| die Namen sind uns aber ein wenig zu wenig intuitiv, z.B. ow-al.apt
| statt asc-ans.apt. (OK, ASCII und ANSI sind nicht korrekt, aber
| jeder weiß, was gemeint ist.)
| Denkbar wären folgende dreistellige Benennungen:
|
| ANSI ans: Windows-Code mit OstWest-Erweiterung (a-*.ttf notwendig)
Wenn es denn nur Erweiterungen waeren...
| ASCII asc: allegro OstWest-Code (Schrift a-dos.fon f.d. DOS-Fenster)
| HTML4 htm: Internet-Textstandard
impliziert keine Zeichencodierungen. Sofern "es" funktioniert, ist
das aber vermutlich egal.
| MAB2 mab: MAB-Daten-Codierung
ISO 5426, genau wie UNIMARC. MAB mit UTF-8-Zeichen wird auch
benoetigt.
| MARC mrc: Codierung der MARC-Katalogdaten
inklusive aller Ebenenumschaltungen und chin. Zeichen? Oder
nur "ANSEL"? MARC21 mit UTF8-Zeichen wird auch benoetigt.
| Pica pic: Proprietärer Code von Pica
| RTF rtf: Der Standard für die allegro-Hilfetexte
vermutlich besser nicht allegro-Windows-codiert.
| UTF-8 utf: Unicode-Standard
|
| Was meint die Expertenschaft?
vgl. auch einen Text aus 2002: <
http://bugzilla.gymel.com/long_list.cgi?buglist=130 >.
"ANSI" bzw. "ASCII" haben einfach sehr viele Bedeutungen, die
gaengigsten sind:
ASCII: 7bit-Texte
ANSI: ISO8859-1 bzw. CP1252-codierte Texte
Das Hauptproblem ist, dass auch in obiger Liste zwei extrem wichtige
(zugegebenermassen nicht mehr so wichtig wie vor 6 oder 15 Jahren)
Zielcodierungen vergessen werden: CP850 (MS-DOS-Zeichensatz seit
DOS 6.0) und ISO8859-1 (ISO Latin1) bzw. alternativ CP1252 (Windows
Latin 1 von M$). Es ist pikanterweise auch nach 28 Jahren allegro-C
nicht einfach moeglich, Dateien zu produzieren, die von nicht-
bibliothekarischen Anwendungen problemlos weiterverarbeitet werden
koennen (ausser man erwischt durch Zufall eine .apr, die d-utf8.apt
einbindet).
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHiy3MhKFJT0F1FsoRAltNAJ429B/RO8ZUvbBCQgYg0kDQVT1ExgCeOiNg
11HgWSUMSV44FKQ6m51cuK4=
=aztv
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro