$Header: /home/c/cross/texts/RCS/Umlaute,v 1.6 1992/10/25 00:00:08 cross Exp cross $

	    ISO 8859-1 Umgebung -- Umlaute
	    ------------------------------

Dieser Text soll beschreiben, wie man/frau die Arbeitsumgebung 
(insbesondere die Sun- und UNIX-Umgebung) so einstellen kann,
dass die Verwendung von Zeichen, deren 8. Bit gesetzt ist 
(im folgenden 8-bit-Zeichen genannt), moeglich wird. Dabei wird
von einem Zeichensatz ausgegangen, der die normalen ASCII-Zeichen
um in Westeuropa gebraeuchliche Sonderzeichen erweitert: ISO 8859-1.
Seine Geschwister werden weiter unten dargestellt.

Es gibt sowohl im Fachbereichsnetz als auch in den deutschen News
seit langem zwei Lager: die einen sagen, UNIX sei ASCII-basiert, 
und man solle mit der Umstellung auf internationale Zeichensaetze 
solange warten, bis es (a) eine Norm gebe, die wirklich alle denkbaren 
Zeichen beruecksichtigt, und (b) alle Tools und Protokolle darauf 
eingestellt seien.  Ihre Gegner wollen darauf nicht warten, sondern 
meinen, Umlaute gehoerten zur deutschen Schriftsprache, auf deren
vollstaendigen Gebrauch sie auch auf dem Rechner nicht verzichten
wollten.

Dieses Dokument will nicht zu der Diskussion beitragen; es schildert
lediglich die Massnahmen, die bei einer Umstellung notwendig sind.


Grundsaetzlich gilt leider die Regel: Jedes noch so kleine Programm
muss einzeln dazu ueberredet werden, 8 Bit zu verstehen.
Ein grosses Uebel ist die fehlerhafte Benutzung der libc: Viele
Programme benutzen entweder 'signed char' als Zeichentyp oder rufen
isprint() und andere Klassifizierungsroutinen auf, ohne vorher mit
setlocale() die Zeichenklassen richtig eingestellt zu haben.

Bevor die Tuecken der einzelnen Programme geschildert werden,
eine Kurzzusammenfassung der Situation und notwendigen Schritte
im Fachbereichsnetz.


Kurzzusammenfassung fuer X-Umgebungen in cs.tu-berlin.de
========================================================

Folgende Aenderungen sind fuer die Standardsituation im 
Fachbereichsnetz, SunOS4.1 unter X, notwendig (natuerlich nur,
soweit die entsprechenden Programme benutzt werden ;-)):

    ~/.cshrc:     setenv LC_CTYPE iso_8859_1
		  setenv LESSCHARSET latin1

    ~/.emacs:     (set-default 'ctl-arrow 1)
                  (autoload 'accent-mode "accent-mode" "Mode for iso chars" t)

    ~/.nn/init:   set data-bits 8

    ~/.elm/elmrc: [pager = builtin ersetzen durch] pager = less
		  (ab elm-2.4 unnoetig)

Falls der emacs-mode aktiviert werden soll, der als "a, "u, etc.
eingegebene Umlaute automatisch in ISO-Zeichen umsetzt, im emacs eingeben:

    M-x accent-mode


    
Einzelne Programme (auch ausserhalb des Fachbereichsnetzes gueltig)
===================================================================

terminal
-------- [dieser Absatz gilt nur fuer ASCII Terminals]
	Bevor irgendwas an der Software gedreht wird, muss natuerlich
	das Terminal 8-bit-Zeichen uebertragen und anzeigen koennen.
	Es sollte also auf 8 bit, no parity eingestellt werden;
	der Zeichensatz sollte auf ISO8859 stehen (nicht 'International
	ASCII', dabei werden nur einige 7-bit-Zeichen ueberladen).
	VT-Terminals haben eine verlockende Option "8-bit-controls",
	die stiftet aber nur Verwirrung, solange termcap und terminfo
	nicht auch geaendert werden, und sollte deshalb auf 
	"7-bit-controls" stehenbleiben.

	Die Eingabe von Umlauten geschieht meist ueber die Compose-Taste:
	z.B. Compose-"-a (nacheinander) ergibt umlaut-a.
	Nicht zu verwechseln mit Compose-a-e (daenische ae-Ligatur).
	Alle Compose-Argumente sind mit zwei, solche mit Shift mit drei
	Tastendruecken zu erreichen.
	Die Bedeutung einiger Compose-Argumente ist davon abhaengig,
	welche Tastatur eingestellt ist.
	Eine vollstaendige Liste befindet sich in jedem DEC Terminal-
	Handbuch seit VT220.


terminalserver, telnet-Protokoll
--------------------------------
	Das Telnet-Protokoll (RFC 854) benutzt einen 8-bit-breiten
	Datenstrom, um ASCII-Daten zu uebertragen. Es ist spezifi-
	ziert, dass andere als ASCII-Zeichen "zu keiner Aktion"
	fuehren. Die meisten Terminalserver, -multiplexer und 
	Telnetprogramme (genaugenommen alle, die ich kenne) geben
	8-bit-Zeichen trotzdem an den Benutzer weiter, so dass
	ISO-Zeichen angezeigt werden koennen.

terminalserver, rlogin-Protokoll
--------------------------------
	Manche Terminalserver beherrschen auch das rlogin-Protokoll;
	bei den mir bekannten ist der Datenstrom 8 bit breit, wenn
	er nicht umgestellt wird.

Modems
------  siehe Stichwort "TTY"; alle Modems am Fachbereichsnetz
	und die des ZRZ sind auf 8-bit-Uebertragung geschaltet.

PC/Atari/Amiga-Terminalprogramme
--------------------------------
        [Dieser Abschnitt wird demnaechst ueberarbeitet]

	IBM verwendet Zeichensaetze, die nicht ISO 8859 entsprechen.
	Atari hat sich IBM angeschlossen.
	Die meisten Terminalprogramme sind aber auf ISO 8859
	umschaltbar. Diese Einstellungsmoeglichkeit darf nicht
	mit "8-bit-controls" (siehe Stichwort "Terminal") oder
	mit "international ASCII character set" (einige 7-bit-
	Zeichen mit nationalen Sonderzeichen ueberladen) 
	verwechselt werden.

	Amiga benutzt ISO-8859-Zeichensaetze.  Wenn Terminalprogramme
	auf dem Amiga ISO 8859 nicht beherrschen, sind sei mutwillig
	dumm programmiert ;-)

getty
-----   Sun's default-Eintrag in /etc/gettytab definiert "ap":
	7 bit, any parity. Er muss auf "p8" geaendert werden.

TTY
---	Obwohl 8-bit-Frames uebertragen werden, entfernen die
	TTY Treiber der meisten Betriebssysteme das 8. Bit, wenn
	sie nicht besonders daran gehindert werden.
	In BSD: "stty pass8"; in System V: "stty -istrip -ostrip cs8".
	In SunOS: eine der beiden Formen.

	Manche wirklich alten BSD4.2/4.3-Versionen benoetigen 
	zusaetzlich (sogar auf pseudo ttys!!) "-even -odd";
	standardmaessig sind sie auf 'Mark Parity' eingestellt
	(codiert als even und odd parity gleichzeitig).

Shells
------  In POSIX wurde ein System zur Unterstuetzung nationaler
	"Besonderheiten" eingefuehrt (nicht nur Zeichensaetze, sondern
	auch Dezimalpunkte, Waehrungen, Datumformat, und schlimmsten-
	falls die Sprache der Programm- und Systemmeldungen).
	Es laesst sich durch Setzen von Environmentvariablen beein-
	flussen. Der Zeichensatz wird durch LC_CTYPE umgesetzt.
	Sun unterstuetzt zur Zeit nur "default" und "iso_8859_1".
	Also: "setenv LC_CTYPE iso_8859_1".

	Andere Betriebssysteme, die National Language Support (NLS)
	schon vor POSIX hatten, benutzen meist andere Variablen, z.B.
	"LANG". Einzelheiten sind mir nicht bekannt.

	Die mitgelieferten Shells aelterer Betriebssysteme unterstuetzen
	oft gar keine 8-bit-Zeichen -- viele Programme in der alten
	4.3BSD-Release benutzen das 8. Bit als Statusbit (meist als
	Kennzeichnung, ob das entsprechende Eingabezeichen in Quotes 
	eingeschlossen war).

	Versionen der tcsh seit etwa 1988 benutzen fuer diese Zwecke
	das 16. Bit statt des 8.

rlogin
------	sollte per Alias "rlogin -L" oder "rlogin -8" aufgerufen werden. 
	Die System V-Syntax (auch DEC) erlaubt -L/-8 nur nach der Option
	"-l <user>" (falls -l angegeben wird). 
	Bei SunOS4.1 ist anscheinend -8 per default eingestellt, auch
	wenn die ManualPage das nicht dokumentiert.

xterm
-----	xterm selbst ist immer 8 bit clean. Sofern der verwendete Font
	Umlaute enthaelt (Test mit xfd -fn <font>), werden sie auch
	dargestellt (*). Die Eingabe ist etwas gewoehnungsbeduerftig:
	Die Meta-Taste setzt das 8. Bit, also:
		ae = M-d         Ae = M-D
		oe = M-v         Oe = M-V
		ue = M-|         Ue = M-\
		ss = M-_         (usw)
	(Manche dieser Kombinationen sind nur unter Zuhilfenahme von
	Shift erreichbar.)
	Die Umlaute koennen natuerlich mit xmodmap auf 'sinnvollere'
	Tasten umgelegt werden.

	(*) XTerm benutzt pseudo ttys und Shells. Wenn eines von
	beiden nur 7 Bit darstellt, kann xterm natuerlich keine
	Wunder vollbringen. Was pseudo ttys angeht, stellt XTerm
	sie zwar auf "pass8" um, aber siehe Punkt "ttys".


emacs
-----	Alle Angaben beziehen sich auf Version 18.58; aeltere Versionen
	koennen zwar auch gepatched werden (s.u.), aber das funktioniert
	angeblich nicht korrekt; neuere Versionen (emacs 19) werden
	per default 8-bit-Zeichen anzeigen koennen.

	Grundsaetzlich ist der emacs zwar 8-bit-"clean", d.h. er
	entfernt an keiner Stelle das 8. Bit, er haelt diese Zeichen
	aber fuer nicht lesbar und zeigt sie deshalb oktal an.

	Das kann durch den ctl-arrow-patch geaendert werden, der z.B.
	von ftp.cs.tu-berlin.de:/pub/gnu/emacs/contrib verfuegbar ist.
	(im Fachbereichsnetz installiert)
	Der Patch wird aktiviert durch eine Zeile in ~/.emacs:
	    (set-default 'ctl-arrow 1)

	8-bit-Zeichen koennen unter X mit der Compose-Taste wie auf
	VT-Terminals eingegeben werden (s.o.).  Damit die Zeichen nicht
	als Kommandos interpretiert werden, muss vorher quoted-insert
	(C-q) eingegeben werden. Das ist umstaendlich und kann wie beim
	xterm durch Aenderung der key bindings verbessert werden.

	Die Eingabe mittels der Compose-Taste ist aus unbekannten 
	Gruenden auf richtigen VT's leider nicht moeglich (mit der im 
	Fachbereichsnetz installierten Version).

	Alternativ koennen Umlaute als Folge von 7-bit-Zeichen mit Hilfe
	des accent-mode eingegeben werden: er wandelt 7-bit-Sequenzen
	("a, "s etc. wie in TeX) in die korrespondierenden Umlaute um.
	In ~/.emacs sollte die Zeile stehen:
	    (autoload 'accent-mode "accent-mode" "Mode for iso chars" t)
	Im emacs aktivieren mit:
	    M-x accent-mode

	Der accent-mode stammt von Bernd Petersohn <muecke@cs.tu-berlin.de>
	und ist als ftp.cs.tu-berlin.de:/pub/gnu/emacs/contrib/accent-mode.el
	verfuegbar.

vi
--	wird -- zumindest bei Sun -- durch die Variable LC_CTYPE
	(siehe Stichwort "Shells") auf 8 bit eingestellt.

Utilities
---------
	less: abhaengig von LESSCHARSET, leider nicht von LC_CTYPE.
	  LESSCHARSET muss auf "latin1" gesetzt sein.
	awk, sed, andere klassische UNIX Tools: sind sehr haeufig
	  (auch unter SunOS) nicht 8-bit-clean und auch nicht dazu
	  zu ueberreden.

Drucken
-------	Drucker sind meist ueber serielle Leitungen angeschlossen,
	die auf 8 bit eingestellt sein muessen (siehe ttys).

	Einstellungen fuer ASCII-Drucker: unbekannt

	PostScript-Drucker: Haben Fonts mit Umlauten, die entweder
	    im Klartext uebermittelt werden koennen (nachdem der
	    Drucker mit einem entsprechenden Header darauf vorbereitet
	    wurde), oder verschluesselt als 7-bit-Zeichen (so geben
	    dvips und troff Umlaute aus).

	a2ps kann nur 7-bit-Zeichen ausgeben.
	    Dafuer gibt es im Fachbereichsnetz /home/pub/bin/iso2ps.


Compiler
--------
	C-Compiler moegen keine Umlaute in Bezeichnern, weil das
	dem ANSI C Standard widerspricht. Umlaute in Kommentaren
	sind meist ungiftig. Umlaute in Strings ebenfalls; die
	meisten C Libraries (printf..) sind auch nicht allergisch
	dagegen.


Mail
----	Hier muss mensch unterscheiden zwischen MTA (Message Transfer 
        Agent, sendmail, smail) und UA (User Agent, elm, emacs/Rmail).

	sendmail: ist normalerweise nicht 8-bit-clean, sondern entfernt
	das 8. Bit aus allen vom Benutzer angenommenen Mails, weil der
	entsprechende Standard (RFC822) nur 7 Bit breite Pfade vorsieht.

	Die Implementierung von sendmail im Fachbereichsnetz aendert sich
	ab und zu auf subtile Weise (Fragen bitte an uli@cs.tu-berlin.de);
	im Moment (Oktober 1992) werden Umlaute in Mails zu manchen Sites
	unverschluesselt uebertragen, zu den meisten Sites jedoch in
	7-Bit-Zeichen gewandelt, vor denen ein escape character eingefuegt
	wird.  Zumindest theoretisch ist somit die Rekonstruktion beim
	Empfaenger moeglich, aber da die Kodierung keinem internationalen
	Standard entspricht...

	Allgemein gilt , dass fuer den Empfaenger Sonderzeichen nur 'sinnvoll'
	sind, wenn der Sender spezifiziert hat, welcher Zeichensatz benutzt
	wurde. Die Syntax der entsprechenden Header-Felder ist zwar seit
	Juni 1992 standardisiert (in RFC1341 == MIME), aber noch nicht
	weit verbreitet.
	Ein praktikabler Header fuer den Mailaustausch ueber Pfade,
	die bereits 8-bit-clean sind, ist:

	    MIME-Version: 1.0
	    Content-Type: text/plain; charset=ISO-8859-1
	    Content-Transfer-Encoding: 8bit

	WICHTIG: Dummerweise spezifiziert RFC822, dass Internet Text
	Messages (Mails, News-Artikel) nur 7-bit-Zeichen enthalten duerfen.
	Aus Kompatiblitaetsgruenden wurde diese Beschraenkung auch mit
	RFC1341 nicht aufgehoben.
	Das heisst, alle oben genannten Massnahmen sind nur normkonform,
	wenn die UAs Mails in/aus 7-bit-Zeichen codieren/rekonstruieren.

	Insbesondere ist der Header "Content-Transfer-Encoding: 8bit"
	_nicht_ RFC822-konform, weil er spezifiziert, dass 8-bit-
	Zeichen uebertragen werden; ich habe ihn zitiert, weil er
	die Situation widerspiegelt, wie 8-bit-Zeichen in Mails und
	Newsartikeln uebertragen werden, die vom Fachbereichsnetz
	ausgehen.


	elm2.3: Benutzt zur Eingabe einen Editor, siehe dort.
	Ausgabe: Der elm "builtin" pager ist NICHT 8-bit-clean, weil
	er faelschlicherweise isprint() benutzt (s.o.).
	Bis es eine korrigierte Version gibt, kann der Pager in 
	~/.elm/elmrc mit "pager = less" umgesetzt werden.

	elm2.4: Ist in Zusammenarbeit mit dem Programm 'metamail'
	MIME-faehig. [Weiteres demnaechst]

	emacs/Rmail: siehe emacs.

News
----    Das Newssystem selbst ist durchgaengig de facto 8-bit-clean.
	(Zur Zulaessigkeit der Verwendung von 8-bit-Zeichen siehe
	aber Stichwort "Mail").  Nur noch sehr wenige Sites benutzen
	das alte Bnews, das das 8. Bit abschneidet.

	Newsreader: rn, trn: sind ohne weitere Einstellungen 8-bit-clean.
	nn: in ~/.nn/init: "local data-bits 8"
	gnus: siehe emacs.

Netiquette -- WARNUNG
---------------------
	Es wird davon abgeraten, in englischsprachigen Newsgroups/Mails
	Umlaute zu benutzen (Achtung: ~/.signature). 
	Die meisten Amis haben noch nie was von ISO 8859 gehoert.

	In Europa wird sich ISO 8859 vermutlich in ca. zwei Jahren
	durchgesetzt haben (subjektive Prognose); im Moment sind aber 
	leider die meisten Mail-/Newsleser noch nicht darauf eingestellt --
	viele Betriebssysteme sind inzwischen in der Lage, 8-bit-Zeichen
	anzuzeigen (siehe oben), aber solange jeder Benutzer dazu seine
	Umgebung noch umkonfigurieren muss, wird es Leute geben, die
	8-bit-Zeichen nicht angezeigt bekommen und deshalb den Erzeuger
	dieser Zeichen anmeckern ("flamen").
    
	Ich persoenlich sage dann immer, "SunOS? HP? Xterm? Selber schuld,
	bringt Eure Umgebung in Ordnung, hier ist unser /usr/INFO/Umlaute,
	damit kriegt Ihr das schon hin"... :-)

	Aber wer garantiert keinen Aerger haben will, muss leider
	noch auf Umlaute in Mails / News verzichten, wenn er sich
	nicht mit den Emfaengern abgesprochen hat.



Zum Schluss die fundamentale Frage: Was ist eigentlich ISO-8859?

| Newsgroups: fb20.sun
| From: cabo@cs.tu-berlin.de (Carsten Bormann)
| Date: Fri, 22 May 1992 18:07:39 GMT
| 
| In der UNIX-Welt West-Europas hat sich ISO 8859-1 (oder der aeltere,
| aber aehnliche DEC-Hausstandard) durchgesetzt.  Ein a-Umlaut ist hier
| z.B. \344.  In der IBM-PC-Welt ist ein a-Umlaut aber ein \204 (man
| korrigiere mich; ich habe gerade keine Code Page 437 zur Hand).
| 
| Da man in 190 Positionen [die restlichen sind mit Sonderzeichen wie
| ESC belegt] nicht alle lateinischen alphabetischen Zeichen (und schon 
| gar nicht Kyrillisch, Hebraeisch, Arabisch, Griechisch) unterbringen 
| kann, gibt es aber auch noch ISO 8895-2 (Ost-Europa), [sorry, den Rest 
| schreibe ich auf Englisch, weil ich ihn gerade greifbar habe] and two 
| other character sets the target regions of which were not identified in 
| the standard (ISO 8859-3, ISO 8859-4).  In addition, Latin/Cyrillic (ISO
| 8859-5), Latin/Arabic (ISO 8859-6), Latin/Greek (ISO 8859-7), and
| Latin/Hebrew (ISO 8859-8) character sets have been standardized under
| the same design rules.  Finally, a fifth Latin alphabet was created to
| satisfy the needs of a European economic region that needed Turkish
| national characters but could live without the Icelandic/Faroese
| national characters present in ISO 8859-1 (ISO 8859-9).  ISO 8859-1 to
| ISO 8859-4 and ISO 8859-9 are known informally as Latin-1 to Latin-5;
| all of these character sets are a subset of the revised version of ISO
| 6937-2 (which was amended in 1989 to include a non-breakable space, a
| soft hyphen, a not sign, and a broken vertical bar).  The right code
| pages of ISO 8859-5 to ISO 8859-8 are currently the accepted way to
| encode the major non-Latin alphabetic character sets.
| 
| requirements for syllabic or ideographic character sets have up to now
| been satisfied by national standards such as the Japanese (JIS) or
| Chinese national character sets, some of which are registered under
| ISO 2375 and thus are part of ECMA-48.  A new work item is under way
| to define a unified coded character set for alphabetic, syllabic, and
| ideographic writing systems, based on a multi-byte encoding (ISO/IEC
| 10646, currently at the stage of a Draft International Standard).
| Unfortunately, as the harmonization of the various far-east
| ideographic repertoires is a time-consuming process, agreement of this
| new standard still seems to be years away.

Nachtrag im September 1992: ISO 10646, der endgueltige ;-) weltweite
Standard fuer Zeichensaetze, wurde inzwischen verabschiedet.
Die untersten 127 Zeichen sind identisch mit US-ASCII, die untersten
256 Zeichen gleichen ISO-8859-1.  Alle anderen ISO-8859-Varianten
und andere Zeichensaetze wurden in 16-bit-Zeichen kodiert.
ISO 10646 sieht zwar auch vier Byte lange Zeichen vor, bisher sind
diese aber noch nicht standardisiert, da weltweit alle Zeichen in
zwei Byte passten.

Literatur
---------

    Coded Character Set -- 7-Bit American Standard Code for Information
    Interchange, ANSI X3.4-1986.

    Information Processing -- 8-bit Single-Byte Coded Graphic Character
    Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.

    Crocker, D.: RFC 822 -- Standard for the format of ARPA Internet
    text messages.  August 1982.

    Borenstein, N.; Freed, N.: RFC 1341 -- MIME (Multipurpose Internet 
    Mail Extensions): Mechanisms for specifying and describing the 
    format of Internet message bodies.  Juni 1992.

    Moore, K.: RFC 1342 -- Representation of non-ASCII text in Internet
    message headers.  Juni 1992.

    Borenstein, N.: RFC 1343 -- User agent configuration mechanism for
    multimedia mail format information.  Juni 1992.

    Borenstein, N.: RFC 1344 -- Implications of MIME for Internet mail
    gateways.  Juni 1992.

    IEEE Standard 1003.1 (POSIX.1)

    ISO/IEC 9945-2.2 Committee Draft POSIX Shell and Utilities (POSIX.2),
    informative annex F, ISO/IEC JTC1/SC22 N1063.  Oktober 1991.

    ANSI X3.159-1989 C language standard. 1989.

    X/OPEN Portability Guide Volume 3 (XVS Supplementary Definitions),
    Chapter 3 (Native Language Support). 1987.

    Solaris 1.0.1 Developer's Set, System Services Overview, pp. 115--158,
    Native Language Application Support. Sun Microsystems 1992.

    SunOS4.1 Reference Manual (printed Version): ascii(7), iso_8859_1(7),
    locale(5), ctype(3V), gettytab(5).  Februar 1990.

    Richard M. Stallman: GNU Emacs Reference Manual. 1988--.

--end-of-file--
