INTERNATIONALISIERUNG VON WEBANWENDUNGEN

Transkript

1 INTERNATIONALISIERUNG VON WEBANWENDUNGEN VERSION

2 Inhaltsverzeichnis... EINFÜHRUNG ZEICHENSÄTZE Bit Zeichensätze... 4 ASCII... 4 ISO-8859 Zeichensätze... 5 Unicode... 6 UTF JAVA SE... 9 CHARAKTER SET ENCODING ZWISCHEN WEBCLIENT UND WEBSERVER Zeichensatz der Response GET POST HTML FORM URI Encoding Form Encoding Probleme des URI Encoding mit Zeichensätzen Konkurrierende 8bit Zeichensätze UTF-8 und URI Encoding bit Zeichensatz konkurrierend mit UTF Lösungsansätze URI Konstruktion Formdaten JavaScript AJAX Session und Request Tomcat Probleme des Euro Zeichen KONTAKT.. 29

3 Einführung.. Die Libra Anwendungen sind für den internationalen Einsatz auf Webtechnologiebasis geeignet. Das Framework befähigt die Anwendungen, mit multinationalen Zeichensätzen und landesspezifischen Formaten gleichzeitig umzugehen, und das System kann in einer Vielzahl von Ländern und Sprachen gleichzeitig genutzt werden. Die Mehrsprachigkeit und Internationalisierung von Software hat eine ganze Reihe von Aspekten. Im Folgenden werden häufig auftretende Probleme mit Zeichensätzen in Webanwendungen dargestellt und wie diese innerhalb des Frameworks gelöst sind. Neben der Darstellung im Frontend ist auch die Datenbank bei Abfragen und Speicherung betroffen. Zeichensätze.. Zur Bestimmung des Begriffs Character Set ( Zeichensatz ) treffen wir folgende Unterscheidungen: (1) Unter einem Character Set wird eine festgelegte Menge von Zeichen für eine oder mehrere Sprachen verstanden. (2) Unter einem Character Set wird ferner die eineindeutige 1 Zuordnung dieser Zeichen zu Zahlen verstanden. Der Zahlenwert wird auch Code Point genannt. (3) Unter einer Character Set Encoding ( Zeichensatzkodierung ) wird die Abbildung eines Zeichens und seines Zahlenwerts auf ein Byte oder eine Sequenz von Bytes verstanden. So enthält der ASCII Zeichensatz alle Zeichen der englischen Sprache und ordnet diesen einen Wert von 0 bis 127 zu. Der Zeichensatz ISO enthält zunächst alle ASCII Zeichen und darüber hinaus die wichtigsten diakritischen Zeichen westeuropäischer Sprachen und umfasst 256 Zeichen. Für die Zuordnung der Zeichen zu Zahlenwerten übernimmt ISO die ASCII Regelung und ordnet den restlichen 128 Zeichen Zahlen von 128 bis 255 zu. Solange ein Zeichensatz nicht mehr als 256 Zeichen enthält (und die Zeichen auf Zahlen von 0 bis 256 abgebildet sind), ist das Encoding der Zeichen in Bytes trivial: der Code Point eines Zeichens wird in genau einem Byte dargestellt. Allerdings birgt schon der Umstand, dass es mehrere Zeichensätze gibt, gewisse Probleme. Eine Sequenz von Bytes, die in eine Folge von Zeichen dekodiert wird, kann immer nur unter der Annahme eines bestimmten Zeichensatzes übersetzt werden. Die 1 Die Umkehrbarkeit der Beziehung besteht nur unter der Annahme eines bestimmten Zeichensatzes Libra Software GmbH I Version 0.2 2

4 Assoziation einer Bytefolge mit einem Zeichensatz ist für deren Verständnis essentiell. Aus der Bytefolge selbst ist der Zeichensatz nicht ersichtlich. Solange von einer Software nur ein 256 Zeichen umfassender Zeichensatz verwendet wird und ihre Nachrichten an angrenzende Systeme und menschliche Schnittstellen immer nur in diesem einen Zeichensatz erfolgen, sind Encoding und Decoding relativ unproblematisch. Allerdings kommen einige Sprachen insbesondere ostasiatische Sprachen nicht mit 256 Zeichen aus und sind deshalb unter einem 1-Byte Encoding Schema nicht darstellbar. Auch drängt sich die Frage auf, wenn verschiedene Sprachen gleichzeitig bedient werden müssen, ob es nicht praktikabler ist, einen einzigen Zeichensatz zu haben, der alle Zeichen (und damit mehr als 256) umfasst, statt Bytefolgen immer mit einer Metainformation über ihren spezifischen Zeichensatz versehen zu müssen. Aus beiden Gesichtspunkten hat sich die Idee eines universalen Zeichensatzes entwickelt. Dass nationale Zeichensätze mit der Zeichenmenge so überaus sparsam umgehen, verdankt sich dem Umstand, dass die Entscheidung über die Aufnahme eines Zeichens nicht nur ein kulturell und sprachwissenschaftlich begründeter Akt ist. Bei der Bildung der Zeichensätze wurden die Einschränkungen des Encoding antizipiert. Solange jedes Zeichen über ein einziges Byte dargestellt wird, kann es nicht mehr als 256 Zeichen in einem Zeichensatz geben. Bei einer Ausweitung lag es deshalb auf der Hand, auf zu gehen, da dies der Raum für ein Encoding in zwei Bytes ist. Damit konnten nicht nur Sprachen mit weit umfangreicheren Zeichensätzen als 256 dargestellt, sondern ein einziger Zeichensatz für alle aktiven Sprachen festgelegt werden allerdings um den Preis, für das Encoding mehr Platz verwenden zu müssen. Dies ist, vereinfacht dargestellt, der Leitgedanke, unter dem Unicode steht. Damit eine Software an ihren Schnittstellen multinational operieren kann, muss sie entweder zu allen als Strings verstandenen Bytesequenzen die Information über den Zeichensatz in einem zusätzlichen Informationssegment mitführen oder Unicode verwenden. Unter der multinationalen Einsatzfähigkeit einer Software wurde in der Vergangenheit oft nur verstanden, dass sie in verschiedenen Ländern installiert und in dem spezifischen Zeichensatz eines Landes verwendet werden kann. Für webbasierte Anwendungen ist hingegen verlangt, dass eine einzige Instanz, Benutzergruppen verschiedener Länder gleichzeitig bedienen kann. Da dies nur auf eine der zwei genannten Alternativen zu erreichen ist und bei Web Requests die Zeichensatz-Information zu einem String nicht mitgeliefert wird, kann eine im Web betriebene Software nur mit Unicode multinationale Benutzergruppen bedienen Libra Software GmbH I Version 0.2 3

5 8 Bit Zeichensätze Da es die kleinste von einer Maschineninstruktion adressierbare Größe ist, lag es historisch gesehen nahe, das Byte als Darstellungseinheit für ein Zeichen zu verwenden. ASCII Der ASCII Zeichensatz, eine Abkürzung für American Standard Code for Information Interchange, verwendet zum Kodieren von Zeichen jedoch lediglich 7 Bit. Dass wir mit ASCII als Paradigma für Byte orientierte Zeichensätze beginnen, entbehrt nicht einer gewissen Ironie. In der Tat wurde ASCII aufsetzend auf dem Murray Code (CCITT-2) anfänglich für amerikanische Fernschreiber Modelle konzipiert. Dieser Verwendung in Fernschreibern und Lochstreifen verdanken sich in erster Linie die sieben Bits. Doch es blieb in Computersystemen jener Zeit häufig auch ein Bit dem Parity Check vorbehalten. In ASCII ist der Bereich von 0x00 bis 0x1F für Steuerzeichen (control character) reserviert, die Funktionen (wie Carriage Return, Linefeed oder Bell) auf Fernschreibern und Druckern auslösten und denen deshalb keine Schriftzeichen zugeordnet sind. Der Bereich 0x21 bis 0x7E umfasst die eigentlichen Buchstaben, Ziffern und Satzzeichen (in der ursprünglichen Fassung waren sogar Kleinbuchstaben gar nicht vorgesehen). Dem Zeichen 0x7F, DEL genannt, fiel die Funktion zu, auf Lochstreifen ein zuvor geschriebenes Zeichen wieder zu stornieren. Zur Zeit seiner Entstehung spielte ASCII nicht die Rolle eines Standards, wie heute in der Retrospektive vielleicht vermutet wird. Vielmehr waren die 8 Bit basierten EBCDIC Zeichensätze von IBM der de facto Standard für Computersysteme. Wäre ASCII von vornherein ausschließlich auf Computersysteme hin ausgelegt gewesen, hätte sich der Zeichensatz paradoxerweise vielleicht nicht als Standardzeichensatz für sie entwickelt. Denn trotz der Beschränkung auf englische Schriftzeichen wäre es fraglich gewesen, ob man sich mit sieben Bit begnügt und nicht den gesamten verfügbaren Bereich mit Sonderzeichen belegt hätte. Gerade das nicht in Anspruch genommene achte Bit ermöglichte es aber in der Folge, oberhalb von 0x7F landesspezifische 8 Bit Zeichensätze zu bilden, in denen ASCII immer als gemeinsame Größe enthalten war. ASCII wurde außerdem zum Standardzeichensatz in Unix, das in seiner Entstehungszeit gegenüber den EBCDIC basierten IBM Systeme gleichfalls eine eher bescheidene Stellung einnahm. Der 7Bit Charakter von ASCII erweist sich auch heute noch als günstig, indem er es erlaubt über das Setzen des High Order Bits eine Unicode Mehr-Byte-Sequenz einzuleiten Libra Software GmbH I Version 0.2 4

6 ISO-8859 Zeichensätze Diakritische Zeichen, wie sie in westeuropäischen Sprachen häufig vorkommen, waren in ASCII nicht vorgesehen, und für eine Verwendung außerhalb des englischsprachigen Einflussbereichs war ASCII auch nicht gedacht. Andere Sprachen verwenden zwar auch die in ASCII vorkommenden Zeichen, kommen aber ohne spezifische weitere Zeichen nicht aus. Durch Ausnutzung der vollen 8 Bits eines Byte gewinnt man gegenüber ASCII im oberen Wertebereich 128 Code Points hinzu. Dieser Bereich wurde zur Darstellung der für die anderen Sprachen dringend benötigten zusätzlichen Zeichen genutzt. Da aber auch diese zusätzlichen 128 Zeichen nicht ausreichten, um nur die europäischen Sprachen hinlänglich abzubilden, wurden spezifische Zeichensätze für einzelne Regionen und Länder geschaffen. So ist beispielsweise ein Zeichensatz für die westeuropäischen, ein anderer für auf dem kyrillischen Alphabet basierende Sprachen, ein weiterer für Griechisch zuständig. ISO-8859 ist ein Standard für eine Reihe dieser landesspezifischen Zeichensätze. ISO Latin-1 Dänisch, Holländisch, Englisch, Finnisch, Französisch, Deutsch, Isländisch, Irisch, Italienisch, Norwegisch, Portugiesisch, Reto Romanisch, Schottisches Gälisch, Spanisch, Schwedisch, Albanisch, Afrikaans, Swahili. ISO ISO Latin-2 Central European Latin-4 North European Bosnisch, Polnisch, Kroatisch, Tschechisch, Slovakisch, Slowenisch, Ungarisch Estland, Lettland, Litauen, Grönland, Finnland ISO Latin/Cyrillic Slawische Sprachen, die Kyrillisch verwenden wie Russisch, Bulgarisch, Mazedonisch, Serbisch, Ukraine ISO Latin/Arabic Arabisch ISO Latin/Greek Griechisch ISO Latin/Hebrew modernes Hebräisch (Israel) ISO Latin-5 Turkish Türkisch, Kurdisch ISO Latin-6 Nordic Alternative zu Latin-4 für nordische Sprachen, Baltische Sprachen bevorzugen Latin-4. ISO Latin/Thai Thailand ISO Überarbeitung von : entfernt selten gebrauchte Symbole entfernt, stattdessen Euro Zeichen und Š, š, Ž, ž, Œ, œ, und Ÿ, die im Französischen, Finnischen und in Estland gebraucht werden 2013 Libra Software GmbH I Version 0.2 5

7 In allen ISO-8859 Zeichensätzen entsprechen die ersten 128 Code Points genau den ASCII Zeichen. Unicode Unicode ist unter der Zielsetzung entstanden, einen universalen, alle Schriftzeichen umfassenden Zeichensatz zu definieren. Da die mögliche Anzahl von Zeichen immer durch deren Encodings bestimmt ist und es bei einer Erweiterung nahe lag, von dem bisherigen einen Byte auf zwei Bytes für die Darstellung des Zahlenwerts zu gehen, konnte Unicode von Anfang an über mögliche Zeichen verfügen. Gegenüber den 256 Zeichen der 8 Bit Zeichensätze schien die Menge von zunächst auch ausreichend, die Zeichen aller Sprachen aufzunehmen. In Java und anderen modernen Programmiersprachen ist ein String deshalb nicht eine Sequenz von Bytes, sondern eine Sequenz von char Primitiven, wobei ein char zwei Bytes umfasst. Strings sind Unicode basiert in Java. Der Unicode Standard legt fest, welches Zeichen genauer gesagt spricht man von einem Graphem als Abstraktion zu einem konkreten Glyph 2 als diskretes Element aufgenommen wird, und ordnet dem Zeichen einen eindeutigen Code Point (einen Zahlenwert im Sinne von Definition 2) zu. Die Notation eines Code Points erfolgt hexadezimal mit vorangestelltem U+. Die ersten 256 Code Points von Unicode entsprechen ISO , was eine Konvertierung von Texten in westeuropäischen Sprachen erleichtern sollte. (Zu bemerken ist, dass dies zwar auf die Code Points im Sinne von Definition 2, aber nicht unbedingt deren Encodings zutrifft. So ist UTF-8 nur aufwärtskompatibel zu ASCII, aber nicht zu ISO ) Da Unicode die Zeichen aller 8 Bit Zeichensätze in einem einzigen Zeichensatz umfasst, löst sich das Problem, zum korrekten Verständnis einer Bytefolge die Information über den Zeichensatz mitführen zu müssen. Dies allerdings nur in einer Umgebung, in der Unicode als alleiniger Zeichensatz (was mit 8 Bit Zeichensätzen nicht möglich war) fungiert. Wird ein Unicode Encoding parallel und in Konkurrenz zu 8 Bit Zeichensätzen verwendet, muss zu einer Bytefolge das Encoding weiterhin mitgeführt werden. Das ursprünglich primäre Encoding von Unicode, das auch in Implementierungen wie Java verwendet wurde, war UCS-2, das zwei Bytes zur Darstellung benutzt und damit Code Points von U+0000 bis U+FFFF abbilden kann. Im weiteren Verlauf zeigte sich, dass die Menge von nicht ausreichte, um wirklich alle Zeichen aufnehmen zu können. Allerdings wurden erst mit Version 3.1 in 2 Ein Glyph ist ein konkretes Schriftbild Libra Software GmbH I Version 0.2 6

8 2001 zum ersten Mal wirklich Zuordnungen außerhalb dieses Bereichs der Basic Multilingual Plane (oder BMP) vorgenommen. Unicode reserviert heute 1,114,112 (0x110000) Code Points. In Unicode 5.0 sind davon (9.1%) einem Zeichen zugeordnet, (12.3%) für private Nutzung reserviert und (78.6%) noch unbelegt. Der Raum für Code Points ist dabei in 17 so genannte Planes aufgeteilt, jede Plane hat Code Points. Plane 0 (0000 FFFF) Plane 1 ( FFFF) Plane 2 ( FFFF) Basic Multilingual Plane (BMP) Supplementary Multilingual Plane (SMP) Supplementary Ideographic Plane (SIP) Plane 3 bis 13 (30000 DFFFF) unbelegt Plane 14 (E0000 EFFFF) Plane 15 (F0000 FFFFF) Plane 16 ( FFFF) Supplementary Special-purpose Plane (SSP) reserviert für Private Use Area (PUA) reserviert für Private Use Area (PUA) Um keinen falschen Eindruck aufkommen zu lassen: schon Plane 0, der so genannte Basic Multilingual Plane (BMP) und ursprüngliche Unicode Character Set, umfasst bereits die Schriftzeichen aller aktiven Sprachen, inklusive Chinesisch, Japanisch und Koreanisch (die im BMP die überwältigende Mehrheit der Zeichen stellen). In Plane 1 geht es um Schriftzeichen von Sprachen wie Alt Persisch, Gotisch, Phönizisch, Alt Italienisch, um mathematische Symbole u. a. und Plane 3 bis 13 reservieren vorsorglich Platz für Zeichen noch nicht entdeckter Sprachen und zukünftige Erweiterungen. Die Zahl von 1,114,112 reservierten Code Points ist deshalb weitgehend unbelegt. Gleichwohl sind heute Zeichen definiert was neue Encodings nahe legt. Denn auch bei einer Beschränkung auf die definierten Zeichen, sind diese nicht mehr alle in 2 Bytes darstellbar. Im Unterschied zu UCS-2 wurde deshalb zunächst UTF-16 entwickelt, um Zeichen außerhalb der BMP darstellen zu können. Wenn ein zwei Byte Paar im Bereich von U+D800 bis U+DBFF (der Bereich U+D800 bis U+F8FF ist in der BMP als Private Use Area ausgewiesen) liegt, handelt es sich innerhalb UTF-16 um ein Surrogat, d.h. das nachfolgende Byte Paar ist zur Bestimmung des Code Points mit hinzuziehen. UTF-16 ist das intern verwendete Format für Microsoft Windows NT/2000/XP/CE (ab Windows 2000, davor war es UCS-2),.NET und Java (ab J2SE 1.5, davor war es UCS-2). Siehe: Libra Software GmbH I Version 0.2 7

9 UTF-8 Neben dem ursprünglichen UCS-2 Verfahren und dessen Nachfolger UTF-16 gibt es eine ganze Reihe weiterer Kodierungsverfahren, um die tatsächlichen Zeichen und potentiellen 1,114,112 Code Points von Unicode in Bytes darzustellen. Dem UTF-8 Encoding müssen wir in unserem Kontext besondere Beachtung schenken, weil es im Austausch von Unicode Daten über Netzwerke zum beherrschenden Standardformat avanciert ist. Wenn der Code Point eines Zeichens unter U+80 liegt mithin im ASCII Bereich liegt, kommt das UTF-8 Encoding mit einem Byte aus um den Preis, dass auch Zeichen zwischen U+80 und U+FF bereits in zwei Bytes dargestellt werden müssen, was zwar gegenüber ISO , aber nicht UTF-16 einen Mehrbedarf an Platz für den Bereich bis U+FF bedeutet. ASCII Zeichen kann UTF-8 mit einem Byte darstellen weshalb das UTF-8 Encoding einer Folge von ASCII Zeichen mit ihrer ASCII Darstellung identisch ist. Für den Bereich von U+80 bis U+7FF benötigt UTF-8 zwei Bytes, von U+800 bis U+FFFF drei Bytes und ab U vier Bytes. UTF-8 strebt in der Annahme, dass Zeichen mit höheren Code Points seltener vorkommen, einen auf eine Byte Grenze bezogen möglichst geringen Platzbedarf an, was vor allem bei der Übertragung von Daten in Netzwerken Bedeutung hat. UTF-8-Kodierung Anzahl kodierter Bits 0xxxxxxx 7 110xxxxx 10xxxxxx xxxx 10xxxxxx 10xxxxxx xxx 10xxxxxx 10xxxxxx 10xxxxxx 21 Die Zahl der High Order Bits des ersten Byte, die auf 1 gesetzt sind, zeigt an, wie viele nachfolgende Bytes für das Encoding verwendet werden. Alle nachfolgenden eingeschlossenen Bytes beginnen mit den High Order Bits 1 und 0 (und können damit niemals als ASCII Zeichen missinterpretiert werden). Der eigentliche Code Point wird in den freien Bits kodiert Libra Software GmbH I Version 0.2 8

10 Java SE.. Java war eine der ersten Sprachen, in der Strings auf Basis von Unicode implementiert sind. Anders als in C wird in Java zwischen einem byte und einem char unterschieden. Damit stellen sich die traditionellen Zeichensatzprobleme im Grunde nur, wenn Java mit externen Systemen kommuniziert, d.h. wenn die Anwendung mit Daten aus dem Filesystem, aus einer Datenbank oder über das Netzwerk operiert. Java unterscheidet in seinem Klassensystem zwischen byte und char Streams, also zwischen InputStream und OutputStream auf der einen und Reader oder Writer auf der anderen Seite. In einen OutputStream werden byte Arrays, in einen Writer char Arrays geschrieben. Reader und Writer sitzen typischerweise auf Byte Streams (die wiederum ihre Basis in einer Netzwerkverbindung oder im Filesystem haben). Für die dabei stattfindende Transformation von char Primitiven in Bytes muss der Ziel- Zeichensatz für den Bytestream festliegen (was entweder über den Default 3 der JVM oder explizit über Bridge Klassen wie OutputStreamWriter und InputStreamReader erfolgt). Wenn es sich beim Zielzeichensatz beispielsweise um ISO handelt, werden aus 16 Bit Unicode Zeichen 8 Bit Zeichen. Sollte der Character Stream Zeichen enthalten, die nicht in den Zielzeichensatz transformiert werden können, wird ein Substitutionszeichen eingesetzt. Strings (und andere typische Java Objekte) können auch direkt in byte Streams geschrieben werden, insbesondere in PrintStream Objekte (weshalb ein Konstruktor der PrintStream Klasse ein Argument für den Zeichensatz des Streams vorsieht). Java hatte für die interne Darstellung von Zeichen in Strings und anderen Objekten ursprünglich das einfache UCS-2 Encoding verwendet. Nach der Ausweitung von 2001 über den BMP hinaus, war deshalb zur vollen Unicode Unterstützung ein neues Encoding notwendig. Unter den vorhandenen Alternativen entschied man sich für UTF- 16, das das bisherige UCS-2 ablöst 4. Java unterscheidet ab 1.5 zwischen Code Points und char Primitiven. Die Klasse String hat ab dieser Version eine Methode codepointcount(), die im Unterschied zu length() nicht die Anzahl der char Primitive, sondern die Anzahl der Unicode Code Points zurückgibt. 3 System Property file.encoding und sun.jnu.encoding. (JNU steht für JNI Utilities) Unter Windows ist der Wert meist Cp1252, unter Linux UTF-8. Zu beachten ist, dass im J2EE Kontext andere Defaults greifen Libra Software GmbH I Version 0.2 9

11 Character Set Encoding zwischen Webclient und Webserver.. Die Kommunikation zwischen Browser und Webserver erfolgt über das http Protokoll 5. Wir können uns auf die Methoden GET und POST des http Protokolls beschränken. Beide haben ihre Besonderheiten. Bei einem http GET wird vom Browser nur eine URL und kein Body übermittelt. GET /bap/test/encode/encode.jsp HTTP/1.1 Host: libra:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.8.1) Gecko/ Firefox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Der Webserver sendet die Ressource, die er zu der URL findet, in einem Content spezifischen Format an den Browser zurück. HTTP/ OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=iso Content-Length: 4298 Date: Wed, 29 Nov :24:36 GMT Der Typ des zurückgeschickten Contents wird in dem http Header Content-Type: text/html;iso ;charset=iso mitgeschickt. Sofern es sich um ein Textformat handelt, auch Informationen zum Character Set. Im Falle von POST enthält die vom Browser an den Webserver übermittelte Nachricht nicht nur Header, sondern auch einen Body. POST /bap/test/encode/encode.jsp HTTP/1.1 Host: libra:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.8.1) Gecko/ Firefox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q =0.8,image/png,*/*;q=0.5 5 für https gilt in Hinsicht auf Probleme des Character Set Encoding das Gleiche 2013 Libra Software GmbH I Version

12 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Content-Type: application/x-www-form-urlencoded Content-Length: 14 Posting 14 bytes... from=abc+%2b+3 Im Webserver stehen für die empfangene Anforderung das request Objekt und für das Senden der Antwort das response Objekt zur Verfügung. Beide haben Attribute, die den Content Type und den Character Set betreffen und die programmatisch abgefragt oder gesetzt werden können. Zeichensatz der Response Im Falle von Webanwendungen werden in einer Response vom Server dynamisch erzeugte HTML Seiten an den Client geschickt. Die HTML Syntax selbst besteht nur aus ASCII Zeichen. Zeichensatz abhängig sind jedoch die Werte von Attributen und die Inhalte der HTML Tags. Solche Zeichensatz sensitiven Strings, die in die Generierung des HTML Output Stroms einfließen, entstammen verschiedenen Quellen - Datenbank - Textdateien (XML Dateien, Ressource Bundles etc.) - Benutzer Eingaben eines vorangegangenen Server Zyklus Da Strings in Java in Unicode dargestellt werden, besteht eine Problematik nur beim Einlesen aus Bytesequenzen und beim Ausgeben über eine JSP Seite oder dem direkten Schreiben auf den Writer einer Response. Was den Browser als Empfänger einer Response betrifft, so kann dieser (jedenfalls Internet Explorer und Mozilla) prinzipiell alle vorkommenden Zeichensätze handhaben (Browser arbeiten intern mit Unicode basierten Strings). Bedingt durch seine Konfiguration oder Default Settings in Kombination mit Einstellungen des Client Betriebssystems, sind aus der Vielzahl der unterstützen Zeichensätze in der Regel jedoch nicht mehr als ein 8 Bit Zeichensatz und zusätzlich ein Unicode Encoding wie UTF-8 relevant. Welche Zeichensätze der Browser genau unterstützt, teilt er dem Server in einem http Header des Requests mit, aus dem Sprache und Zeichensatz Settings des Clients hervorgehen: Accept-Language: en-us,en;q=0.5 Accept-Charset: ISO ,utf-8;q=0.7,*;q= Libra Software GmbH I Version

13 Was die Response betrifft, teilt der Server dem Client gleichfalls in einem Header mit, welchen Typ der zurückgeschickte Content hat. Dabei wird oft in dem Content-Type Header das Character Encoding mitspezifiziert. Wie wir oben gesehen haben Content-Type: text/html;iso ;charset=iso Die Information, in welchem Character Set der Content kodiert ist, wird vom Browser verwendet, um die Zeichenketten dann Browser-intern wieder richtig darzustellen, denn Browser-intern verwenden Internet Explorer und Mozilla Unicode. Auf den Writer einer Response wird im Servlet Container in Strings geschrieben. Zur Netzwerkseite muss der Buffer des Writers in einen Bytestream umgesetzt werden. Der dabei verwendete Character Set wird dem response Objekt entnommen. Der Character Set der Response wird meistens explizit oder implizit mit dem Content Type gesetzt. Im Libra Framework wird der Character Set der Response prophylaktisch 6 explizit im Session Filter vor der Request Verarbeitung gesetzt. Eine Nachbemerkung zu statischen HTML Dokumenten: Da ein Webserver diese direkt aus dem Filesystem liest und unverändert an den Client schickt, wurde es in diesen Fall als nicht sehr praktisch empfunden, Content Type und Character Set in einem http Header mitgeben zu müssen. Woher soll der http Server den Character Set kennen? Deshalb hält HTML syntaktisch ein Meta Tag bereit, das vom Autor im Dokument selbst gesetzt werden kann und das vom Browser zu berücksichtigen ist. <meta http-equiv="content-type" content="text/html; charset=iso "> Da die Datei mindestens bis zu dieser Stelle vom Browser unter der Annahme eines Character Sets gelesen werden muss, gehen die verschiedenen Browser mit einer Bestimmung des Character Sets über diesen Weg teilweise unterschiedlich um. Zu bevorzugen ist die Methode des Setzens eines entsprechenden http Headers, was im Falle von dynamisch erzeugten Contents kein Problem darstellen sollte. GET Bei einem http GET wird kein Header, der einen Content Type spezifiziert, mitgeschickt. Dies liegt gewissermaßen auf der Hand, da nur eine URL und kein Content übertragen wird. Aufgrund eines fehlenden Content Type fehlt eine Angabe über den Character Set. 6 response.setcharacterencoding (String charset): This method can be called repeatedly to change the character encoding. This method has no effect if it is called after getwriter has been called or after the response has been committed. (J2EE Specification 1.4) 2013 Libra Software GmbH I Version

14 Auch im Falle eines GET werden jedoch typischerweise vom Browser über den Pfad 7 der URL hinaus spezifische Informationen als Parameter 8 im Query String der URL übertragen. Wird nun beim Bilden der URI und dessen Query Strings ein anderer Zeichensatz verwendet als beim Abfragen der Parameter auf dem Server, kann es zu abweichenden Werten kommen. Für das Encoding von Komponenten in einer URI wird die % Notation verwendet und mindestens gilt bei Annahme eines 8bit Zeichensatzes (wie ISO ), dass jedes Zeichen, dessen Binärwert größer x7f (mithin kein ASCII Zeichen) ist, als %nn darzustellen ist (wobei nn die Hexadezimalziffern seines numerischen Werts sind). Ein ü aus ISO wird so zu %FC. Wird jedoch beim Encodieren von URL Komponenten UTF-8 als Zeichensatz verwendet, wird ü zu %C3%BC. Auf dem Server wird in Java Webcontainern ISO als Default Encoding für die Umsetzung von Readern und Writern auf Input- und Output Streams verwendet. Wird der Wert Müller in einem Parameter name im Queryteil einer URL unter UTF- 8 kodiert, wird der Parameter als name=m%c3%bcller übertragen. Da bei GET kein Header über den Zeichensatz mitgeschickt wird, wird der Parameterwert unter ISO als Müller verstanden. Im Falle eines GET wird jedoch keine Information über ein Character Encoding mitgeschickt, schon gar nicht, welches Character Encoding bei Bildung der URI verwendet wurde. GET Requests kommen zustande, wenn a) auf dem Client ein Link aktiviert wird (die Response des Servers wird in das Window des Links (oder ein anderes im Link spezifiziertes Window geladen) b) auf dem Client wird programmatisch (durch Javascript) die Location Property eines Window gesetzt c) auf dem Client wird programmatisch durch Aufruf von Window.open() oder Window.showModalDialog() ein neues Fenster geladen d) auf dem Client wird eine Form mit method=get submittiert e) programmatischer AJAX Aufruf mit http GET In allen Fällen (mit Ausnahme des Form Submit) ist der Browser selbst in die Bildung der URI für den Request nicht involviert. Die URI stammt aus dem Attributwert eines 7 Der Pfad soll dem Server sagen, wo sich die angeforderte Ressource befindet, und ist insofern an die hierarchische Verzeichnisstruktur eines Filesystems angelehnt. 8 Parameter haben einen Namen und einen Wert. Namen und Wert sind durch ein = Zeichen und mehrere Parameter untereinander durch ein & im Querystring der URL getrennt. In der Anwendungssoftware auf dem Server werden Parameter Werte durch Funktionsaufrufe wie request.getparameter( parametername ) abgefragt Libra Software GmbH I Version

15 HTML Elements, das auf eine Useraktion hin den http Request auslöst. Mit der Kodierung der URI hat der Browser nichts zu tun. Diese Attributwerte sind einfache Textstrings, die bei Verwendung von URL Rewriting (zum Einschweißen der Session ID) schon auf dem Server gebildet und als Strings in die Output Ströme injiziert werden. Mit Javascript werden diese Strings allerdings auf dem Client oft nachbehandelt. Schon hier lässt sich also erkennen, dass Zeichensatzprobleme entstehen können, wenn auf dem Server oder auf dem Client URI Strings gebildet werden. Im Falle des Submittierens einer Form mit GET nimmt jedoch auch der Browser selbst Einfluss auf die URI Bildung. Wie unter POST wird die URI dem ACTION Attribut des FORM Elements entnommen. Anders als bei POST wird bei einem GET vom Browser ein etwa vorhandener Query String aus der URI entfernt und der Query String in Gänze durch das Encoding der Form ersetzt wird. Was das Zeichensatz Encoding betrifft, wird vom Browser dabei immer der Zeichensatz verwendet, den er für das HTML Dokument ermittelt hatte. POST Bei http POST hat der übermittelte Request einen Body. Von welcher Art dieser Body ist, wird in einem http Header des Request mitgeteilt, der den Content Type näher spezifiziert. Wenn eine Form submittiert wird, ist dieser Content Type application/x-www-formurlencoded 9. POST Requests kommen zustande, wenn a) auf dem Client eine Form mit method=post submittiert wird b) programmatischer AJAX Aufruf mit http POST Eine charset Information wird für den Content Type application/x-www-formurlencoded vom Browser nicht mitgeschickt 10. Dies ist umso bedauerlicher, als es sich zum einen durch ein Anhängen leicht bewerkstelligen ließe und zum anderen auf dem Server die Information aufgrund der Zustandslosigkeit des http Protokolls tatsächlich verloren ist. Denn vom Browser wird beim Bilden des Nachrichten-Body immer der Character Set verwendet wird, den er für das HTML Dokument, dem die Form entstammt, ermittelt hat. Da auf dem Server eingehende Requests nicht zwingend einem Link oder einer Form der zuletzt produzierten Response entstammen 11, wäre es 9 "multipart/form-data" wird in diesem Dokument nicht berücksichtigt. 10 HTML 4.01 sieht für Form Element ein Attribut accept-charset vor: This attribute specifies the list of character encodings for input data that is accepted by the server processing this form. Eine Unterstützung ist jedoch für IE6 (2006) nicht gegeben. Auf der Mozilla Plattform findet das Attribut zwar Berücksichtigung, aber zum Server wird die Information weder im Content-Type noch einem separaten Header zurückgegeben. 11 insbesondere wenn Webseiten in IFRAME Panes gekachelt sind 2013 Libra Software GmbH I Version

16 eine fragile Methode, für einen Request einfach den für eine Response zuletzt verwendeten Character Set anzunehmen. Wenn eine Form submittiert wird, was in Nicht Ajax Anwendungen der Standardfall für das Zustandekommen von POST Requests ist, wird als URI für diesen Request der Wert des ACTION Attributs der Form genommen. Sollte dieser URI String bereits einen Querystring mit Parametern enthalten, wird dieser Querystring mit der URI unverändert zum Server geschickt. Die Werte der Form werden zusätzlich allein im Body der Message übertragen. Auf dem Server können bei http POST deshalb Parameter des Requests entweder der URI oder dem Message Body entstammen. Da hinsichtlich URI und Message Body unterschiedliche Zeichensatz Encodings (bedingt durch Server Konfiguration oder programmatische Maßnahmen) greifen können, führt der Webserver über den Ursprung der Parameter genau Buch. HTML FORM HTML Form Elemente haben eine zentrale Bedeutung, wenn vom Client Daten, die durch den User bearbeitet oder neu erfasst werden sollen, an den Server zurückgeschickt werden. Denn die Informationen die beim serverseitigen Generieren der Seite in ein Link geschweißt werden, können (abgesehen von einer programmatischen Manipulation durch Javascript) vom Benutzer nicht mehr geändert werden. Die Daten der Input Elemente einer Form können dabei entweder über ein http GET oder ein http POST übermittelt werden. POST ist der Standardfall, auch wenn GET der Default ist. In beiden Fällen wird auf die Input Elemente der Form das URI Encoding angewendet. Zuvor nimmt der Browser jedoch das Zeichensatz Encoding vor. Denn die Textwerte und Strings der Input Element werden intern in Unicode verwaltet. Aus dem internen Unicode Encoding transformiert der Browser beim Submittieren der Form die Werte der Input Elemente in den Zeichensatz des Dokuments (das die Form enthält). Wenn eine Form auf dem Client submittiert wird, wird vom Browser immer der für die HTML Seite geltende Zeichensatz verwendet. In Hinsicht auf die Probleme der Verwendung internationaler Zeichensätze ist für Forms festzuhalten, dass durch das Vorhandensein von Eingabefeldern das, was in kodierter Form zum Server zurück geschickt wird, anders als beim programmatischen Bilden von URLs und deren Query Strings, nicht mehr ausschließlich der Kontrolle des Servers im Generieren der Seite unterliegt. User sind zwar bei der Eingabe durch die national ausgelegten Keyboards eingeschränkt, können durch Cut und Paste jedoch in die Eingabefelder theoretisch auch andere Zeichen eingeben Libra Software GmbH I Version

17 Wenn deshalb beim Submittieren die Werte der Eingabefelder in den Zeichensatz der HTML Seite transformiert werden, kann es durchaus geschehen, dass dieser Zeichensatz die eingegebenen Zeichen gar nicht enthält. Dies ist häufig der Fall, wenn in ein Eingabefeld beispielsweise ein Zeichen eingegeben und für die Seite ISO verwendet wird. Denn ISO enthält das Euro Zeichen nicht. Oder wenn die Tastatur ein kyrillisches Keyboard Layout hat und für die HTML Seite ISO verwendet wird. URI Encoding Auf dem Client sind URI Strings Attributwerte von Elementen des HTML Dokuments: in Links lösen sie bei Aktivierung durch den Benutzer http GET Requests aus, als Action Attribut einer Form bestimmen sie die URL für den http POST beim Submittieren. Für die URI Bildung gelten unabhängig von den Regeln für die Bildung von Byteströmen in Beziehung auf Zeichensätze sehr spezifische Encoding Regeln. Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme. RFC 1738, Uniform Resource Locators (URL), December 1994 Die Notwendigkeit von Encoding Regeln liegt auf der Hand, wenn man den Querystring der URI betrachtet. = und & sind reservierte Zeichen, können aber auch im Wert eines Parameters vorkommen. Wie erkennt der Webserver, dass in betrag=a=b&firma=becker & Co&street=Erzbergerstr. 17 = in a=b und & in Becker & Co nicht die Bedeutung reservierter Zeichen haben? Sie müssen in von der URI Syntax festgelegten Escape Sequenzen kodiert werden. Metazeichen sind Zeichen im Gesamtstring einer URI, die für die verschiedenen standardisierten Schemata die verschiedenen Informationssegmente einer URI voneinander trennen. Solche Zeichen gelten als reserviert und dürfen nicht innerhalb der Informationssegmente selbst, bzw. nur in Form einer Escape Sequenz verwendet werden. Alle Zeichen in einer URL, die nicht zum ASCII Zeichensatz gehören, alle Zeichen, die zwar zum ASCII Zeichensatz gehören, aber keinem graphischen Schriftzeichen zugeordnet sind (die ASCII control character), weiter alle Zeichen, die reserviert sind, und darüber hinaus die so genannten unsicheren Zeichen müssen gemäß den für eine URI geltenden Konventionen in einer Escape Sequenz kodiert werden. Eine 2013 Libra Software GmbH I Version

18 Escape Sequenz ist ein Triplet, bestehend aus einem % und zwei hexadezimalen Ziffern, die den Binärwert des Zeichens wiedergeben Libra Software GmbH I Version

19 Hex Decimal Control Char 00-1F 0-31 Space unsafe! reserved sub-delim Quote ( ) unsafe 'Pound' character ("#") unsafe reserved gen-delim Dollar ( $ ) reserved reserved sub-delim Percent character ( % ) unsafe Ampersand ( & ) reserved reserved sub-delim reserved sub-delim ( reserved sub-delim ) reserved sub-delim * 2A 41 + reserved reserved sub-delim Plus ( + ) 2B 43 + reserved sub-delim Comma (, ) 2C 44 + reserved reserved sub-delim hyphen ( - 2D Period (. ) 2E Forward slash ("/") 2F 47 reserved reserved gen-delim Colon (":") 3A 58 reserved reserved gen-delim Semicolon (";") 3B 59 reserved reserved sub-delim < 3C 60 unsafe Equals ( = ) 3D 61 reserved reserved sub-delim > 3E 62 unsafe Question mark ("?") 3F 63 reserved reserved gen-delim 'At' symbol ("@") reserved reserved gen-delim A-Z 41-5A [ 5B 91 unsafe reserved gen-delim \ 5C 92 unsafe ] 5D 93 unsafe reserved gen-delim ^ 5E 94 unsafe Underscore ( _ ) 5F ` unsafe a-z 61-7A { 7B 123 unsafe 7C 124 unsafe } 7D 125 unsafe Tilde ( ~ ) 7E 126 unsafe Libra Software GmbH I Version

20 Der Wert a=b muss deshalb zuerst in a%3db kodiert werden, um dann in den Querystring eingesetzt zu werden. betrag=a%3db&firma=becker%20%26%20co&street= Weiter gilt, dass nicht nur Metazeichen, sondern auch so genannte unsafe characters aus dem ASCII Set durch Escape Sequenzen zu ersetzen sind. Alle ASCII Control Codes, also alle Zeichen von x00 bis x1f und x7f müssen gleichfalls (da sie nicht sichtbar sind) mit einer Escape Sequenz kodiert werden. Dass das Problem des Encoding von Zeichenketten die Werte und nicht die Namen von Parametern eines Query Strings trifft, ist durch syntaktische Regeln seitens HTML bedingt. Da die Namen der Parameter mit den Namen der Input Elemente einer Form übereinstimmen müssen, gilt für sie seitens HTML die Einschränkung: ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). Der Gebrauch von : und. in einem Namen müsste genau genommen mit einer Escape Sequenz kodiert werden. Da die zwei Zeichen jedoch im Segment des Querystrings syntaktisch als Metazeichen nicht vorkommen (und ASCII Zeichen sind, d.h. sowohl in einem spezifischen ISO wie in einem UTF-8 Zeichensatz funktionieren), werden sie in der Regel auch ohne Encoding richtig verarbeitet. Wie man sieht, unterliegt das Einsetzen von Strings in eine URI bestimmten Regeln: alle Strings müssen vor dem Einsetzen so kodiert werden, dass die in ihnen enthaltenen nicht erlaubten Zeichen (nicht erlaubt, weil sie Teil der URI Syntax sind oder als unsicher gelten) in Triplet Sequenzen aufgelöst werden. Dies hat nichts mit einem Zeichensatz Encoding zu tun. Das direkte Einfügen von Strings in eine URI, in denen die syntaktisch reservierten Zeichen nicht durch Escape Sequenzen ersetzt wären, würde die URI verfälschen und unbrauchbar machen. Die Festlegung der URI Syntax ist in verschiedenen RFCs erfolgt. RFC 1738, Uniform Resource Locators (URL), December 1994, Berners-Lee, Masinter & McCahill RFC 2396, URI Generic Syntax, August 1998, Berners-Lee, et. al. (löst RFC 1738 und RFC 1808 ab) RFC 3986, URI Generic Syntax, January 2005, Berners-Lee, et al. (löst RFC2396 ab) Eine URI ist allgemeiner als eine URL. Da es heute keinen generischen URL Standard mehr gibt, sondern dieser im URI Standard aufgegangen ist, werden beide Begriffe mit Nuancen wechselseitig gebraucht. Eine URI ist eine Zeichenfolge, die eine abstrakte oder physische Ressource identifiziert Libra Software GmbH I Version