From: supergau@cs.tu-berlin.de (Thipor Kong)
Subject: Re: dt. Umlaute auf SUN SPARC, X11?  (Hilfe!)
Organization: Techn. University of Berlin, Germany
Date: Sat, 25 Jul 1992 18:39:08 GMT

 > Die Geraete haben alle amerikanische Tastaturen und normalerweise ist
 > es unueblich, andere ASCII-Zeichen als 7-bit zu verwenden.
 > 
 > Nun ist mir aber aufgefallen, dass die Geraete problemlos den ISO-8859
 > Zeichensatz beherrschen und dait u.a. auch alle deutschen Umlaute
 > darstellen und verarbeiten koennen.

Hier ein Text, der die Umstellung von Software auf iso8859_1 generell be-
handelt.

Thipor

PS: hat sich schon jemand um iso8859-Umlaute f"ur 386BSD gek"ummert?


$Header: /home/c/cross/texts/RCS/Umlaute,v 1.5 1992/07/14 12:36:23 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 (z.B.) rufen isprint() auf, ohne sich vorher mit isascii()
vergewissert zu haben, dass das Argument ein 7-bit-Zeichen ist --
isprint() liefert bei 8-bit-Zeichen beliebigen Muell... (Die Manual-
page ctype(3V) ist irrefuehrend.)

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

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
--------------------------------
	IBM verwendet einen internationalen Zeichensatz, der nicht
	ISO 8859 entspricht. 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.

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). 
	Beim SunOS4.1 ist anscheinend -8 per default eingestellt, auch
	wenn die ManualPage das nicht suggestiert.

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-_
	(unter Umstaenden sind die Zeichen nur mit 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 mithilfe
	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

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. Die
	Implementierung im Fachbereichsnetz unterlaesst dies, allerdings
	auf eine noch nicht sehr intuitive Weise.
	smail: keine Ahnung.

	Es 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, aber noch nicht weit
	verbreitet. Ein korrekter Header sieht nach RFC 1341 so aus:

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

	Neuere IDA-Sendmailversionen akzeptieren auch:
	"X-Charset: ISO-8859-1" oder "X-Charset: LATIN1"

	WICHTIG: Dummerweise spezifiziert RFC822, dass Internet
	Text Messages (Mails, News-Artikel) nur 7-bit-Zeichen 
	enthalten duerfen.  Das heisst, alle oben genannten Massnahmen
	sind nur normkonform, wenn "irgendwer" eine Konvertierung in
	7-bit-Zeichen bzw. daraus zurueck vornimmt. (sendmail kann das,
	es ist aber im Fachbereichsnetz nicht eingeschaltet.)

	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.

	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").
	Es gibt noch einige Sites, die das weithin verdammte alte
	"B-News" benutzen (z.B. unido). Soweit mir bekannt, entfernt
	es das 8. Bit aus allen Artikeln, die es transferiert.

	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 --
	die meisten 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.


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.

    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--
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 !!!                                            supergau@cs.tu-berlin.de

Newsgroups: de.comp.os.unix