DE69605433T2

DE69605433T2 - Unicode-wandler

Info

Publication number: DE69605433T2
Application number: DE69605433T
Authority: DE
Inventors: Andrew Daniels; Peter Edberg; John Mcconnell; Yung-Fong Tang
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1995-09-13
Filing date: 1996-09-13
Publication date: 2000-07-20
Anticipated expiration: 2016-09-14
Also published as: AU7360596A; DE69605433D1; EP0852037B1; EP0852037A1; JP2008192163A; JP2007317214A; JP4451908B2; JPH11512543A; JP4584359B2

Description

Technischer Bereich

Die vorliegende Erfindung betrifft ein System zur Umwandlung zwischen Zeichencodierungen für geschriebenen oder angezeigten Text, und genauer einen Codeumwandler zum Umwandeln von einem Zeichensatz in einen anderen Zeichensatz.

Stand der Technik

Computer und andere elektronische Vorrichtungen benutzen typischerweise Text, um mit Benutzern zu interagieren. Der Text wird gewöhnlich auf einem Bildschirm oder irgendeiner anderen Art von Anzeigevorrichtung angezeigt. Da der Text in digitaler Form innerhalb des Computers oder einer anderen elektronischen Vorrichtung dargestellt werden muß, muß eine Zeichensatzcodierung verwendet werden. Allgemein gesprochen, dient eine Zeichensatzcodierung dazu, jedes Zeichen des Zeichensatzes mit einer eindeutigen digitalen Darstellung zu codieren. Die Zeichen (welche codiert sind) entsprechen Buchstaben, Zahlen und verschiedenen Textsymbolen sind numerische Codes zur Verwendung von Computern oder anderen elektronischen Vorrichtungen zugeordnet. Der geläufigste Zeichensatz zur Verwendung mit Computern und anderen elektronischen Vorrichtungen ist der American Standrad Code for Information Exchange (ASCII'). ASCII verwendet 7-Bit-Folgen für seine Codierungen. In anderen Ländern werden andere Zeichensätze verwendet. In Europa sind die vorherrschenden Zeichencodierungsstandards die ISO 8859-X-Familie, insbesondere ISO 8859-1 (genannt "Latin- 1"), welche von der International Standards Organization (ISO) entwickelt wurde. In Japan ist der vorherrschende Zeichencodierungsstandard JIS X0208, wobei sich JIS auf den Japanese Information Standard bezieht und von der Japan Standards Association (JSA) entwickelt wurde. Beispiele für andere Zeichensätze umfassen die MacTMOS Standard Roman-Codierung (von Apple Computer, Inc.), Shift-JIS (Japan), BigS (Taiwan) und viele mehr.
Durch die fortschreitende Globalisierung der Wirtschaft und der Netzwerke ist es für Computer und andere elektronische Vorrichtungen wichtig geworden, in der Lage zu sein, mit vielfachen Zeichencodierungen umzugehen. Derselbe Computer oder dieselbe elektronische Vorrichtung können beispielsweise von Personen verschiedener Nationalitäten benutzt werden, welche mit dem Computer oder der elektronischen Vorrichtung in einer andere Sprache umgehen möchten. Gewöhnlich wird für jede Sprache eine andere Zeichensatzcodierung benötigt. Jedoch können sich auch Zeichensätze für dieselbe Sprache voneinander unterscheiden.
Es ist ebenfalls notwendig, von einer Zeichensatzcodierung in eine andere Codierung umwandeln zu können. Beispielsweise möchte ein Anwender in Frankreich, welcher ISO 8859-1 verwendet, eine elektronische Mail-Nachricht in Französisch zu einem Anwender in Israel schicken, welcher ISO 8859-8 verwendet. Da der Absender und Empfänger verschiedene Zeichensatzcodierungen verwenden, werden die Nicht-ASCII-Zeichen in der Nachricht für den Anwender in Israel verstümmelt ankommen. Idealerweise würde einer der Computer oder elektronischen Vorrichtungen von einem Zeichensatz in den anderen Zeichensatz umwandeln. Dies wurde bis zu einem begrenzten Grad für einige wenige Zeichensätze erreicht, aber in großem Ausmaß ist es mit modernen Computern oder elektronischen Vorrichtungen nicht möglich. Die Codeumwandlung gestaltet sich schwierig aufgrund der zahlreichen unterschiedlichen Zeichenstandards und der oftmals miteinander in Konflikt stehenden oder unvereinbaren nationalen Standards.
Der UnicodeTM-Standard (hiernach einfach Unicode oder Unicode-Standard genannt) wurde entwickelt, um einen internationalen Zeichencodierungsstandard zu schaffen. Die Entwickler des Unicode-Standards wollten und lieferten ein wirksameres und flexibleres Verfahren für die Zeichenidentifizierung. Der Unicode-Standard umfaßt Zeichen aller größeren anerkannten und vor dem 31. Dezember 1990 veröffentlichten internationalen Standards sowie Zeichen, welche nicht in vorherigen Standards enthalten sind. Die Zeichen werden in dem Unicode-Standard ohne Verdopplung codiert. Die Codes innerhalb des Unicode-Standards sind 16-Bits (oder 2 Bytes) groß.
Ein Zeichencodestandard wie der Unicode-Standard erleichtert die Codeumwandlung und ermöglicht das Einrichten nützlicher Verfahren, welche auf Textdatenbasis arbeiten. Beispielsweise kann, in Übereinstimmung mit dem o. g. Beispiel, der Computer oder die elektronische Vorrichtung in Frankreich Unicode-Zeichen übermitteln, und der Computer oder die elektronische Vorrichtung in Israel kann die Unicode-Zeichen, welche sie empfängt in einen auf Hebräisch basierenden Zeichensatz umwandeln, welcher vereinbar mit dem Computer oder einer anderen elektronischen Vorrichtung in Israel ist.
Hiernach findet sich eine allgemeine Überblicksdiskussion des Unicode-Standards. Für zusätzliche Einzelheiten bezüglich des Unicode-Standards siehe z. B. The Unicode Standard, Worldwide Character Encoding, Version 1.0, Addision-Wesley 1991 (Version 1.1 ist auch für zusätzliche Einzelheiten erhältlich).
Die Gestaltung des Unicode-Codierungsschemas ist unabhängig von der Gestaltung der Basis- Textverarbeitungsalgorithmen, mit Ausnahme der Richtungsgebung. Unicode- Implementierungen sollen geeignete Textverarbeitungs- und/oder -wiedergabealgorithmen enthalten. Aus Bequemlichkeitsgründen sind alle Codes in dem Unicode-Standard in eine linguistische und funktionale Kategorie gruppiert, obwohl alle Codes in dem Unicode-Standard gleich zugänglich sind. "Der Code-Raum in dem Unicode-Standard ist in sechs Bereiche unterteilt: Allgemeine Schriftarten (alphabetische und andere Schriftarten, welche relativ kleine Zeichensätze aufweisen), Bildzeichen, CJK (chinesische, japanische und koreanische) Nebenschriften, CJK-Ideograntrne, privatebrauch und und Kompatibilität. Der allgemeine Schriftartenbereich umfaßt alphabetische oder silbenmäßige Schriftarten wie Lateinisch, Kyrillisch, Griechisch, Hebräisch, Arabisch, Devanagari und Thai. Der Bildzeichenbereich umfaßt eine große Vielfalt von Zeichen für die Zeichensetzung, Mathematik, Chemie, Bildsonderzeichen usw. Der CIK-Nebenbereich umfaßt Zeichensetzung, Bildzeichen, Kana, Bopomofo und einzelnes und zusammengesetztes Hangul. Der CJK-Ideographie-Bereich bietet Raum für mehr als 20.000 ideographische Zeichen oder Zeichen von anderen Schriftarten. Der Bereich "Privatgebrauch" wird benutzt, um für den Anwender - oder Lieferanten- spezifische graphische Zeichen zu definieren. Der Kompatibilitätsbereich enthält Zeichen aus weit verbreiteten Firmen- und nationalen Standards, welche andere kanonische Darstellungen in der Unicode-Codierung aufweisen." The Unicode Standard, supra, Version 1.0, S. 13.
Der Unicode-Standard liefert Zeicheneigenschaften und Steuerzeichen. Zeicheneigenschaften sind nützlich für die Verwendung beim Parsing, Sortieren und anderen Algorithmen, welche semantische Kenntnisse über die Codepunkte innerhalb der Unicode-Codierung erfordern. Die von dem Unicode-Standard identifizierten Zeicheneigenschaften umfassen: Ziffern, Zahlen, Zwischenraumzeichen, zwischenraumlose Zeichen und die Richtung. Die Unicode-Zeichen sind auf der Basis der Zeicheneigenschaften gruppiert. Ziffern, Zahlen und Zwischenraumzeichen sind gut bekannt. Die Gruppe der zwischenraumlosen Zeichen beinhaltet die zwischenraumlosen Zeichen und die Richtungsgruppe beinhaltet die Richtungszeichen.
Zwischenraumlose Zeichen (z. B. Akzentzeichen in griechischer und römischer Schriftart, Vokalzeichen in Arabisch und Devanagari) erscheinen nicht linear in dem wiedergegebenen Endtext. In einer Unicode-Zeichencodeabfolge folgen alle solche Zeichen dem Basiszeichen, welches sie modifizieren, oder dem Zeichen, nach welchem sie in phonetischer Reihenfolge artikuliert würden (beispielsweise ist das römische "Ä" als "A'" gespeichert, wenn es nicht in einer zuvor zusammengesetzten Form gespeichert ist). Bei der Wiedergabe sollen diese Zeichen (d. h. zwischenraumlose Zeichen) bezüglich des vorherigen Basiszeichens in irgendeiner Weise positioniert werden und selber keine Zwischenraumposition einnehmen. Steuerzeichen sind in dem Unicode-Standard codiert, sind aber selber keine graphischen Zeichen. Diese Steuerzeichen können beispielsweise verwendet werden, um einen horizontalen Tabstop anzuzeigen, oder zusätzliche Informationen über den Text zu liefern, wie Formatierungsattribute oder die Struktur, oder zur Steuerung durch richtungsgebende Formatierung. Da der Unicode-Standard auch Zeichenanordnungen in zwei Richtungen liefert, umfaßt das Unicode-Codierungsschema auch Zeichen, um Änderungen in der Richtung zu spezifizieren. Beispielsweise weisen Griechisch, Römisch und Thai eine vorherrschende Richtung von links nach rechts auf, während Arabisch und Hebräisch eine vorherrschende Richtung von rechts nach links aufweisen. Die Verwendung von Steuerzeichen zur Änderung der Richtung wird manchmal von dem Anwender oder dem System benötigt, wenn links nach rechts-Zeichen in rechts nach links-Reihenfolge angezeigt werden sollen.
Ein Problem bei konventionellen Codeumwandlern liegt darin, daß sie nur in der Lage sind, ein Primärzeichen in ein Zielzeichen umzuwandeln. Diese Art von Umwandlung funktioniert bei einigen Zeichensätzen, ist aber nicht zufriedenstellend bei bestimmten Zeichensätzen (z. B. Unicode), welche zahlreiche zwischenraumlose Zeichen oder Kombinationszeichen beinhalten, welche normalerweise anderen Zeichen zugeordnet sind. Die konventionellen Codeumwandler sind auch nicht in der Lage, Symbole, Doppelbuchstaben oder Ideogramme, welche Vielfachzeichen zugeordnet sind, umzuwandeln.
Als Folge bieten die konventionellen Codeumwandler keine umfassende Umlauftreue, durch welche die Codeumwandler umwandeln und wieder zurückumwandeln können, wodurch die ursprünglich eingegebene Zeichenfolge hergestellt wird. Dies ist wichtig, wenn der Codeumwandler als Zentrum für die Umwandlung von einem Zeichencode in einen anderen verwendet wird.
Somit besteht ein Bedarf an einem Codeumwandler, welcher in der Lage ist, von Mehrfachprimärzeichen in ein einziges Zielzeichen oder von einem einzigen Primärzeichen in mehrfache Zielzeichen umzuwandeln, um eine Umlauftreue bei Zeichencodeumwandlungen sicherzustellen.
Ein weiteres Problem bei konventionellen Codeumwandlern besteht darin, daß sie nicht die Richtung berücksichtigen, wenn sie Zeichen aus einer Primärzeichenfolge in Zeichen einer Zielzeichenfolge umwandeln. Dies kann zu fehlerhaften Umwandlungen führen, da einige Zeichensätze von links nach rechts geordnet sind, während andere von rechts nach links geordnet sind. Dies tritt typischerweise auf, wenn in ein Zielzeichen umgewandelt wird, welches zwei äquivalente Zeichen für eine gegebene Zielcodierung aufweist, wobei der einzige Unterschied die Richtung ist. In diesem Fall muß für die Zuordnung des korrekten Zielzeichens die Richtung des Primärzeichens bekannt sein. Die konventionellen Codeumwandler sind auch deshalb unzureichend, da sie nicht flexibel genug sind, um bestimmte Zeichensätze (z. B. Unicode) zu handhaben, welche Zeichen beinhalten, die Sprachen entsprechen, welche von links nach rechts geordnet sind (richtungsabhängig) sowie Sprachen, welche von rechts nach links geordnet sind. Eine Unicode-Zeichenfolge, in welcher sich beispielsweise die Ordnung oder Ausrichtung der Zeichen innerhalb der Unicode-Zeichenfolge ändert, würde von konventionellen Codeumwandlern nicht korrekt umgewandelt werden, da die konventionellen Codeumwandler eine feste Richtung für die gesamte Zeichenfolge annehmen.
Es besteht somit ein Bedarf an einem Codeumwandler, weicher in der Lage ist, Zeichen aus einem Primärzeichensatz in Zeichen eines Zielzeichensatzes umzuwandeln, wobei er die Richtung der Zeichen berücksichtigt.
Aus dem Dokument US-A-5309358 (ANDREWS ET AL) vom 3. Mai 1994 ist die Umwandlung von Doppel-Byte-Zeichenfolgen von einem Austauschcode in einen anderen bekannt. Die Umwandlung verwendet Spalten- und Reihenindexe in einer Umwandlungsdatenmenge und eine nationale Doppel-Byte-Umwandlungstabelle.
Ein weiteres Problem bei einigen konventionellen Codeumwandlern ist wie folgt begründet. Bei dem Empfang von Text über ein Netzwerk kommen die dem Text zugeordneten Daten typischerweise in Datenblöcken an. Die Daten sind erst dann vollständig empfangen, nachdem alle Blöcke, welche die Daten aufweisen, empfangen wurden. Die empfangenen Daten werden in einem Puffer angeordnet, wo sie auf die Umwandlung der Zeichencodes warten. In vielen Fällen ist der Puffer nicht in der Lage, den gesamten Datenstrom oder manchmal sogar einen Block davon zu speichern. Auf jeden Fall kann das Ende des Puffers (d. h. das letzte Zeichen in dem Puffer) in der Mitte dessen eintreten, was später von dem Scanner 408 als ein Textelement bestimmt werden soll. Wenn das Ende des Puffers in der Mitte eines Textelementes eintritt, ist der Scanner 408 nicht in der Lage, das letzte Textelement korrekt zu erhalten, da die nachfolgenden Zeichen das letzte Textelement beeinflussen oder Teil von diesem sein können.
Ein weiteres Problem bei den meisten konventionellen Codeumwandlern liegt darin, daß sie bei der Umwandlung von Zeichen aus einem Primärzeichensatz in Zeichen aus einem Zielzeichensatz nicht den Kontext berücksichtigen. Bei bestimmten Zeichensätzen (z. B. Unicode) umfaßt der Zeichensatz getrennte Zeichencodes für die verschiedenen Kontextdarstellungsformen, wohingegen bei anderen Malen nur ein einziger Zeichencode vorliegt und der Kontext benutzt wird, um die Darstellungsform zu bestimmen. Konventionelle Codeumwandler sind jedoch nicht in der Lage, Codes in Übereinstimmung mit ihrem Kontext umzuwandeln. Auf dem Kontext basierende Codeumwandlung ist besonders problematisch, wenn der an der Umwandlung beteiligte Zeichensatz (wie Unicode) eine Mischung aus Techniken für die Zuordnung der Zeichenkontexte verwendet.
Es besteht somit ein Bedarf an einem Codeumwandler, welcher in der Lage ist, akkurat und flexibel Zeichen aus einem Primärzeichensatz in Zeichen aus einem Zielzeichensatz umzuwandeln, wobei er den Kontext der Zeichen berücksichtigt.

Beschreibung der Erfindung

Grob gesprochen, betrifft die Erfindung die Codeumwandlung und/oder Abkürzungsverarbeitungstechniken.
In einem ersten Aspekt der Erfindung liefert eine Codeumwandlungstechnik Umlauftreue, wobei sichergestellt wird, das die resultierenden Zeichencodes austauschbar mit anderen Plattformen sind. Das Codeumwandlungssystem ist in der Lage, ein einziges Primärzeichen oder eine Primärzeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Mit Umlauftreue kann der Primärtext in einen Zieltext und dann wieder zurück zu dem ursprünglichen Primärtext umgewandelt werden. Die Austauschbarkeit wird sichergestellt, indem die Verwendung von Standardzielzeichen maximiert und die Verwendung von privaten Zeichen minimiert wird. Die Codeumwandlung ist besonders nützlich für die Umwandlung in/aus Unicode-Zeichen aus/in andere Zeichensätze. Die Zuordnung einer Folge von Unicode- Zeichen zu einem einzigen Zeichen in einem Zielzeichensatz war bis heute nicht durchführbar. Die Erfindung liefert eine robuste Lösung, welche ein großes Maß an Flexibilität im Betrieb sowie bei der Datenspeicherung bietet. Die Erfindung kann auf zahlreiche Arten, einschließlich als Verfahren, Vorrichtung oder System oder auf einem computerlesbaren Medium implementiert werden.
Als Verfahren zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge führt eine Ausführung der Erfindung gemäß dem ersten Aspekt der Erfindung die folgenden Vorgänge durch: Empfang einer Primärzeichenfolge mit einer ersten Zeichencodierung; sequentielle Unterteilung der Primärzeichenfolge in Textelemente, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge umfaßt; Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente in einer Abbildungstabelle; und Kombinieren der Umwandlungscodes für die Textelemente, um eine Zielzeichenfolge der zweiten Zeichencodierung zu bilden.
Zusätzlich kann die Abbildungstabelle, unter Bezugnahme auf den ersten Aspekt der Erfindung, reguläre Abbildungen und Ersatzabbildungen beinhalten, und der Suchvorgang kann den Umwandlungscode für jedes der Textelemente unter Verwendung der Ersatzabbildungen bestimmen, wenn die Abbildungstabelle unter Verwendung der regulären Abbildungen keinen Umwandlungscode für die Textelemente enthält. Es wird auch bevorzugt, daß jedes der Zeichen eine ihm zugeordnete Zeichenklasse aufweist, und daß die Unterteilung der Primärzeichenfolge auf wenigstens teilweise der Zeichenklasse der Zeichen innerhalb der Primärzeichenfolge basiert.
Als ein Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge umfaßt eine Ausführung der Erfindung gemäß dem ersten Aspekt der Erfindung: einen Umwandler zur Steuerung der Umwandlung der Primärzeichenfolge mit einer ersten Zeichencodierung in die Zielzeichenfolge mit einer zweiten Zeichencodierung; eine Abfrageeinrichtung, um die Primärzeichenfolge in Textelemente zu unterteilen, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge beinhaltet; eine Abbildungstabelle zur Speicherung von Zielcodierungen für Textelemente der Primärcodierung; und eine Suchvorrichtung zum Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente in der Abbildungstabelle.
Das Codeumwandlungssystem gemäß dem ersten Aspekt der Erfindung kann ferner eine Ersatzvorrichtung und eine Abfragetabelle umfassen. Die Ersatzvorrichtung liefert Ersatzumwandlungscodes in bestimmten Fällen, wenn die Suchvorrichtung nicht in der Lage ist, einen Umwandlungscode für ein oder mehrere Textelemente zu liefern. Die Ersatzumwandlungscodes enthalten einen oder mehrere Codepunkte in der Zielcodierung, welche nicht genau äquivalent zu den Zeichen in dem Textelement sind, aber ein graphisches Aussehen aufweisen, welches ähnlich ist. Die Abfragetabelle hilft der Abfrageeinrichtung bei der Bestimmung, ob einzelne Zeichen in der Eingabezeichenfolge in ein laufendes Textelement eingefügt werden sollen, oder ob alternativ ein neues nächstes Textelement begonnen werden soll.
Als ein Abfragesystem zum Abfragen einer Eingabezeichenfolge umfaßt eine Ausführung der Erfindung gemäß dem ersten Aspekt der Erfindung eine Eingabevorrichtung zum Erhalt eines Eingabezeichens aus der Eingabezeichenfolge, wobei die Eingabezeichenfolge eine Zeichenklasse aufweist; eine Attributetabelle, um Attribute für das Eingabezeichen zu liefern; und ein Zustandsmodul, um sowohl einen nächsten Zustand für das Zustandsmodul als auch eine nächste Aktion in Übereinstimmung mit den Attributen für das Eingabezeichen und einem laufenden Zustand des Zustandsmoduls zu bestimmen. Das Abfragesystem bestimmt, basierend auf der nächsten, von dem Zustandsmodul bestimmten Aktion, ob das Eingabezeichen der Eingabezeichenfolge in ein laufendes Textelement eingefügt werden soll, oder ob das laufende Textelement enden und ein neues Textelement beginnen soll. Vorzugsweise beinhalten die Attribute wenigstens eine Zeichenklasse für das Eingabezeichen, und das Zustandsmodul bestimmt den nächsten Zustand und die nächste Aktion basierend auf der Zeichenklasse für das Eingabezeichen und dem laufenden Zustand des Zustandsmoduls.
Als ein computerlesbares Medium, welches Programmanweisungen zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge enthält, umfaßt eine Ausführung der Erfindung gemäß dem ersten Aspekt der Erfindung: einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer eine Primärzeichenfolge mit einer ersten Zeichencodierung empfängt; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer die Primärzeichenfolge in Textelemente unterteilt, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge beinhaltet; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer für jedes der Textelemente in einem Umwandlungscode sucht, welcher einer zweiten Zeichencodierung zugeordnet ist; und einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer die Umwandlungscodes für die Textelemente kombiniert, so daß eine Zielzeichenfolge mit der zweiten Zeichencodierung gebildet wird.
In einem zweiten Aspekt der Erfindung berücksichtigt ein Codeumwandlungssystem die Richtung bei der Umwandlung von Zeichen aus einer Primärzeichencodierung in eine Zielzeichencodierung.
Das Codeumwandlungssystem gemäß dem zweiten Aspekt der Erfindung ist in der Lage, ein einziges Primärzeichen oder eine Primärzeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Durch Bestimmung oder Auflösung der Richtung der sich in Umwandlung befindenden Zeichen kann das Codeumwandlungssystem dann die bestimmte oder aufgelöste Richtung der Zeichen dazu verwenden sicherzustellen, daß die korrekte Zuordnung zu der Zielzeichencodierung verwendet wird. Somit wird mit der Erfindung eine korrekte Codeumwandlung selbst dann erreicht, wenn die Ausrichtung der Zeichen innerhalb der Primärzeichenfolge variiert. Die Erfindung kann auf zahlreiche Arten, einschließlich als ein Verfahren, eine Vorrichtung oder ein System, oder auf einem computerlesbaren Medium implementiert werden.
Als ein Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge umfaßt eine Ausführung der Erfindung gemäß dem zweiten Aspekt der Erfindung: einen Wandler zur Steuerung der Umwandlung der Eingabezeichenfolge mit einer Primärzeichencodierung in eine Zielzeichenfolge mit einer Zielzeichencodierung, wobei die Eingabezeichenfolge eine Vielzahl von Zeichen beinhaltet; eine Abfrageeinrichtung zur Bestimmung der Richtung der Zeichen in der Eingabezeichenfolge; eine Abbildungstabelle zur Speicherung der Zielzeichencodierungen für die Zeichen der Primärzeichencodierung; und eine Suchvorrichtung zum Suchen eines einer zweiten Zielzeichencodierung zugeordneten Umwandlungscodes für jedes der Zeichen aus der Eingabezeichenfolge in der Abbildungstabelle, basierend auf der Richtung und der Primärzeichencodierung für die Zeichen aus der Eingabezeichenfolge. Vorzugsweise unterteilt die Abfrageeinrichtung ferner die Eingabezeichenfolge in Textelemente, wobei jedes Textelement ein oder mehrere Zeichen aus der Eingabezeichenfolge beinhaltet, bestimmt die Abfrageeinrichtung die Richtung der Textelemente, speichert die Abbildungstabelle Zielzeichencodierungen für Textelemente aus der Primärzeichencodierung und sucht die Suchvorrichtung die Zielzeichencodierung für jedes der Textelemente auf der Basis der Richtung und der Primärzeichencodierung für die Zeichen in den Textelementen. Die Ausführung kann auch eine Ersatzvorrichtung umfassen, um Ersatzumwandlungscodes in bestimmten Fällen bereitzustellen, wenn die Suchvorrichtung nicht in der Lage ist, einen Umwandlungscode für ein oder mehrere Textelemente zu liefern.
Als ein Verfahren zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge führt eine Ausführung der Erfindung gemäß dem zweiten Aspekt der Erfindung die folgenden Vorgänge durch: Empfang einer Primärzeichenfolge mit einer ersten Zeichencodierung, wobei die Primärzeichenfolge eine Vielzahl von Primärzeichen umfaßt; Bestimmung einer Richtung für die Primärzeichen der Primärzeichenfolge; Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Primärzeichen in einer Abbildungstabelle auf der Basis der ersten Zeichencodierung und der bestimmten Richtung; und Kombinieren der Umwandlungscodes für die Primärzeichen, um eine Zielzeichenfolge der zweiten Zeichencodierung zu bilden.
Als ein computerlesbares Medium, welches Programmanweisungen zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge enthält, umfaßt eine Ausführung der Erfindung gemäß dem zweiten Aspekt der Erfindung: einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer eine Primärzeichenfolge mit einer ersten Zeichencodierung empfängt; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer eine Richtung für jedes der Primärzeichen in der Primärzeichenfolge bestimmt und die Primärzeichenfolge in Textelemente unterteilt, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge beinhaltet; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer für jedes der Textelemente in einem Umwandlungscode sucht, welcher einer zweiten Zeichencodierung zugeordnet ist; und einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer die Umwandlungscodes für die Textelemente kombiniert, so daß eine Zielzeichenfolge mit der zweiten Zeichencodierung gebildet wird.
In einem dritten Aspekt der Erfindung berücksichtigt ein Codeumwandlungssystem den Kontext bei der Umwandlung von Zeichen aus einer Primärzeichencodierung in eine Zielzeichencodierung.
Das Codeumwandlungssystem gemäß dem dritten Aspekt der Eindung ist in der Lage, ein einziges Primärzeichen oder eine Primärzeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Durch Bestimmung des Kontexts der sich in Umwandlung befindenden Zeichen kann das Codeumwandlungssystem dann den bestimmten Kontext der Zeichen dazu verwenden sicherzustellen, daß die korrekte Zuordnung zu der Zielzeichencodierung verwendet wird. Somit wird mit der Erfindung eine korrekte Codeumwandlung selbst dann erreicht, wenn der Kontext der Zeichen zu unterschiedlichen Zielzeichencodierungen führt. Die Erfindung kann auf zahlreiche Arten, einschließlich als ein Verfahren, eine Vorrichtung oder ein System, oder auf einem computerlesbaren Medium implementiert werden.
Als ein Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge umfaßt eine Ausführung der Erfindung gemäß dem dritten Aspekt der Erfindung: einen Wandler zur Steuerung der Umwandlung der Eingabezeichenfolge mit einer Primärzeichencodierung in eine Zielzeichenfolge mit einer Zielzeichencodierung, wobei die Eingabezeichenfolge eine Vielzahl von Zeichen beinhaltet; eine Abfrageeinrichtung zur Bestimmung eines Kontexts für jedes der Zeichen in der Eingabezeichenfolge; eine Abbildungstabelle zur Speicherung der Zielzeichencodierungen für die Zeichen der Primärzeichencodierung; und eine Suchvorrichtung zum Suchen eines einer Zielzeichencodierung zugeordneten Umwandlungscodes für jedes der Zeichen aus der Eingabezeichenfolge in der Abbildungstabelle, basierend auf dem Kontext und der Primärzeichencodierung für die Zeichen aus der Eingabezeichenfolge. Vorzugsweise unterteilt die Abfrageeinrichtung ferner die Eingabezeichenfolge in Textelemente, wobei jedes Textelement ein oder mehrere Zeichen aus der Eingabezeichenfolge beinhaltet. Die Ausführung kann auch eine Ersatzvorrichtung umfassen, um Ersatzumwandlungscodes in bestimmten Fällen bereitzustellen, wenn die Suchvorrichtung nicht in der Lage ist, einen Umwandlungscode für ein oder mehrere Textelemente zu liefern.
Als ein Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge umfaßt eine andere Ausführung der Erfindung gemäß dem dritten Aspekt der Erfindung: eine Umwandlervorrichtung zur Steuerung der Umwandlung der Eingabezeichenfolge mit einer Primärzeichencodierung in eine Zielzeichenfolge mit einer Zielzeichencodierung; ein Zustandsmodul zur Bestimmung eines Kontexts für jedes der Zeichen in der Primärfolge; eine Abbildungsvorrichtung zur Speicherung der Zielzeichencodierungen für die Zeichen der Primärzeichencodierung; und eine Suchvorrichtung zum Suchen eines einer Zielzeichencodierung zugeordneten Umwandlungscodes für jedes der Zeichen aus der Primärzeichenfolge in der Abbildungsvorrichtung.
Als ein Verfahren zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge führt eine Ausführung der Erfindung gemäß dem dritten Aspekt der Erfindung die folgenden Vorgänge durch: Empfang einer Primärzeichenfolge mit einer ersten Zeichencodierung, wobei die Primärzeichenfolge eine Vielzahl von Primärzeichen umfaßt; Bestimmung eines Kontexts für die Primärzeichen der Primärzeichenfolge; Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Primärzeichen in einer Abbildungstabelle auf der Basis der ersten Zeichencodierung und des für das Primärzeichen bestimmten Kontexts; und Kombinieren der Umwandlungscodes für die Primärzeichen, um eine Zielzeichenfolge der zweiten Zeichencodierung zu bilden.
Als ein computerlesbares Medium, welches Programmanweisungen zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge enthält, umfaßt eine Ausführung der Erfindung gemäß dem dritten Aspekt der Erfindung: einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer eine Primärzeichenfolge mit einer ersten Zeichencodierung empfängt; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer einen Kontext für jedes der Primärzeichen in der Primärzeichenfolge bestimmt und die Primärzeichenfolge in Textelemente unterteilt, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge beinhaltet; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer für jedes der Textelemente in einem Umwandlungscode sucht, welcher einer zweiten Zeichencodierung zugeordnet ist; und einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer die Umwandlungscodes für die Textelemente kombiniert, so daß eine Zielzeichenfolge mit der zweiten Zeichencodierung gebildet wird.
In einem vierten Aspekt der Erfindung stellt eine Abkürzungsverarbeitungstechnik sicher, daß eine zur Umwandlung empfangene Primärzeichenfolge akkurat in eine andere Zielzeichencodierung umgewandelt wird, selbst wenn die Primärzeichenfolge die Länge eines Eingabepuffers überschreitet, welcher die Primärzeichenfolge für die Umwandlung hält.
Die Abkürzungsverarbeitung gemäß dem vierten Aspekt der Erfindung kürzt einen Teil der in dem Eingabepuffer gehaltenen Primärzeichenfolge ab, so daß der abgekürzte Teil in die Zielzeichenfolge umgewandelt werden kann, ohne von nachfolgenden Zeichen in der Primärzeichenfolge beeinflußt zu werden. Natürlich sollte der in dem Eingabepuffer nach der Abkürzung gehaltene Teil der Primärzeichenfolge (abgekürzter Teil) maximiert werden, so daß die Codeumwandlung wirksam durchgeführt werden kann. Die Erfindung ist besonders nützlich, wenn die Eingabeprimärzeichenfolge über ein Netzwerk als Daten empfangen wird.
Beispielsweise können die Daten Textdaten sein, welche elektronisch über das Internet übermittelt werden. In jedem Fall kann die Erfindung auf zahlreiche Arten, einschließlich als ein Verfahren, eine Vorrichtung oder ein System, oder auf einem computerlesbaren Medium implementiert werden.
Als ein Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge umfaßt eine Ausführung der Erfindung gemäß dem vierten Aspekt der Erfindung: einen Wandler zur Steuerung der Umwandlung der Eingabezeichenfolge mit einer ersten Zeichencodierung in eine Zielzeichenfolge mit einer zweiten Zeichencodierung; einen Puffer zum Empfang eines Abschnitts der Primärzeichenfolge in einem Mal, wobei die Primärzeichenfolge mehr als einen Abschnitt umfaßt; eine Abkürzungsvorrichtung zur Abkürzung des Abschnitts der Primärzeichenfolge; eine Abfrageeinrichtung zur Unterteilung des abgekürzten Abschnitts der Primärzeichenfolge in Textelemente, wobei jedes Textelement ein oder mehrere Zeichen des abgekürzten Abschnitts der Primärzeichenfolge umfaßt; eine Abbildungstabelle zur Speicherung der Zielzeichencodierungen für Textelemente der Primärzeichencodierung; und eine Suchvorrichtung zum Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente.
Als ein erstes Verfahren zur Abkürzung einer Primärzeichenfolge für die Zeichenumwandlung in eine Zielzeichenfolge, führt eine Ausführung der Erfindung gemäß dem vierten Aspekt der Erfindung die folgenden Vorgänge durch: Empfang eines Pufferabschnittes einer Primärzeichenfolge in einem Puffer, wobei die Primärzeichenfolge mehr als einen Pufferabschnitt umfaßt; Bestimmung einer Untergruppe des Pufferabschnittes der Primärzeichenfolge, welche in eine Zielzeichenfolge umgewandelt werden kann, ohne von nachfolgenden Pufferabschnitten der Primärzeichenfolge beeinflußt zu werden; und Umwandlung der Untergruppe des Pufferabschnittes der Primärzeichenfolge in Zielcodierungen. Vorzugsweise führt das erste Verfahren auch den Vorgang der Speicherung eines Restteils des Pufferabschnittes zur Umwandlung mit einem nächsten Pufferabschnitt oder dessen Untergruppe durch, wobei der Restteil zusammen mit der Untergruppe gleich dem Pufferabschnitt ist.
Als ein zweites Verfahren zur Abkürzung einer Primärzeichenfolge für die Zeichenumwandlung in eine Zielzeichenfolge, führt eine Ausführung der Erfindung gemäß dem vierten Aspekt der Erfindung die folgenden Vorgänge durch: Empfang eines Abschnittes einer Primärzeichenfolge in einem Puffer; Bestimmung eines Textelementes innerhalb des Abschnittes der Primärzeichenfolge, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge umfaßt; Bestimmung, ob das Textelement vollständig ist; Einfügen des Textelementes in einen abgekürzten Abschnitt der Primärzeichenfolge, wenn das Textelement vollständig ist; Wiederholen der Textelementbestimmung bis der Abschnitt der Prirnärzeichenfolge vollständig berücksichtigt ist; und danach Ausgabe des abgekürzten Abschnittes der Primärzeichenfolge zur Zeichenumwandlung. Vorzugsweise führt das zweite Verfahren auch den Vorgang der Speicherung eines Restabschnittes der Primärzeichenfolge zur Verwendung mit einem nächsten, in dem Puffer empfangenen Abschnitt der Primärzeichenfolge durch.
Als ein computerlesbares Medium, welches Programmanweisungen zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge enthält, umfaßt eine Ausführung der Erfindung gemäß dem vierten Aspekt der Erfindung: einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer einen Abschnitt einer Primärzeichenfolge mit einer ersten Zeichencodierung in einem Puffer empfängt; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer den Abschnitt der Primärzeichenfolge abkürzt; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer den abgekürzten Abschnitt der Primärzeichenfolge in Textelemente unterteilt, wobei jedes Textelement ein oder mehrere Zeichen des abgekürzten Abschnittes der Primärzeichenfolge beinhaltet; einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer für jedes der Textelemente in einem Umwandlungscode sucht, welcher einer zweiten Zeichencodierung zugeordnet ist; und einen computerlesbaren Code, welcher so konfiguriert ist, daß er bewirkt, daß ein Computer die Umwandlungscodes für die Textelemente kombiniert, so daß eine Zielzeichenfolge mit der zweiten Zeichencodierung gebildet wird.
Andere Aspekte und Vorteile der Erfindung werden aus der nachfolgenden detaillierten Beschreibung hervorgehen, welche in Verbindung mit den anliegenden Zeichnungen zu sehen ist, welche beispielhaft die Prinzipien der Erfindung illustrieren.

Kurze Beschreibung der Zeichnungen

Die vorliegende Erfindung ist leicht zu verstehen anhand der detaillierten Beschreibung in Verbindung mit den anliegenden Zeichnungen, bei welchen gleiche Bezugszahlen gleiche Strukturelemente bezeichnen, und bei welchen:
Abb. 1 ein Blockdiagramm eines repräsentativen Computersystems in Übereinstimmung mit der Erfindung ist;
Abb. 2 das Format der Unicode-Zeichencodierungen illustriert;
Abb. 3 ein Blockdiagramm eines erfindungsgemäßen Basissystems zur Codeumwandlung des Unicodes ist, welches eine Primärzeichenfolge empfängt und eine Zielzeichenfolge ausgibt;
Abb. 4 ein Blockdiagramm einer Ausführung eines Systems zur Codeumwandlung aus dem Unicode gemäß einer Ausführung der Erfindung ist;
Abb. 5 ein schematisches Diagramm einer bevorzugten Anordnung für eine Abbildungstabelle des Unicode-Codeumwandlungssystems ist;
Abb. 6A ein Verfahrensfließbild ist, welches von einem Anwendungsprogramm durchgeführt wird, welches das Unicode-Codeumwandlungssystem gemäß einer Ausführung der Erfindung benutzt;
Abb. 6B ein Fließbild der Abkürzungsverarbeitung in Übereinstimmung mit einer Ausführung der Erfindung ist;
Abb. 7 ein Fließbild der Unicodeumwandlungsverarbeitung gemäß einer Ausführung der Erfindung ist; ·
Abb. 8 ein Fließbild der Update-Offsets-Verarbeitung gemäß einer Ausführung der Erfindung ist;
die Abb. 9A und 9B Fließbilder der Verarbeitung des nächsten Textelementes gemäß einer Ausführung der Erfindung sind;
die Abb. 10A, 10B und 10C Fließbilder der Verarbeitung des nächsten Textelementes gemäß einer Ausführung der Erfindung sind;
Abb. 11 ein Blockdiagramm einer Abfrageeinrichtung gemäß einer Ausführung der Erfindung ist;
Abb. 12 ein schematisches Diagramm eines bevorzugten Formates für die in Abb. 10 gezeigte Attributetabelle ist;
Abb. 13 ein Fließbild der Verarbeitung zum Suchen von Attributen gemäß einer Ausführung der Erfindung ist;
die Abb. 14A und 14B schematische Diagramme sind, welche einer Abfragetabelle zugeordnet sind, die von der Abfrageeinrichtung benutzt wird, um die nächste Aktion gemäß einer Ausführung der Erfindung zu bestimmen;
Abb. 15 eine Tabelle ist, welche sowohl eine bevorzugte Gestaltung als auch die Informationen, welche in der Abfragetabelle gespeichert würden, gemäß einer bevorzugten Ausführung der Erfindung darstellt;
die Abb. 16A und 16B Tabellen sind, welche sowohl eine bevorzugte Gestaltung als auch die Informationen, welche in der Abfragetabelle gespeichert würden, gemäß einer bevorzugten Ausführung der Erfindung darstellen;
Abb. 17A ein Fließbild ist, welches die Verarbeitung zur Bestimmung der Richtung gemäß einer Ausführung der Erfindung illustriert;
die Abb. 17B-17D Tabellen sind, welche eine bevorzugte Gestaltung der Zustandstabellen für zwei Richtungen gemäß der Erfindung darstellen;
Abb. 18 ein Fließbild ist, welches die Verarbeitung zur Bestimmung der Anfangsrichtung gemäß einer Ausführung der Erfindung darstellt;
Abb. 19 ein Fließbild ist, welches die Verarbeitung zum Suchen eines Textelementes gemäß einer Ausführung der Erfindung darstellt;
Abb. 20 ein Fließbild ist, welches die Verarbeitung von Kettenformaten gemäß einer Ausführung der Erfindung darstellt;
Abb. 21 ein Fließbild ist, welches die Verarbeitung von Reihenformaten gemäß einer Ausführung der Erfindung darstellt;
Abb. 22 ein Fließbild ist, welches die Verarbeitung von Listenformaten gemäß einer Ausführung der Erfindung darstellt;
die Abb. 23A und 23B die Verarbeitung von Segmentdatenmengenformaten gemäß einer Ausführung der Erfindung illustrieren;
Abb. 24 ein Fließbild ist, welches die Verarbeitung für die Suchvariantenliste gemäß einer Ausführung der Erfindung darstellt;
die Abb. 25A und 25B schematische Diagramme von Tabellen und Datenformaten, welche der Variantenlistenverarbeitung zugeordnet sind, gemäß einer Ausführung der Erfindung sind;
die Abb. 26A, 26B und 26C Fließbilder sind, welche die Verarbeitung für die Zuordnung der Suchzielfolge zu der Ausgabesequenz gemäß einer Ausführung der Erfindung darstellt;
Abb. 27 ein Fließbild ist, welches die Verarbeitung der Ersatzhandhabung in Übereinstimmung mit der Erfindungsverarbeitung gemäß einer Ausführung der Erfindung illustriert;
Abb. 28 ein Fließbild ist, welches die Standardverarbeitung gemäß einer Ausführung der Erfindung illustriert; und
Abb. 29 ein Blockdiagramm einer Ausführung eines Systems zu Codeumwandlung in den Unicode gemäß einer Ausführung der Erfindung illustriert.

Beste Arten der Durchführung der Erfindung

Ausführungen der Erfindung werden hiernach unter Bezugnahme auf die Abb. 1-29 diskutiert. Fachleute werden jedoch leicht erkennen, daß die hier bezüglich dieser Abbildungen gegebene detaillierte Beschreibung nur als Beispiel dient, da sich die Erfindung über diese begrenzten Ausführungen hinaus erstreckt.
Ein Codeumwandlungssystem gemäß dem ersten Aspekt der Erfindung wandelt Primärzeichen in Zielzeichen mit einer anderen Codierung um. Die Erfindung betrifft ein Codeumwandlungssystem, welches Umlauftreue bietet, wobei es sicherstellt, daß die resultierenden Zeichencodes austauschbar mit anderen Plattformen sind. Das Codeumwandlungssystem ist in der Lage, ein einziges Primärzeichen oder eine Zeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Mit der Umlauftreue kann ein Primärtext in einen Zieltext umgewandelt und dann wieder zurück in den ursprünglichen Primärtext umgewandelt werden. Die Austauschbarkeit der resultierenden Zeichencodes mit anderen Plattformen wird sichergestellt, indem die Verwendung von Standard- Zielzeichen maximiert und die Verwendung von privaten Zeichen minimiert wird. Das Codeumwandlungssystem ist besonders nützlich für die Umwandlung in/aus den Unicodezeichen aus/in andere Zeichensätze. Die Zuordnung einer Folge von Unicode-Zeichen zu einem einzigen Zeichen in einem Zielzeichensatz war bis heute nicht durchführbar.
Das Codeumwandlungssystem kann ein Computersystem oder eine andere elektronische Vorrichtung zur Durchführung dieser Codeumwandlungsoperationen sein. Dieses Computersystem kann speziell für die erforderlichen Zwecke gebaut sein, oder es kann sich um einen Computer für allgemeine Zwecke handeln, welcher in Übereinstimmung mit einem Computerprogramm arbeitet. Die hier dargelegte Verarbeitung ist auf irgendein Computersystem oder irgendeine andere elektronische Vorrichtung anwendbar. Insbesondere können verschiedene Rechnervorrichtungen für allgemeine Zwecke mit Software benutzt werden, welche gemäß den hier dargelegten Lehren geschrieben ist, oder es kann passender sein, eine spezialisiertere elektronische Vorrichtung zu konstruieren, um die erforderlichen Operationen durchzuführen.
Ein Codeumwandlungssystem gemäß dem zweiten Aspekt der Erfindung berücksichtigt die Richtung bei der Umwandlung der Zeichen aus einer Primärzeichencodierung in eine Zielzeichencodierung. Das Codeumwandlungssystem ist in der Lage, ein einziges Primärzeichen oder eine Zeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Durch Bestimmung oder Auflösung der Richtung der sich in Umwandlung befindenden Zeichen kann das Codeumwandlungssystem dann die bestimmte oder aufgelöste Richtung der Zeichen verwenden, um sicherzustellen, daß die korrekte Zuordnung zu der Zielzeichencodierung erhalten wird. Somit wird mit der Erfindung eine korrekte Codeumwandlung erreicht, selbst wenn die Richtung der Zeichen innerhalb einer Primärzeichenfolge variiert.
Die Erfindung ist besonders nützlich, wenn auf Arabisch oder Hebräisch basierende Zeichensätze verwendet werden, da sie eine Ausrichtung von rechts nach links aufweisen. Die Erfindung liefert Flexibilität, um sowohl die eine oder die andere Richtung sowie die Fähigkeit, Richtungen mittendrin zu ändern, zu handhaben. Die Fähigkeit, Richtungen mittendrin zu ändern, ist wichtig in Fällen, wo Arabisch oder/und Hebräisch mit den anderen Zeichensätzen benutzt werden, welche die geläufigere Ausrichtung von links nach rechts aufweisen. Ein Beispiel für die Verwendung eines Zeichens mit unterschiedlichen Richtungen ist das Zwischenraumzeichen. In dem Unicode gibt es nur eine Codierung und sie hat keine inhärente Richtung. Auf der anderen Seite gibt es in MacArabisch verschiedene Zwischenraumzeichen mit einer Ausrichtung von links nach rechts und von rechts nach links.
Die Bestimmung oder Auflösung der Richtung der Primärzeichen, welche umgewandelt werden, wird mit einer Richtungsbestimmungstechnik erreicht, welche in Einzelheiten hiernach beschrieben ist unter Bezugnahme auf ein Codeumwandlungssystem, welches Primärzeichen in Zielzeichen aus einer anderen Codierung umwandelt.
Ein Codeumwandlungssystem gemäß dem dritten Aspekt der Erfindung berücksichtigt den Kontext bei der Umwandlung von Zeichen aus einer Primärzeichencodierung in eine Zielzeichencodierung. Das Codeumwandlungssystem ist in der Lage, ein einziges Primärzeichen oder eine Zeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Durch Bestimmung des Kontexts der Zeichen kann das Codeumwandlungssystem dann den bestimmten Kontext der Zeichen dazu verwenden sicherzustellen, daß die korrekte Zuordnung zu der Zielzeichencodierung verwendet wird. Somit wird mit der Erfindung eine korrekte Codeumwandlung selbst dann erreicht, wenn der Kontext der Zeichen die Zuordnung zu der Zielcodierung durchführt.
Bei bestimmten Zeichensätzen bewirkt der Kontext, in welchem die Zeichen verwendet werden, daß die Zeichen verschiedene Darstellungsformen aufweisen. Diese Darstellungsformen eines Zeichen sind Glyphen. Die unterschiedlichen Darstellungsformen erscheinen anders, wenn sie angezeigt werden. Der Kontext, in welchem das Zeichen benutzt wird, bestimmt die Darstellungsform. Arabisch ist eine Sprache mit Zeichen, welche abhängig von ihrem Kontext unterschiedliche Darstellungsformen aufweisen.
Arabische Schriftarten werden benutzt, um die arabische Sprache zu schreiben. Die arabische Schriftart ist Kursivschrift, sogar in ihrer gedruckten Form. Als Folge kann derselbe Buchstabe in unterschiedlichen Formen geschrieben werden, abhängig davon, wie er mit seinen Nachbarbuchstaben verbunden ist. Ein Beispiel für solch ein Zeichen ist der arabische Buchstabe "HEH" (Unicode-Zeichencodierung von u0647). Beispielsweise kann ein arabisches Zeichen einem von vier verschiedenen Darstellungsformen in DOS Arabisch abhängig von dem Kontext zugeordnet werden. Folglich bestimmt das erfindungsgemäße Umwandlungssystem den Kontext des arabischen Zeichens innerhalb des Unicode-Stromes, so daß die korrekte Abbildung erreicht werden kann.
Die Bestimmung des Kontexts der Primärzeichen, welche umgewandelt werden, wird mit der Kontextverarbeitung erreicht, welche hiernach in Einzelheiten unter Bezugnahme auf ein Codeumwandlungssystem beschrieben wird, welches Primärzeichen in Zielzeichen mit einer unterschiedlichen Codierung umwandelt.
Unter Bezugnahme auf den zweiten und dritten Aspekt der Erfindung wandelt das Codeumwandlungssystem Primärzeichen in Zielzeichen mit einer anderen Codierung um. Die Erfindung besteht aus einem Codeumwandlungssystem, welches Umlauftreue bietet, wobei sichergestellt wird, daß die resultierenden Zeichencodes austauschbar mit anderen Plattformen sind. Das Codeumwandlungssystem ist in der Lage, ein einziges Primärzeichen oder eine Zeichenfolge entweder einem einzigen Zielzeichen oder einer Zielzeichenfolge zuzuordnen. Durch die Umlauftreue kann ein Primärtext in einen Zieltext und dann zurück in den ursprünglichen Primärtext umgewandelt werden. Die Austauschbarkeit der resultierenden Zeichencodes mit anderen Plattformen wird sichergestellt, indem die Verwendung von Standard- Zielzeichen maximiert und die Verwendung von privaten Zeichen minimiert wird. Das Codeumwandlungssystem ist besonders nützlich für die Umwandlung in/aus den Unicodezeichen aus/in andere Zeichensätze. Die Zuordnung einer Folge von Unicode-Zeichen zu einem einzigen Zeichen in einem Zielzeichensatz war bis heute nicht durchführbar.
Das Codeumwandlungssystem kann ein Computersystem oder eine andere elektronische Vorrichtung zur Durchführung dieser Codeumwandlungsoperationen sein. Dieses Computersystem kann speziell für die erforderlichen Zwecke gebaut sein, oder es kann sich um einen Computer für allgemeine Zwecke handeln, welcher in Übereinstimmung mit einem Computerprogramm arbeitet. Die hier dargelegte Verarbeitung ist auf irgendein Computersystem oder irgendeine andere elektronische Vorrichtung anwendbar. Insbesondere können verschiedene Rechnervorrichtungen für allgemeine Zwecke mit Software benutzt werden, welche gemäß den hier dargelegten Lehren geschrieben ist, oder es kann passender sein, eine spezialisiertere elektronische Vorrichtung zu konstruieren, um die erforderlichen Operationen durchzuführen.
In dem vierten Aspekt der Erfindung stellt eine Abkürzungsverarbeirungstechnik sicher, daß eine zur Umwandlung empfangene Primärzeichenfolge akkurat in eine andere Zielzeichencodierung umgewandelt wird, selbst wenn die Primärzeichenfolge die Länge eines Eingabepuffers überschreitet, welcher die Primärzeichenfolge für die Umwandlung hält. Die Abkürzungsverarbeitungstechnik kürzt einen Teil der in dem Eingabepuffer gehaltenen Primärzeichenfolge ab, so daß der abgekürzte Teil in die Zielzeichencodierung umgewandelt werden kann, ohne von nachfolgenden Zeichen in der Primärzeichenfolge beeinflußt zu werden. Natürlich sollte der in dem Eingabepuffer nach der Abkürzung gehaltene Teil der Primärzeichenfolge (abgekürzter Teil) maximiert werden, so daß die Codeumwandlung wirksam durchgeführt werden kann.
Die erfindungsgemäße Abkürzungsverarbeitungstechnik wird in Einzelheiten hiernach unter Bezugnahme auf ein Codeumwandlungssystem beschrieben, welches Primärzeichen in Zielzeichen mit einer anderen Codierung umwandelt.
Abb. 1 ist ein Blockdiagramm eines repräsentativen Computersystems 100 in Übereinstimmung mit der vorliegenden Erfindung. Das Computersystem 100 umfaßt eine zentrale Datenverarbeitungseinheit (CPU) 102, wobei die CPU in zwei Richtungen an einen Random- Access-Speicher (RAM) 104 und in einer Richtung an einen Nurlesespeicher (ROM) 106 angeschlossen ist. Typischerweise beinhaltet der RAM 104 Programmieranweisungen und Daten, einschließlich Tabellen, wie hier beschrieben, zusätzlich zu anderen Daten und Anweisungen für laufend auf der CPU 102 operierende Verfahren. Der ROM 106 beinhaltet typischerweise Basisbetriebsanweisungen, Daten und Programmabläufe, welche von dem Computersystem I00 verwendet werden, um seine Aktionen zu erfüllen. Zusätzlich ist eine Massenspeichervorrichtung 108, wie eine Harddisk, eine CD-ROM, ein magnetooptischer (floptischer) Treiber, ein Laufwerk oder dergleichen in zwei Richtungen mit der CPU 102 verbunden. Die Massenspeichervorrichtung 108 beinhaltet allgemein zusätzliche Programmieranweisungen, Daten und Textprogrammabläufe, welche typischerweise nicht aktiv von der CPU benutzt werden, obwohl von der CPU auf den Adressenraum Zugriff genommen werden kann, z. B. als virtuellem Speicher oder dergleichen. Jeder der oben beschriebenen Computer beinhaltet ferner eine Eingabe-/Ausgabequelle 110, welche typischerweise Eingabemedien wie eine Tastatur, Markierungsvorrichtungen (z. B. Maus oder Schreiber) und dergleichen umfaßt. Das Computersystem 100 kann auch eine Netzwerkverbindung 112 umfassen, über welche Daten und Anweisungen übertragen werden können. Zusätzliche Massenspeichervorrichtungen (nicht gezeigt) können auch durch die Netzwerkverbindung 112 an die CPU 102 angeschlos sen sein. Das Computersystem 100 umfaßt ferner einen Anzeigebildschirm 114 zur Anzeige von Texten und Bildern, welche von dem Computersystem 100 erzeugt oder angezeigt werden.
Die CPU 102 arbeitet zusammen mit einem Betriebssystem (nicht gezeigt), um einen Computercode einzurichten. Der Computercode kann auf dem RAM 104, dem ROM 106 oder einer Massenspeichervorrichtung 108 gespeichert sein. Der Computercode kann auch auf einem tragbaren Programm-Medium 116 gespeichert sein und dann in das Computersystem 100 bei Bedarf geladen oder auf ihm installiert werden. Tragbare Programm-Medien 116 umfassen beispielsweise CD-ROMs, PC-Karten-Vorrichtungen, RAM-Vorrichtungen, Floppy-Disks, Magnetbänder.

1. Definitionen

1. Codepunkt: Ein Codepunkt ist ein Bit-Muster in einer bestimmten Codierung. Gewöhnlich ist das Bit-Muster ein oder mehrere Bytes Lang. Ein Unicode-Codepunkt beträgt immer 16 Bits oder zwei Bytes.
2. Codierung: Eine Codierung ist eine Eins-zu-eins-Zuordnung eines Zeichensatzes zu einem Satz Codepunkte. Beispielsweise ordnet die ASCII-Codierung einen Satz, welcher a-z, A-Z und 0-9 umfaßt; den Codepunkten x00 bis x7F zu.
3. Textelement: Ein Textelement ist eine Folge von einem oder mehreren Codepunkten, welche für einen bestimmten Vorgang als eine Einheit behandelt werden. Beispielsweise ist der Lateinische Großbuchstabe U gefolgt von einem zwischenraumlosen Trema ein Textelement (z. B. zwei angrenzende Zeichen in diesem Beispiel) für den Codeumwandlungsvorgang gemäß der Erfindung.
4. Glyphen: Eine angezeigte Form, welche die visuelle Darstellung eines Zeichens liefert. Beispielsweise sind ein kursives "a" und ein römisches "a" zwei verschiedene Glyphen, welche dasselbe zugrundeliegende Zeichen darstellen.
5. Darstellungsform: Eine Darstellungsform ist eine Glyphe, welche ihre visuelle Form abhängig von dem Kontext ändert. Einige Codierungen bilden nur abstrakte Zeichen, welche unabhängig von dem Kontext sind, ab, während andere Codierungen nur Darstellungsformen abbilden. Beispielsweise ist ein Doppelbuchstabe wie "fi" eine Darstellungsform für die Zeichenfolge aus dem Lateinischen Großbuchstaben F gefolgt von dem Lateinischen Großbuchstaben I.
6. Ersatz: Ein Ersatz ist eine Folge von einem oder mehreren Codepunkten in der Zielcodierung, welche nicht genau äquivalent zu den Primärcodepunkten sind, welche aber einige der Informationen des Originals bewahren. Beispielsweise ist (C) ein möglicher Ersatz für .
7. Standard: Ein Standard ist eine Folge von einem oder mehreren Codepunkten in der Zielcodierung, welche verwendet werden, wenn nichts in der Zielcodierung nicht einmal den Primärcodepunkten ähnelt.

II. Unicode-Umwandler

Die allgemeine Umwandlungstechnik gemäß der Erfindung wandelt Primärzeichen in Zielzeichen mit einer anderen Codierung um. Vorzugsweise sind entweder die Primärzeichen oder die Zielzeichen Unicode-Zeichen.
Der Unicode-Standard ist eine Ansammlung von Zeichencodierungen, welche zu einem einzigen, universellen, internationalen Zeichencodierungsstandard zusammengefaßt wurden. Abb. 2 illustriert das Format der Unicodezeichencodierungen. Insbesondere liefert der Unicode- Standard Codes, welche 16 Bits groß sind, wie von einem in Abb. 2 gezeigten Format 200 illustriert ist. Innerhalb dieses Dokumentes sind Unicode-Zeichen in hexadezimaler Form mit einem vorausgehenden u (z. B. u0041) dargestellt, und Zeichen in anderen Codierungen sind in hexadezimaler Form mit einem vorausgehenden x (z. B. x41 für ein 1-Byte-Zeichen, x8140 für ein 2-Byte-Zeichen) dargestellt.
Abb. 3 illustriert ein Blockdiagramm eines erfindungsgemäßen Basissystems zur Unicode- Codeumwandlung 300, welches eine Primärzeichenfolge 302 empfängt und eine Zielzeichenfolge 304 ausgibt. Das Unicode-Codeumwandlungssystem 300 wandelt Zeichen der Primärzeichenfolge 302 in ein oder mehrere Zeichen in dem Zielstrom um, welche eine andere Zeichencodierung aufweisen als die in der Primärzeichenfolge verwendete Codierung. Vorzugsweise wandelt das Unicode-Codeumwandlungssystem 300 aus dem Unicode in eine andere Zielcodierung (Aus-Unicode) um, oder es wandelt aus einer anderen Primärcodierung um (In-Unicode).
Abb. 4 illustriert ein Blockdiagramm einer Ausführung eines Unicode- Codeumwandlungssystems 400 gemäß der Erfindung. Die Abkürzungsvorrichtung 407 und der Puffer 405 liegen in dem vierten Aspekt der Erfindung vor und betreffen diesen, aber sie müssen nicht unbedingt in dem ersten, zweiten oder dritten Aspekt vorliegen und diese betreffen.
Bezüglich des ersten, zweiten und dritten Aspektes der Erfindung umfaßt ein Unicode- Codeumwandlungssystem 400 einen Aus-Unicode-Umwandler 402, welcher eine Unicodezeichenfolge 404 empfängt und eine Zielzeichenfolge 40fi erzeugt. Der Aus-Unicode- Umwandler 402 führt die Codeumwandlung in Übereinstimmung mit der Erfindung durch. Dabei wirkt der Aus-Unicode-Umwandler 402 mit einer Abfrageeinrichtung 408 zusammen. Die Abfrageeinrichtung 408 fragt in Verbindung mit einer Abfragetabelle 410 die Unicodezeichenfolge 404 ab, um ein Textelement zu identifizieren. Der Aus-Unicodeumwandler 402 benutzt dann eine Suchvorrichtung 412, um das eine oder mehrere Zeichen in der Zielcodierung für das von der Abfrageeinrichtung 408 identifizierte Textelement zu suchen. Die Suchvorrichtung 412 verwendet eine Abbildungstabelle 414, um das eine oder mehrere Zeichen in der Zielcodierung für das Textelement zu erhalten.
Zusätzlich kann der Aus-Unicode-Umwandler 402 auch eine Ersatzvorrichtung 416 verwenden. Die Ersatzvorrichtung 416 arbeitet zusammen mit der Abbildungstabelle 414, um ein oder mehrere Zeichen in der Zielcodierung zu identifizieren, welche als eine Ersatzabbildung für das Textelement in Fällen verwendet werden können, wo die Suchvorrichtung 412 nicht in der Lage war, ein oder mehrere Zeichen in der Zielcodierung für das Textelement zu identifizieren. Eine Zustandsverwaltungsvorrichtung 418 hält oder speichert Informationen über den laufenden Zustand der Umwandlung. Diese Informationen können beispielsweise den Kontext, die Richtung und den Zustand des symmetrischen Memory-Swappings beinhalten.
Bezüglich des vierten Aspekts der Erfindung umfaßt ein Unicode-Codeumwandlungssystem 400 einen Aus-Unicode-Umwandler 402, welcher eine Unicode-Zeichenfolge 404 empfängt und eine Zielzeichenfolge 406 erzeugt. Die Unicode-Zeichenfolge wird in einem Puffer 405 gespeichert. Eine Abkürzungsvorrichtung 407 ist vorgesehen, um die Länge der in dem Puffer 405 gespeicherten Unicode-Zeichenfolge 404 abzukürzen, so daß eine akkurate Umwandlung sichergestellt wird.
Der Aus-Unicode-Umwandler 402 steuert das gesamte Verfahren der Codeumwandlung. Dabei wirkt der Aus-Unicode-Umwandler 402 mit einer Abfrageeinrichtung 408 zusammen. Die Abfrageeinrichtung 408 fragt in Verbindung mit einer Abfragetabelle 410 die abgekürzte Unicode-Zeichenfolge 404 (geliefert von der Abkürzungsvorrichtung 407) ab, um ein Textelement zu identifizieren. Der Aus-Unicode-Umwandler 402 verwendet dann eine Suchvorrichtung 412, um das eine oder mehrere Zeichen in der Zielcodierung für das von der Abfrageeinrichtung 408 identifizierte Textelement zu suchen. Die Suchvorrichtung 412 benutzt eine Abbildungstabelle 414, um das eine oder mehrere Zeichen in der Zielcodierung für das Textelement zu erhalten. Zusätzlich kann der Aus-Unicode-Umwandler 402 auch eine Ersatzvorrichtung 416 verwenden. Die Ersatzvorrichtung 416 arbeitet zusammen mit der Abbildungstabelle 414, um ein oder mehrere Zeichen in der Zielcodierung zu identifizieren, welche als eine Ersatzabbildung für das Textelement in Fällen verwendet werden können, wo die Suchvorrichtung 412 nicht in der Lage war, ein oder mehrere Zeichen in der Zielcodierung für das Textelement zu identifizieren. Eine Zustandsverwaltungsvorrichtung 418 hält oder speichert Informationen über den laufenden Zustand der Umwandlung. Diese Informationen können beispielsweise den Kontext, die Richtung und den Zustand des symmetrischen Memory- Swappings beinhalten. Solche Informationen werden benötigt für eine nicht durch Blöcke begrenzte Umwandlung, bei welcher die abgekürzte Unicode-Zeichenfolge nicht am Ende eines Blockes endet. In solch einem Fall liefert das Codeumwandlungsverfahren durch Speichern von Informationen über den laufenden Zustand der Umwandlung korrekte Codeumwandlungen, selbst wenn die Eingabezeichenfolge 404 größer als die Kapazität des Puffers 405 ist.

A. Abfrageeinrichtung und Abfragetabelle

In Verbindung mit der Abfragetabelle 410 fragt die Abfrageeinrichtung 408 die Unicodezeichenfolge 404 ab und läßt das nächste Textelement und irgendwelche zusätzlichen Informationen, welche von der Suchvorrichtung 412 benötigt werden, rückspringen. Die zusätzlichen Informationen umfassen eine oder mehrere Richtungsinformationen, Kontextinformationen und verschiedene Zustandsanzeigen. Die allgemeine Funktionsweise der Abfrageeinrichtung 408 ist die Folgende: Die Abfrageeinrichtung 408 fragt die Zeichen der Eingabe-Unicode-Zeichenfolge 404 ab. Wenn Richtungsinformationen für die Zielcodierung benötigt werden, wird dann die Zeichenrichtung für jedes Zeichen in dem Textelement erhalten. Auch wenn Zeichenkontextinformationen für die Zielcodierung benötigt werden, werden Zeichenkontextinformationen für jedes Zeichen in dem Textelement erhalten. Dann, wenn die Abfrageeinrichtung 408 jedes der Zeichen abfragt, führt die Abfrageeinrichtung 408 einen Vorgang für das Zeichen in Übereinstimmung mit den in der Abfragetabelle 410 vorliegenden Informationen durch. Der bestimmte Vorgang, den die Abfrageeinrichtung 408 durchführt, ist basierend auf dem Zustand und der Zeichenklasse bestimmt. Die Vorgänge, welche die Abfrageeinrichtung 408 durchführen kann, umfassen: Markieren des laufenden Zeichens, Setzen oder Löschen des symmetrischen Swapping-Bits, Festhalten der Kontextform eines Textelementes, Setzen eines Merkers, welcher anzeigt, daß das Textelement neu geordnet werden muß, und Anzeigen des Endes des Textelementes. Das symmetrische Swapping-Bit, der Kontext und die Richtung werden von der Zustandsverwaltungsvorrichtung 418 als zu dem Zustand der Abfrageeinrichtung gehörende Information gespeichert. Vor dem Rückspringen speichert die Abfrageeinrichtung 408 Kontextinformationen für das Textelement. Die Abfrageeinrichtung 408 läßt das Textelement (jedes Textelement innerhalb der Eingabezeichenfolge) und seine Attribute rückspringen. Die Attribute umfassen die folgenden Elemente: Richtung, Klasse, Priorität symmetrischer Swappingzustand, Teilsatz und Kontext. Nachdem die Abfrageeinrichtung 408 ein Textelement bestimmt hat, müssen die Zeichen möglicherweise in kanonischer Reihenfolge neu geordnet werden. Als ein Beispiel wird das Neuordnen der Zeichen innerhalb eines Textelementes dann durchgeführt, wenn das Textelement zwischenraumlose Zeichen umfaßt, welche nicht in kanonischer Reihenfolge, wie von dem Unicode definiert, vorliegen.
Vorzugsweise werden die Abfrageeinrichtung 408 zusammen mit der Abfragetabelle 410 als ein Paar Zustandsmodule implementiert, welche parallel zueinander arbeiten. Ein erstes Zustandsmodul löst die Zeichenrichtung auf, und ein zweites Zustandsmodul berechnet Textelemente und Zeichenformkontextinformationen, wo verwendbar, und speichert auch den symmetrischen Swapping-Zustand. Durch Verwendung von zwei getrennten Zustandsmodulen ist das Unicode-Codeumwandlungssystem 400 einfacher zu gestalten und zu warten. Das erste und zweite Zustandsmodul können als zweidimensionale Datenmengen (oder Tabellen) implementiert werden, welche durch Zustand und Klasse indiziert sind. In den Fällen, wo der Vorgang, welchen die Abfrageeinrichtung 408 durchzuführen hat, von der Zeichenrichtung abhängt, ist der Zustandsmoduleingang ein Index in eine andere Tabelle, welche den geeigneten Vorgang enthält, den die Abfrageeinrichtung 408 für jede Richtung durchzuführen hat.
Die Aktion der Abfrageeinrichtung 408 besteht darin, die Eingabe-Unicode-Zeichenfolge 404 in Textelemente umzuwandeln und die Textelemente und ihre Attribute rückspringen zu lassen. Die Abfrageeinrichtung 408 muß bestimmte Eigenschaften des Textelementes speichern, so daß es korrekt in die Zielcodierung umgewandelt werden kann. Die Eigenschaften umfassen nämlich die Richtung, den Kontext und den symmetrischen Swapping-Zustand. Die Abfrageeinrichtung muß jedoch nicht wissen, was die Zielcodierung ist, da ihre Funktionsweise unabhängig von der bestimmten Zielcodierung ist. Nichtsdestotrotz wird das Unicode-Umwandlungssystem 400 vorzugsweise derart implementiert, daß die Definition eines Textelementes (d. h. das Blockbildungsverhalten) einfach durch Veränderung der Abfragetabelle 410 mit der Zielcodierung variieren kann.
Die Richtungseigenschaft von Zeichen wird verwendet für die Darstellung der Zeichen. Wenn beispielsweise Arabisch oder Hebräisch auf einem Anzeigebildschirm angezeigt werden, sind sie von rechts nach links geordnet. Die meisten Unicode-Zeichen weisen eine implizite Richtung auf, siehe Unicode-Version 1.0 auf S. 407 (Abschnitt 4.6) und S. 611 (Anhang A). Die mit dem Unicode-Standard bereitgestellten impliziten Richtungsklassen und ihre Werte umfassen: Links- Rechts (Left-Right) (0), Rechts-Links (Right-Left) (1), Europäisclhe Zahl (European Number) (2), Europäischer Zahlseparator (European Number Separator) (3), Europäischer Zahlterminator (European Number Terminator) (4), Arabische Zahl (Arabic Number) (5), Gemeinsamer Zahlseparator (Common Number Separator) (6), Blockseparator (Block Separator) (7), Segmentseparator (Segment Separator) (8), Leerraum (Whitespace) (9) und Andere Leerzeichen (Other Neutrals) (10). Die Abfrageeinrichtung 408 sucht die Richtungsklasse für Zeichen des Textelementes. Die Richtungsklasse wird dann verwendet, um die Richtung des Textelementes aufzulösen. Es gibt auch spezielle Unicode-Zeichen, welche eine Überlagerung oder Integrierung der Richtungseigenschaft bewirken. Diese speziellen Richtungs-Unicode-Zeichen werden von der Abfrageeinrichtung 408 als Textelemente mit einzelnem Zeichen behandelt.
Es gibt einige Basisregeln, welche die Abfrageeinrichtung 408 bei der Bildung der Textelemente befolgt. Die Basisregel ist, daß wenn keine der Regeln anzuwenden ist, das Textelement ein einzelnes Unicode-Zeichen ist. Eine weitere Regel ist, daß zwischenraumlose Zeichen oder Kombinationszeichen, welche einem Basiszeichen folgen, mit dem Basiszeichen als ein einziges Textelement zusammengefaßt werden. Noch eine andere Regel ist, daß Zeichen, welche Symbolen zugeordnet sind (z. B. Koreanische Hangul-Jamos-Zeichen), wobei man auf Doppelbuchstaben oder Ideogramme trifft, zu Textelementen kombiniert werden. Noch eine weitere Regel ist, daß wenn ein Bruchstrich auf jeder Seite von einer Folge von einem oder mehreren Dezimalziffern umgeben ist, sie als ein numerisches Bruchtextelement kombiniert werden.
Die Regel für zwischenraumlose Zeichen oder Kombinationszeichen wird jetzt in größeren Einzelheiten erklärt. Gemäß dem Unicode-Standard folgen zwischenraumlose Zeichen dem Basiszeichen. Somit werden die zwischenraumlosen Zeichen, welche einem Basiszeichen folgen, Teil des Textelementes, welches das Basiszeichen beinhaltet. Siehe "The Unicode Standard", Version 1.0, auf S. 403 (Abschnitt 4.5). Wenn beispielsweise einem einzelnen zwischenraumlosen Zeichen ein Zeichen folgt, welches kein zwischenraumloses Zeichen ist, wird das zwischenraumlose Zeichen mit dem vorherigen Zeichen zu einem Textelement kombiniert. Die Länge des Textelementes beträgt dann zwei und die Attribute für das Textelement werden von dem Basiszeichen definiert. Wenn es kein vorausgehendes Zeichen gibt, wird das zwischenraumlose Zeichen einfach als ein einzelnes Textelement weitergeführt. Mehrfache zwischenraumlose Zeichen können auch auf diese Weise kombiniert werden.
Die Regel für koreanische Hangul-Jamos-Zeichen wird jetzt in größeren Einzelheiten erklärt. Jedes Hangul-Zeichen hat einen impliziten Wert, welcher zu einer der Klassen gehört: Choseong (Anfang), Jungseong (Mitte) oder Jongseong (Ende). Der Unicode-Standard, Version 1.1 (Abschnitt 5) listet die Codes und die zulässigen Kombinationen für diese Zeichen auf. Die Abifageeinrichtung 408 gruppiert die koreanischen Jamoszeichen gemäß den zulässigen Kombinationen für diese Zeichen. Für Eingabekombinationen, welche nicht zulässig sind, läßt die Abfrageeinrichtung 408 das Zeichen als ein einziges Textelement rückspringen. Wie zuvor wird, wenn einer Hangul-Silbe ein Kombinationszeichen folgt, das Kombinationszeichen in das Textelement für die Hangulsilbe eingefügt.
Die Regel für Bruchstriche wird jetzt in größeren Einzelheiten erklärt. Die Abfrageeinrichtung 408 behandelt zu Anfang jedes Zeichen für Bruchstrichzahlen, als ob sie einzelne Zeichentextelemente wären. Trifft man jedoch auf eine vollständige Bruchstrichfolge, fügt die Abfrageeinrichtung 408 die der Folge zugeordneten Zeichen zu einem einzigen Textelement zusammen. Wenn eine Ziffer mit einem Kombinationszeichen gefunden wird, können die Ziffer und das Kombinationszeichen nicht Teil eines Bruchstriches sein, aber die Ziffer und das Kombinationszeichen können zusammen ein Textelement bilden.
Außer bei zwischenraumlosen Zeichen, werden alle arabischen Zeichen durch die Abfrageeinrichtung 408 als einzelne Textelemente geleitet. Die arabischen formbildenden Zustandszeichen werden auch als einzelne Textelemente durch die Abfrageeinrichtung geführt. Die richtungsgebenden Formatierungscodes werden durch die Abfrageeinrichtung 408 als einzelne Textelemente geleitet.

B. Suchvorrichtung, Abbildungstabellen und Ersatzvorrichtung

Die Abbildungstabelle 414 wird von der Suchvorrichtung 412 benutzt, um eine Eingabefolge von einem oder mehreren Unicode-Zeichen einer Ausgabefolge von einem oder mehreren Zeichen in der Zielcodierung zuzuordnen. Zusätzlich zu der Unicodefolge (d. h. Textelement) selbst, sind bestimmte zusätzliche Informationsteile über die Eingabefolge erhältlich (z. B. Richtung, Kontext, symmetrischer Swappingzustand, vertikale Formanforderungen, Ersatzerfordernisse, Toleranz, Variante) und einige Tabellen verwenden diese Informationen. Vorzugsweise speichert die Abbildungstabelle 414 auch Daten, welche von der Ersatzvorrichtung 416 benötigt werden, obwohl eine separate Tabelle zur Benutzung von der Ersatzvorrichtung 416 vorgesehen werden könnte.
Abb. 5 ist ein schematisches Diagramm einer bevorzugten Anordnung für die Abbildungstabelle 414 des Unicode-Codeumwandlungssystems 400. Die Abbildungstabelle 414 umfaßt vorzugsweise einen Kopfzeilenbereich 500 und dann Datensegmente innerhalb der Abbildungstabelle, welche basierend auf der Anzahl von Zeichen in dem Textelement eingeteilt sind. Der Inhalt des Kopfreilenbereiches 500 ist in Einzelheiten unten diskutiert. Die in Abbildung S illustrierte Abbildungstabelle 414 weist Codierungen für Textelemente mit einem bis N Zeichen auf. Wenn die Suchvorrichtung 412 die Abbildungstabelle 414 nach Zielcodierungen für Textelemente mit einem Zeichen absucht, wird das Segment 502 der Abbildungstabelle 414 benutzt. Wenn das Textelement zwei Zeichen groß ist, wird dann ähnlich das Segment 504 benutzt, und wenn das Textelement N Zeichen groß wäre, würde das Segment 506 benutzt. Obwohl die Abb. 4 und 5 eine einzige Abbildungstabelle 414 illustrieren, benutzt das Unicode-Codeumwandlungssystem 400 eine Vielzahl von verschiedenen Abbildungstabellen 414, nämlich eine Abbildungstabelle für jeden Zielzeichensatz. Jede Abbildungstabelle beinhaltet mehrfache Untertabellen.
Die Abbildungstabellen 414 sind mit Größen- und Gesamtumwandlungsgeschwindigkeitsanforderungen gestaltet, welche bekannt sind. Die Abbildungstabellen 414 sollten so klein wie möglich sein, ohne die Suchzeit stark zu beeinträchtigen, und die Suchzeit sollte so schnell wie möglich sein, ohne die Tabellengröße erheblich zu vergrößern. Das Unicode- Codeumwandlungssystem 400 unterstützt vielfache Tabellenformate, so daß verschiedene Formate für jede Untertabelle möglich sind, wodurch es möglich wird, daß ein Geschwindigkeits-/Größenkompromiß für eine bestimmte Tabelle gemäß dem Bedarf einzustellen ist. Vorzugsweise sollte die Gestaltung der Abbildungstabelle 414 die Zuordnung von einem einzigen Unicode-Zeichen zu einem einzigen Zeichen in der Zielcodierung so schnell wie möglich machen, da dies der geläufigste Fall ist.
Die Gestaltung der Abbildungstabelle 414 ist derart, daß die Tabellen wenigstens einige der Erfordernisse der Ersatzvorrichtung 416 unterstützen, vielfache Abbildungstoleranzen unterstützen und vielfache Zielzeichensatzvarianten unterstützen. Das Tabellenformat ist auch in der Lage, Unicodefolgen mit einem oder mehreren Zeichen einer Ausgabefolge von null oder mehr Zeichen zuzuordnen. Die Abbildungstabellen 414 können auch mehrere mögliche Ausgabefolgen für eine einzige Eingabefolge spezifizieren, wobei die bestimmte Ausgabefolge von Attributen wie Richtung, Kontext und symmetrischem Swappingzustand bestimmt wird. Bezüglich des dritten Aspekts der Erfindung liegt der Schwerpunkt auf der Auswahl einer bestimmten Ausgabefolge basierend auf dem Kontext. Die Abbildungstabellen können auch leicht ausgeweitet werden, um die Anpassung an Benutzerwünsche bezüglich des Codierungsverhaltens des Unicode-Codeumwandlungssystems 400 zu erleichtern.
Die von den Abbildungstabellen 414 benötigten Informationen umfassen die folgenden Elemente: das Textelement von der Abfrageeinrichtung 408 (d. h. die Eingabefolge der umzuwandelnden Zeichen, mit allen Kombinationszeichen in kanonischer Reihenfolge); ob vertikale Formen anstatt horizontaler Formen verwendet werden sollen, wo verfügbar; die aufgelöste Richtung des Textelementes; die Kontextinformation bezüglich der Zeichenform für das Textelement (Anfang, Mitte, Ende oder isoliert); den laufenden Zustand des symmetrischen Swappings (aktiviert oder unterdrückt); Informationen über das aufzurufende Suchniveau (Toleranzniveau (genau oder locker) und Ersatz (an oder aus)); und eine Identifiziervorrichtung für eine bestimmte Codierungsvariante (eine Variantenidentifikation). Die Information über das Suchniveau wird von einem Abruf oder einem Anwendungsprogramm geliefert, welche das Unicode-Codeumwandlungssystem 400 abruft. In einem Sprach- oder Zeichensatz, bei welchem die Richtung und der Kontext unwichtig sind, werden die aufgelöste Richtung und die Kontextinformation nicht benötigt.
Die Definition von Varianten, die aktuellen Zuordnungen von Unicodefolgen zu Zielfolgen und die Tabellenformate, welche verwendet werden, um Zugang zu ihnen zu haben, sind durch die Gestaltung der Abbildungstabelle 414 veränderbar. Somit sind die Genauigkeit und, bis zu einem gewissen Grad, die Leistungs-/Größenkompromisse stark abhängig von der Gestaltung der Abbildungstabellen 414. Es ist vorzuziehen, daß die Abbildungstabellen 414 genaue und lockere Zuordnungen, Ersatzzuordnungen und Standardzuordnungen unterstützen.
Genaue Zuordnungen sind Codeumwandlungen, bei welchen die Umlauftreue garantiert ist. Genaue Zuordnungen von Unicode zu einem Zielzeichensatz sind reziprok zu den Unicodezuordnungen von diesem Zeichensatz zu dem Unicode. Lockere Zuordnungen von Unicode zu dem Zielzeichensatz sind zusätzliche Zuordnungen, welche in den Bereich der Definition oder eingerichteten Verwendung für die Zeichen in dem Zielzeichensatz fallen. Lockere Zuordnungen erscheinen korrekt abgebildet, weisen aber eine gewisse Zweideutigkeit auf Beispielsweise kann in vielen Zeichensätzen ein einzelnes Zeichen vielfache semantische Bedeutungen entweder durch explizite Definition, zweideutige Definition oder eingerichtete Verwendung aufweisen. Beispielsweise ist das Shift-JIS-Zeichen x8161 so spezifiziert, daß es zwei Bedeutungen hat: "doppelte vertikale Linie" und "parallel". Jede dieser Bedeutungen entspricht einem anderen Unicode-Zeichen: u2016 "doppelte vertikale Linie" und u2225 "parallel zu". Bei der Zuordnung von Shift-JIS zu Unicode muß das Codeumwandlungssystem eines dieser Unicode-Zeichen auswählen, beispielsweise "doppelte vertikale Linie". Bei der Abbildung aus dem Unicode in Shift-JIS kann - und sollte normalerweise - das Codeumwandlungssystem beide Unicode-Zeichen demselben Shift-JIS-Zeichen zuordnen. Jedoch ist nur eine dieser Aus-Unicode-Zuordnungen reziprok zu der In-Unicode-Zuordnung.
Genaue gegenüber lockeren Zuordnungsbeispielen:
- Wenn Unicode u000D genau ASCII xOD "Wagenrücklauf" zugeordnet wird, dann kann Unicode u2029 "ABSATZTRENNUNG" locker ASCII xOD zugeordnet werden.
- Wenn Unicode u002D "MINUS-BINDESTRICH" genau ASCTf x2D "Minus-Bindestrich" zugeordnet wird, dann können die Unicodes u2010 "BINDESTRICH" und u2212 "MINUSZEICHEN" locker ASCII x2D zugeordnet werden.
- Wenn Unicode 00EO "LATEINISCHER KLEINBUCHSTABE. A MIT ACCENT GRAVE" genau ISO 8859-1 ff0 "Kleinbuchstabe a mit Accent grave" zugeordnet wird, dann kann die Zwei-Zeichen-Unicodefolge u0061+0300 "LATEINISCHER KLEINBUCHSTABE A" + "KOMBINATIONS-ACCENT GRAVE" locker ISO 8859-1xEO zugeordnet werden.
- Da Shift-JIS halbbreite und vollbreite Zeichen unterschiedet, müssen lockere Zuordnungen für Shift-JIS auch diese Unterscheidungen einhalten. Unicode uFF40 "VOLLBREITER ACCENT GRAVE" wird genau Shift-JIS x814D "Accent grave [vollbreit]" zugeordnet, welcher sich von Shift-JIS x60 "Accent grave [halbbreit]" unterscheidet. Die Unicode-Folge u3000 + u0300 "aEOGRAMM-LEERZEICHEN" + "KOMBINATIONS-ACCENT GRAVE" kann locker Shift-JIS x814D zugeordnet werden. Jedoch sollte die Unicode-Folge u0020 + u0300 "LEERZEICHEN" + "KOMBINATIONS-ACCENT GRAVE" nicht locker Shift-JIS x814D zugeordnet werden; stattdessen sollte sie locker Shift-JIS x60 zugeordnet werden.
Bezüglich des ersten Aspekts der Erfindung ist die Umlauf-Zuordnung von Unicode zu einem anderen Zeichensatz und wieder zurück möglich, wenn nur Unicode-Zeichen verwendet werden, für welche genaue Zuordnungen zu dem anderen Zeichensatz existieren.
Ferner sind bezüglich des ersten bis zum vierten Aspekts der Erfindung Ersatzzuordnungen Zuordnungen aus dem Unicode, welche die Bedeutung oder Identität des Unicode-Zeichens nicht bewahren. Dies bedeutet, daß sie ein Unicode-Zeichen (oder eine Zeichenfolge) einem Zeichen (oder einer Folge) in dem Zielsatz zuordnen, dessen Definition oder Verwendung nicht die Bedeutung oder Verwendung des Unicode-Zeichens umfaßt. Nichtsdestotrotz liefert die Ersatzzuordnung, falls verfügbar, ein Zeichen (oder eine Folge) in der Zielcodierung, welches am nächsten dem Unicode-Zeichen (oder der Zeichenfolge) entspricht.

Ersatzzuordnungsbeispiele:

- Das Unicodezeichen u0300 "KOMBINATIONS-ACCENT GRAVE" kann ASCII x60 "Accent grave [Zwischenraum] als eine Ersatzzuordnung zugeordnet werden. Der Unterschied liegt darin, daß das Unicode-Zeichen ein Kombinationszeichen (zwischenraumlos) ist, wohingegen das ASCII-Zeichen ein Zwischenraumzeichen ist.
- Das Unicode-Zeichen u01CO "LATEINISCHER BUCHSTABEN-GEDANKENSTRICH" könnte ASCII x7C "vertikale Linie" als eine Ersatzzuordnung zugeordnet werden.
- Das Unicode-Zeichen u2001 "EM QUAD" könnte ASCII x20 "Leerzeichen" als eine Ersatzzuordnung zugeordnet werden.
Somit werden, wie in den oben stehenden Beispielen illustriert, Ersatzzuordnungen benutzt, um ein Zielzeichen (oder eine Folge) zu erzeugen, welches die graphische Annäherung an das Unicode-Zeichen (oder die Folge) ist.
Aus Leistungsgründen (d. h. die Geschwindigkeit, mit welcher die Codierung aus der Abbildungstabelle erhalten werden kann) gibt es mehrere mögliche Formate zur Indizierung in der Abbildungstabelle 414. Die möglichen Formate umfassen ein Segmentformat, ein Listenformat, ein Reihenformat oder ein Kettenformat. Separate Indices werden vorzugsweise für Zeichenfolgen mit unterschiedlichen Längen vorgesehen. Als Folge kann der Index, welcher jeder der Zeichenfolgen 502, 504, 506 zugeordnet ist, in einem anderen Format vorliegen, und Informationen am Anfang jedes Indexes spezifizieren sein Format. Unabhängig von dem Format ordnet jeder Index zuletzt eine Eingabefolge entweder direkt einer Ausgabefolge, oder, wenn die Ausgabefolge lang ist, einer Abweichung (offset) zu, welche die Stelle der entsprechenden Ausgabefolge spezifiziert.
Das Kettenformat zur Indizierung in der Abbildungstabelle 414 steht für die weitere Diskussion. Bei dem Kettenformat wird der Anfang des Abschnitts überprüft, um zu bestimmen, ob es sich um eine Kettenkopfzeile für eine Kettenformattabelle oder irgendein anderes Format handelt. Das Kettenformat spezifiziert eine Kette von vielfachen Indextabellen, wobei jede möglicherweise in einem anderen Format vorliegt. Wenn die gewünschte Abbildung in der ersten Indextabelle nicht gefunden wurde, überprüft die Suchvorrichtung 412 die zweite usw. Das Kettenformat ist beispielsweise nützlich, wenn ein Indexformat (welches wirksam in Raum und/oder Zeit ist) die meisten, aber nicht alle der Eingabefolgen zuordnen kann, während ein anderes, weniger wirksames Indexformat die wenigen übrigen Folgen verarbeiten kann. Ohne Kettenmechanismus müßte das weniger wirksame Format für alle Indexfolgen verwendet werden. Das Kettenformat ist auch dann nützlich, wenn verschiedene Varianten und verschiedene Toleranzstufen unterschiedliche Untertabellen erfordern. Jede Untertabelle in der Kette weist Bitmerker auf, welche bewirken können, daß sie ausgenommen oder eingefügt wird, basierend auf der Zuordnungstoleranz und der Variante, welche gerade behandelt werden. Bezüglich des zweiten, dritten und vierten Aspekts der Erfindung werden, wenn die Suchvorrichtung 412 die Abbildungstabelle 414 nach Zielcodierungen absucht, nur die eingefügten Untertabellen berücksichtigt.
Ferner bezüglich des ersten bis vierten Aspekts der Erfindung bilden diese jeder Untertabelle zugeordneten Bitmerker eine Untertabellenmaske. Auch die Abrufanforderungen (z. B. Codierungsvariante und Toleranz) und bestimmten Attribute (z. B. aufgelöste Richtung und Kontext) bilden eine Auswahlmaske. Die Bitzuweisungen innerhalb der Untertabellenmaske und der Auswahlmaske sind identisch. Somit wird die Bestimmung, ob eine bestimmte Untertabelle eingefügt wird oder nicht, als eine bitweise UND-Aktion der Untertabellenmaske mit der Auswahlmaske, und dann eines Vergleichs des Ergebnisses mit der Untertabellenmaske implementiert. Wenn das Ergebnis der bitweisen UND-Aktion dasselbe wie die Untertabellenmaske für die Untertabelle ist, wird die Untertabelle eingefügt; sonst wird sie nicht eingefügt.
Die Kopfzeile 500 der Abbildungstabelle 414 enthält vorzugsweise:
- Allgemeine Identifizierungsinformationen: Format, Länge, Kontrollzahl und Version.
- Die Mindestzielzeichengröße (in Bytes) (auch als "charsize" bezeichnet).
- Allgemeine Merker (beispielsweise, ob diese Suchtabelle Richtungs- oder Kontextdaten erfordert).
- Die maximale Länge der Eingabefolge, welche von dieser Tabelle verarbeitet wird, und eine Liste der Offset/Längen-Paare, welche die Tabellen spezifiziert, die Eingabefolgenlängen von eins bis zu diesem Maximum verarbeiten.
- Das Standardersatzzeichen oder die Standardersatzzeichenfolge für diese Aus-Unicode- Zuordnung.
- Eine Anzahl und Liste der von dieser Tabelle unterstützten Varianten. Für jede Variante werden eine oder mehrere zugeordnete Bitmasken spezifiziert. Wenn es mehrfache Bitmasken für eine einzige Variante gibt, werden Attributinformationen (wie die Richtung, der Kontext und die Anforderung für vertikale Formen) verwendet, um zu bestimmen, welche Bitmaske verwendet wird. Auf "1" gesetzte Bits in einer Bitmaske werden benutzt, um verschiedene Untertabellen zu aktivieren, um die verschiedenen Varianten zu unterstützen.
- Ein zusätzlicher Satz von Bitmasken, welche jeder der vier möglichen Toleranzeinstellungen (genau/locker, Ersatz an/aus) zugeordnet sind. Die geeignete Toleranzstufenmaske wird mit einem ODER-Glied mit der Variantenmaske verbunden, um die Bitmaske zu bilden, welche verwendet wird, um Untertabellen zu aktivieren oder zu deaktivieren.

C. Codeumwandlungsverarbeitung

Die Verarbeitung, welche von einer bevorzugten Ausführung des Unicode- Codeumwandlungssystems 400 durchgeführt wird, wird in Einzelheiten hiernach erklärt.
Abb. 6A ist ein Fließbild für die Verarbeitung 600, welche von einer Anwendung (d. h. einem Abrufanwendungsverfahren oder -programm), durchgeführt wird, die das Unicode- Codeumwandlungssystem 400 benutzt. Insbesondere betrifft Abb. 6A die Aus-Unicode- Verarbeitung, aber es sollte klar sein, daß analoge Operationen durchgeführt werden, um in die andere Richtung (In-Unicode-Verarbeitung) umzuwandeln. Der Aus-Unicode-Umwandler 402 steuert das gesamte Umwandlungsverfahren.
Zu Anfang schafft und initialisiert 602 die Verarbeitung 600 eine neue Instanz der Zustands- und Steuerinformationen für eine Umwandlung. Da die Verarbeitung 600 Instanzen einrichtet, können mehrfache Abfragevorgänge ablaufen und durch ihre Instanz unterschieden werden.
Danach wird eine Entscheidung 604 auf der Basis getroffen, ob eine Abkürzung erforderlich ist. In dem Fall, wo eine Abkürzung erforderlich ist, wird die Abkürzungsvorrichtung 407 aufgerufen 606. Die Abkürzung wird eingesetzt, wenn der Eingabedatenstrom die Kapazität des Empfangspuffers 405 überschreitet, welcher die Daten für die Umwandlung speichert. In einem Fall, wo die Abkürzung nicht erforderlich ist, oder nach dem Block 606 in dem Fall, wo die Abkürzung erforderlich ist, wird der Aus-Unicode-Umwandler 402 aufgerufen 608, um die Unicodezeichenfolge 404 umzuwandeln. Der Aus-Unicode-Umwandler 402 hat die Aktion, das Textelement zu erhalten und die Zielzuordnung dafür zu suchen, wie in Einzelheiten unten diskutiert wird. Wenn einmal die UmwandlungsAktion rückspringt, empfängt die Verarbeitung 600 die Zielzeichenfolge 406 von dem Aus-Unicode-Umwandler 402.
Die Verarbeitung 600 bestimmt dann 612, ob es einen Umwandlungsfehler gegeben hat. Wenn es einen Umwandlungsfehler gegeben hat, wird dann der Fehler bearbeitet 614. Auf der anderen Seite wird, wenn die Umwandlung erfolgreich war, dann eine Entscheidung auf der Basis getroffen 616, ob die Umwandlung vollständig ist. Die Umwandlung ist vollständig, wenn die Zeichen der Unicode-Zeichenfolge 404 in Zielcodierungen umgewandelt sind. Wenn die Umwandlung vollständig ist, ist die Verarbeitung 600 abgeschlossen und die Zielzeichenfolge 406 wird dem Verfahren oder der Anwendung zugänglich gemacht, welche die Codeumwandlung aufgerufen hat. Zusätzlich legt die Verarbeitung 600 die Instanz der Zustands- und Steuerinformationen für eine Umwandlung ab 618. Auf der anderen Seite wiederholt, wenn die Entscheidung 616 bestimmt, daß die Umwandlung noch nicht vollständig ist, dann die Verarbeitung 600 die Blöcke 604-616, bis die Umwandlung vollständig ist oder sich ein Fehler ergibt.
Abb. 6B ist ein Fließbild für die Abkürzungsverarbeitung 620 in Übereinstimmung mit dem vierten Aspekt der Erfindung. Die Abkürzungsverarbeitung 620 wird von Block 606 in Abb. 6A aufgerufen und von der Abkürzungsvorrichtung 407 durchgeführt. Die Abkürzungsverarbeitung 620 initialisiert 622 eine Ausgabelänge bis Null (0). Die Ausgabelänge entspricht der effektiven Länge des Puffers, d. h. der abgekürzten Länge des Puffers. Danach wird das nächste Textelement erhalten 624. Die mit dem Erhalt 624 des nächsten Textelementes verbundene Verarbeitung wird von der Abfrageeinrichtung 408 durchgeführt und ist in Einzelheiten unten unter Bezugnahme auf die Abb. 9A-9B beschrieben. Dann wird eine Entscheidung 626 auf der Basis getroffen, ob sich das Textelement über die physische Länge des Puffers (Pufferlänge) hinaus erstrecken könnte. Wenn sich das Textelement nicht möglicherweise über die Pufferlänge hinaus erstrecken kann, wird dann die Ausgabelänge aktualisiert 628, um dieses Textelement einzufügen. Hierbei wird die effektive Länge Textelement für Textelement ausgeweitet, bis sich das Textelement nicht mehr möglicherweise über die Pufferlänge hinaus erstrecken kann. Nach dem Block 628 wird eine Entscheidung 630 auf der Basis getroffen, ob zusätzlicher Text in dem Puffer zu berücksichtigen bleibt. Wenn es noch zusätzlichen Text in dem Puffer zu berücksichtigen gibt, läuft die Verarbeitung zurück zu Block 624, um die Abkürzungsverarbeitung 620 zu wiederholen. Auf der anderen Seite, wenn kein zusätzlicher Text mehr in dem Puffer zu berücksichtigen ist, oder wenn der Block 626 bestimmt, daß sich das Textelement möglicherweise über die Pufferlänge hinaus erstrecken könnte, wird die Ausgabelänge 632 rückgeführt. Die rückgesprungene Ausgabelänge 632 ist die effektive (d. h. abgekürzte) Länge des Puffers, so daß der Puffer effektiv an dem Ende eines Textelementes (nämlich das letzte Textelement für den Text innerhalb des Puffers) endet.
Somit bestimmt die Abkürzungsverarbeitung die effektive (d. h. abgekürzte) Länge des Puffers. Diese wird auch als abgekürzter Abschnitt des Puffers bezeichnet. Der Extratext, welcher in dem Puffer nach der Abkürzung verbleibt, wird als Restabschnitt bezeichnet. Der Restabschnitt wird zu einem nächsten Pufferabschnitt der Eingabeprimärzeichenfolge übertragen und mit ihm berücksichtigt. Diese Verarbeitung gewährleistet, daß Textelemente korrekt bestimmt werden.
Ein Beispiel für den Einsatz der Abkürzungsverarbeitung ist das folgende:

Beispiel: "... ABCD'EFG..."

Wenn der in dem Puffer gehaltene Abschnitt direkt nach "D" endet, dann kürzt die Abkürzungsverarbeitung den in dem Puffer gehaltenen Abschnitt derart, daß die abgekürzte Länge nach "C" endet. Es ist notwendig, den Abschnitt in dem Puffer abzukürzen, da andernfalls das Textelement "D" von seinenn Kombinationszeichen "' ", welches folgt, getrennt würde. Bei einer Trennung wird der Text nicht korrekt in die Zielcodierung umgewandelt. Der Restabschnitt besteht dann aus "D" und wird in den nächsten Abschnitt übertragen, d. h. "D'EFG... ".
Abb. 7 ist ein Fließbild der Unicodeumwandlerverarbeitung 700. Die Unicode- Umwandlerverarbeitung ist mit den Operationen verbunden, welche von Block 608 in Abb. 6A durchgeführt werden.
Die Unicodeumwandlerverarbeitung 700 beginnt mit einer Entscheidung 702. Die Entscheidung 702 bestimmt, ob es umzuwandelnden Text gibt. Wenn es keinen umzuwandelnden Text gibt, springt die Unicodeumwandlerverarbeitung 700 einfach zurück (oder endet). Wenn es auf der anderen Seite umzuwandelnden Text gibt (d. h. die Unicodezeichenfolge 404 wurde nicht vollständig verarbeitet), läuft die Verarbeitung 700 weiter. Zuerst werden Offsets für einen Offset-Datenbereich aktualisiert 704. Der Offset-Datenbereich ist ein Datenbereich mit Offsets (Hinweisadressen), welche einer Eingabezeichenfolge zugeordnet sind, und welche anzeigen, wo bestimmte Änderungen, wie Schrift-Änderungszeichen, Zeilenumbrüche, Sprachänderungen etc. innerhalb der Eingabezeichenfolge 404 auftreten, welche die Aufrufanwendung für wichtig erachtet. Die Aktualisierung 704 des Offset-Datenbereiches beinhaltet die Anpassung der Offsets (Hinweisadressen) für Zeichen mit unterschiedlicher Länge. Beispielsweise sind die Unicode- Zeichen der Eingabe-Unicodezeichenfolge 404 zwei Bytes lang, während die Größe der mit einer Zielcodierung von ASCII verbundenen Zeichen ein Byte lang ist. Hier würde die Aktualisierung 704 des Offset-Datenbereiches die Offsets so anpassen, daß sie das entsprechende Zeichen in der Zielcodierung adressieren. In der Tat werden die Offsets in der Eingabezeichenfolge der Ausgabezeichenfolge, welche eine andere Codierung aufweist, zugeordnet. Das nächste Textelement wird dann erhalten 706. Die Abfrageeinrichtung 408 bestimmt unter Verwendung der Abfragetabelle 410 die Textelemente aus der Unicode- Zeichenfolge 404. Das Erhalten 706 des nächsten Textelementes wird in Einzelheiten unten diskutiert. Das erhaltene Textelement 706 wird dann in der Abbildungstabelle 414 gesucht 708, um einen Umwandlungscode für das nächste Textelement in der Zielcodierung zu erhalten. Das Suchen wird von der Suchvorrichtung 412 in Verbindung mit der Abbildungstabelle 414 durchgeführt. Das Suchen 708 des Umwandlungscodes wird auch unten in Einzelheiten diskutiert.
Danach wird eine Entscheidung 710 auf der Basis getroffen, ob ein Umwandlungscode für das Textelement gefunden wurde. Wenn ein Umwandlungscode gefunden wurde, werden eine Eingabepositionshinweisadresse und eine Ausgabepositionshinweisadresse jeweils für die Unicodezeichenfolge 404 und die Zielzeichenfolge 406 aktualisiert 712. Die Eingabepositionshinweisadresse zeigt an, wieviel von der Eingabezeichenfolge 404 umgewandelt wurde. Die Ausgabepositionshinweisadresse zeigt die Länge der Zielzeichenfolge 406 an. Nach Block 712 kehrt die Verarbeitung 700 zum Beginn der Unicodeumwandlerverarbeitung 700 zurück, so daß das nächste Textelement (falls vorhanden) der umzuwandelnden Unicodezeichenfolge 404 verarbeitet werden kann.
In dem Fall jedoch, wo die Entscheidung 710 bestimmt, daß kein Umwandlungscode in der Abbildungstabelle 414 gefunden wurde, wird eine Entscheidung 714 auf der Basis getroffen, ob die Aufrufeinrichtung (d. h. die Aufrufanwendung) eine Ersatzverarbeitung angefordert hat. Wenn die Aufrufeinrichtung eine Ersatzverarbeitung angefordert hat, wird die Ersatzverarbeitung durchgeführt 716. Die Ersatzverarbeitung wird von der Ersatzvorrichtung 416 durchgeführt und wird in Einzelheiten unten diskutiert. Auf der anderen Seite wird, wenn die Aufrufvorrichtung keine Ersatzverarbeitung aufgerufen hat, ein Fehler angezeigt 718, da das Textelement nicht von der Suchvorrichtung 412 in die Zielcodierung umgewandelt werden konnte. Nach den Blöcken 716 und 718 werden die Eingabepositionshinweisadresse und die Ausgabepositionshinweisadresse für die Unicode-Zeichenfolge 404 und die Zielzeichenfolge 406 jeweils aktualisiert 702, und dann kehrt die Verarbeitung zum Beginn der Unciodeumwandlerverarbeitung 700 zurück, so daß das nächste Textelement (falls vorhanden) der umzuwandelnden Unicodezeichenfolge 404 verarbeitet werden kann.
Abb. 8 ist ein Fließbild für die Offsetaktualisierungsverarbeitung 800. Die Offsetaktualisierungsverarbeitung 800 ist mit dem Block 704 in Abb. 7 verbunden, in welchem der Offsetdatenbereich aktualisiert wird.
Die Offsetaktualisierungsverarbeitung 800 beginnt mit einer Entscheidung 802 auf der Basis, ob sich die laufende Eingabeposition in dem Offsetdatenbereich befindet. Wenn sich die laufende Eingabeposition in dem Offsetdatenbereich befindet, dann wird der Inhalt des Offsetdatenbereiches aktualisiert 804 in Übereinstimmung mit der laufenden Ausgabepositionslänge nach Block 804, und die Offsetaktualisierungsverarbeitung 800 springt zurück. Wenn auf der anderen Seite die laufende Eingabeposition nicht innerhalb des Offsetdatenbereiches liegt, dann bewirkt die Entscheidung 802 einfach, daß die Offsetaktualisierungsverarbeitung 800 zurückspringt, da es kein Offset zu aktualisieren gibt.
Die Abb. 9A und 9B sind Fließbilder für die Verarbeitung des nächsten Textelementes 900 bezüglich des ersten, zweiten und vierten Aspekts der Erfindung. Die Verarbeitung des nächsten Textelementes 900 erläutert in Einzelheiten die Operationen, welche von dem Block 706 in Abb. 7 bei dem Erhalt des nächsten Textelementes durchgeführt werden. Vorzugsweise wird die Verarbeitung des nächsten Textelementes 900 von der Abfrageeinrichtung 408 in Verbindung mit der Abfragetabelle 410 durchgeführt.
Die Verarbeitung des nächsten Textelementes 900 beginnt mit der Initialisierung 902 von Zustands- und Neuordnungsmerkern. Danach wird eine Entscheidung 904 auf der Basis getroffen, ob die Abbildungstabelle 414 Richtungsinformationen benötigt. Wenn die Abbildungstabelle 414 Richtungsinformationen benötigt, dann wird die Richtung der Unicodezeichenfolge 404 aufgelöst 906. In dem zweiten Aspekt der Erfindung wird dann, wenn die Abbildungstabelle 414 Richtungsinformationen benötigt, die Richtung des nächsten Eingabezeichens der Unicodezeichenfolge 404 aufgelöst 906. Nachdem die Richtung aufgelöst ist 906 oder nach der Entscheidung 904 in dem Fall, wo die Richtung nicht erforderlich ist, wird eine Entscheidung 908 auf der Basis des Kontextes des Zeichens getroffen. Wenn der Kontext der Zeichen innerhalb der Unicode-Zeichenfolge 404 die Codeumwandlung (Zuordnung) beeinflussen kann, wird der Kontext aufgelöst 910. Nach Block 910 oder nach der Entscheidung 908, wenn der Kontext nicht wichtig ist, wird das Unicode-Zeichen aus der Unicode- Zeichenfolge 404 erhalten 912. Danach werden die Attribute für das erhaltene Unicode-Zeichen gesucht 914. Die gesuchten Attribute 914 werden unten in Einzelheiten unter Bezugnahme auf die Abb. 11-13 diskutiert. Dann wird die Aktion für die Verarbeitung des nächsten Textelementes 900 bestimmt 916. Die Bestimmung 916 der Aktion wird in größeren Einzelheiten unten unter Bezugnahme auf die Abb. 14A, 14E4 und 15 erklärt.
Danach wird eine Entscheidung 918 auf der Basis getroffen, ob die Aktion "ENDE" ist. Wenn die Aktion nicht "ENDE" ist, dann ist die Aktion zumindest ein "WEITER". Wenn die Aktion "WEITER" ist, wird eine Entscheidung 920 auf der Basis getroffen, ob die Aktion auch "MARKIEREN" ist. Wenn die Aktion auch "MARKIEREN" ist, dann wird das Zeichen in das Textelement eingefügt 922. Zusätzlich wird der Zweirichtungszustand gespeichert 924, wenn eine "MARKIEREN"-Aktion genommen wird. Der Zweirichtungszustand beinhaltet den Richtungsintegrierungsstack und den laufenden Zustand des Zweirichtungszustandmoduls. Nach Block 924 oder nach dem Entscheidungsblock 920, wenn die Aktion nicht auch "MARKIEREN" ist, wird eine Verzweigungsoperation 926 basierend auf einem Aktiorismodifizierfaktor durchgeführt. Der Aktionsmodifizierfaktor ist ein Teil der Aktion und beinhaltet Modifizierfaktoren wie "S", "ISS", "ASS". Die Aktion kann auch keinen Modifizierfaktor aufweisen. Wenn der Aktionsmodiflzierfaktor "S" ist, wird ein Neuordnungsmerker gesetzt 928. Der Neuordnungsmerker zeigt an (wenn gesetzt), daß die Zeichen innerhalb des Textelementes eventuell neu geordnet werden müssen. Wenn der Aktionsmodifizierfaktor "ISS" ist (d. h. Inhibit Symmetric Swapping), dann wird ein Swap-Merker deaktiviert 930. Wenn der Aktionsmodifizierfaktor "ASS" ist (d. h. Activate Symmetric Swapping), wird der Swap-Merker aktiviert 932. Der Swap-Merker zeigt an, ob das symmetrische Swapping benötigt wird oder nicht. Der Verteiler 926 kann leicht angepaßt werden, um zusätzliche Aktionsmodifizierfaktoren unter Verwendung eines Ausdehnungsbereiches 934 zu umfassen. Der Ausdehnungsbereich 934 ermöglicht Anwendern, das Verhalten der Abfrageeinrichtung 408 zu verändern. Wenn es keinen Aktionsmodifizierfaktor gibt, dann führt die Verarbeitung für das nächste Textelement 900 keine mit Aktionsmodifizierfaktoren verbundene Operationen durch. Nach den Aktionsmodifizierfaktoroperationen wird ein laufender Zeichenindex aktualisiert 936. Der laufende Zeichenindex ist eine Hinweisadresse in die Primärzeichenfolge, welche verwendet wird, um die Primärzeichenfolge abzufragen, wenn die Verarbeitung für das nächste Textelement 900 durchgeführt wird. Die Verarbeitung für das nächste Textelement 900 wiederholt dann die Operationen beginnend mit Block 904. Die Verarbeitung läuft durch die Blöcke 904-936, bis die Entscheidung 918 bestimmt, daß die Aktion, ENDE" ist. Wenn die Aktion "ENDE" ist, bewirkt die Entscheidung 918, daß ein Entscheidungsblock 938 durchgeführt wird. Der Entscheidungsblock 938 bestimmt, ob der Neuordnungsmerker gesetzt ist. Wenn der Neuordnungsmerker gesetzt ist (Block 928), dann werden Zeichen innerhalb des Textelementes neu geordnet 940. Die Neuordnung wird vorzugsweise unter Verwendung des Prioritätsattributs durchgeführt, welches Gewichtungswerte für unterschiedliche Zeichenklassen liefert. Nach Block 938 in dem Fall, wo der Neuordnungsmerker nicht gesetzt ist, oder nach Block 940 in dem Fall, wo der Neuordnungsmerker gesetzt ist, ist die Verarbeitung für das nächste Textelement 900 vollständig und kehrt zu der Unicodeumwandlerverarbeitung 700 zurück.
Die Abb. 10A, 10B und. 10C sind Fließbilder für die nächste Textelementverarbeitung 900 gemäß dem dritten Aspekt der Erfindung. Die Verarbeitung für das nächste Textelement 900 zeigt in Einzelheiten die von dem Block 706 in Abb. 7 durchgeführten Operationen bei dem Erhalt des nächsten Textelementes. Vorzugsweise wird die Verarbeitung für das nächste Textelement 900 von der Abfrageeinrichtung 408 in Verbindung mit der Abfragetabelle 410 durchgeführt.
Die nächste Textelementverarbeitung 900 beginnt mit der Initialisierung 952 von Zustands- und Neuordnungsmerkern. Danach wird eine Entscheidung 954 auf der Basis getroffen, ob die Abbildungstabelle 414 Richtungsinformationen benötigt. Wenn die Abbildungstabelle 414 Richtungsinformationen benötigt, dann wird die Richtung des nächsten Eingabezeichens der Unicode-Zeichenfolge 404 aufgelöst 956. Dann wird das Unicode-Zeichen aus der Unicode- Zeichenfolge 404 erhalten 958. Hierbei wird das nächste Zeichen in der Unicode-Zeichenfolge 404 erhalten 958. Danach werden die Attribute für das erhaltene Unicode-Zeichen gesucht 960. Die gesuchten Attribute 960 werden unten unter Bezugnahme auf die Abb. 11-13 in Einzelheiten diskutiert. Dann werden die Aktion und der nächste Zustand für die Verarbeitung für das nächste Textelement 900 bestimmt 962. Die Bestimmung 962 der Aktion und des nächsten Zustands wird in größeren Einzelheiten unten unter Bezugnahme auf die Abb. 14A, 14B, 16A und 16B erläutert.
Danach wird eine Entscheidung 964 auf der Basis getroffen, ob die Aktion "ENDE" ist. Wenn die Aktion nicht "ENDE" ist, dann ist die Aktion zumindest ein "WEITER". Wenn die Aktion "WEITER" ist, wird eine Entscheidung 966 auf der Basis getroffen, ob die Aktion auch "MARKIEREN" ist. Wenn die Aktion auch "MARKIEREN" ist, dann wird das Zeichen in das Textelement eingefügt 968. Zusätzlich wird der Zweirichtungszustand gespeichert 970, wenn eine "MARKIEREN"-Aktion genommen wird. Der Zweirichtungszustand beinhaltet den Richtungsintegrierungsstack und den laufenden Zustand des Zweirichtungszustandmoduls. Nach Block 970 oder nach dem Entscheidungsblock 966, wenn die Aktion nicht auch "MARKIEREN" ist, wird eine Verzweigungsoperation 972 basierend auf einem Aktionsmodifizierfaktor durchgeführt. Der Aktionsmodifizierfaktor ist ein Teil der Aktion und beinhaltet Modifizierfaktoren wie "S", "ISS", "ASS". Die Aktion kann auch keinen Modifizierfaktor aufweisen. Wenn der Aktionsmodiflzierfaktor "S" ist, wird ein Neuordnungsmerker gesetzt 974. Der Neuordnungsmerker zeigt an (wenn gesetzt), daß die Zeichen innerhalb des Textelementes eventuell neu geordnet werden müssen. Wenn der Aktionsmodifizierfaktor "ISS" ist (d. h. Inhibit Symmetric Swapping), dann wird ein Swap- Merker deaktiviert 976. Wenn der Aktionsmodifizierfaktor "ASS" ist (d. h. Activate Symmetric Swapping), wird der Swap-Merker aktiviert 980. Der Swap-Merker zeigt an, ob das symmetrische Swapping benötigt wird oder nicht. Der Verteiler 972 kann leicht angepaßt werden, um zusätzliche Aktionsmodifizierfaktoren unter Verwendung eines Ausdehnungsbereiches 980 zu umfassen. Der Ausdehnungsbereich 980 ermöglicht Anwendern, das Verhalten der Abfrageeinrichtung 408 zu verändern. Wenn es keinen Aktionsmodifizierfaktor gibt, dann führt die Verarbeitung für das nächste Textelement 900 keine mit Aktionsmodifizierfaktoren verbundene Operationen durch. Nach den Aktionsmodifizierfaktoroperationen wird ein laufender Zeichenindex aktualisiert 982. Der laufende Zeichenindex ist eine Hinweisadresse in die Primärzeichenfolge, welche verwendet wird, um die Primärzeichenfolge abzufragen, wenn die Verarbeitung für das nächste Textelement 900 durchgeführt wird. Die Verarbeitung für das nächste Textelement 900 wiederholt dann die Operationen beginnend mit Block 904. Die Verarbeitung läuft durch die Blöcke 954-982, bis die Entscheidung 964 bestimmt, daß die Aktion "ENDE" ist. Wenn die Aktion "ENDE" ist, bewirkt die Entscheidung 964, daß eine Kontextverarbeitung 984 durchgeführt wird. Nach der Kontextverarbeitung 984 bestimmt der Entscheidungsblock 986, ob der Neuordnungsmerker gesetzt ist. Wenn der Neuordnungsmerker gesetzt ist (siehe Block 974), dann werden Zeichen innerhalb des Textelementes neu geordnet 988. Die Neuordnung wird vorzugsweise unter Verwendung des Prioritätsattributs durchgeführt, welches Gewichtungswerte für unterschiedliche Zeichenklassen liefert. Nach Block 986 in dem Fall, wo der Neuordnungsmerker nicht gesetzt ist, oder nach Block 988 in dem Fall, wo der Neuordnungsmerker gesetzt ist, ist die Verarbeitung für das nächste Textelement 900 vollständig und kehrt zu der Unicodeumwandlerverarbeitung 700 zurück.
Die Kontextverarbeitung 984 wird jetzt unter Bezugnahme auf Abb. 10C beschrieben. Die Kontextverarbeitung 984 wird in dieser beschriebenen Ausführung von der Abfrageeinrichtung 408 zusammen mit der Abfragetabelle 410 implementiert. Die Kontextverarbeitung 984 beginnt mit einer Entscheidung 985, welche bestimmt, ob die Aktion "EndOutputXn" (d. h. einzelner Kontext) ist. Wenn dies so ist, dann wird die Kontextmaske gesetzt 986, um anzuzeigen, daß der Kontext einzeln und die Kontextverarbeitung 984 vollständig ist und rückspringt. Auf der anderen Seite bestimmt dann, wenn die Aktion nicht EndOutputXn ist, eine Entscheidung 987, ob die Aktion EndOutputXI ist (d. h. Anfangskontext). Wenn dies so ist, dann wird die Kontextmaske gesetzt 988, um anzuzeigen, daß der Kontext anfänglich und die Kontextverarbeitung 984 vollständig ist und rückspringt. Wenn auf der anderen Seite die Aktion nicht EndOutputXI ist, dann bestimmt eine Entscheidung 989, ob die Aktion EndOutoutXr ist (d. h. Endkontext). Wenn dies so ist, dann wird die Kontextmaske gesetzt 990, um anzuzeigen, daß der Kontext am Ende und die Kontextverarbeitung 984 vollständig ist und rückspringt. Wenn auf der anderen Seite die Aktion nicht EndOutputXr ist, dann bestimmt eine Entscheidung 991, ob die Aktion EndOutputXm ist (d. h. mittlerer Kontext). Wenn dies so ist, dann wird die Köntextmaske gesetzt 992, um anzuzeigen, daß der Kontext in der Mitte und die Kontexiverarbeitung 984 vollständig ist und rückspringt. Wenn die Entscheidung 991 bestimmt, daß die Aktion nicht EndOutputXm ist, dann hat das Textelement keinen ihm zugeordneten Kontext, und die Kontextmaske wird auf Nichtbeachten gesetzt 993.
Somit wird die Kontextverarbeitung 984 in der oben dargelegten Ausführung derart implementiert, daß das Textelement und der Kontext zusammen bestimmt werden. Beide Bestimmungen nutzen die von der Abftageeinrichtung 408 und der Abfragetabelle 410 durchgeführte Abfragung, um sicherzustellen, daß das Textelement vollständig und daß der Kontext des Textelementes innerhalb des Eingabetextstromes bekannt ist. Die in der Kontextmaske vorliegenden Kontextinformationen werden danach von der Suchvorrichtung 412 in Zusamenwirken mit der Abbildungstabelle 414 benutzt, um die korrekte Zielcodierung für das Textelement mit dem bestimmten Kontext zu suchen. Mehr Einzelheiten bezüglich der Funktionsweise der Kontexiverarbeitung werden unten unter Bezugnahme auf die Abb. 16A und 16B dargelegt.
Abb. 11 ist ein Blockdiagramm der Abfrageeinrichtung 408. Die Abftageeinrichtung 408 umfaßt unter anderem eine Attributeverarbeitungsvorrichtung 1000 und eine Textelementverarbeitungsvorrichtung 1002. Die Textelementverarbeitungsvorrichtung 1002 führt die oben unter Bezugnahme auf die Abb. 9A und 9B und die Abb. 10K 10C beschriebene Verarbeitung für das nächste Textelement 900 durch. Die Attributeverarbeitungsvorrichtung I000 wirkt mit einer Attributetabelle 1004 zusammen, um die Attribute für ein Unicode-Zeichen zu erhalten, wie es von der Verarbeitung für das nächste Textelement 900 benötigt wird (siehe Block 914 in Abb. 9A und Block 960 in Abb. 10A). Die Attribute beinhalten die folgenden Elemente: Richtung, Klasse, Priorität, symmetrisches Swapping, Untergruppe und Kontext. Das Richtungsattribut wird bei der Richtungsauflösung verwendet (Block 906 Abb. 9A und Block 956 Abb. 10A und Abb. 17A). Das Klassenattribut wird von der Abfrageeinrichtung 408 verwendet, um Aktionen zu bestimmen (z. B. WEITER, ENDE). Das Prioritätsattribut wird verwendet, um die Zeichen imierhalb eines Textelementes neu zu ordnen (siehe Block 940, Abb. 9B und Block 988 Abb. 10A). Das symmetrische Swappingaftribut wird verwendet, um zu bestimmen, ob symmetrisches Swapping erforderlich ist oder nicht. Das Kontextattribut wird bei der Auflösung des Kontexts verwendet (Block 910 Abb. 9A).
Abb. 12 ist ein schematisches Diagramm eines bevorzugten Formates für die Attributetabelle 1004 aus Abb. 11. Die Attributetabelle 1004 umfaßt einen Kopfzeilenbereich 1100, einen Reihentabellenbereich 1102 und einen Attributetabellenbereich 1104. Der Kopfzeilenbereich 1100 beinhaltet Informationen bezüglich der folgenden Elemente: Gesamttabellengröße, Kontrollzahlwert, Version, Offset und Anzahl der Elemente für jede Tabelle. Die Elemente innerhalb des Reihentabellenbereiches 1102 liefern Reihen, in welchen die Attribute zusammen gruppiert sind, und dann ist für eine jede solche Gruppe eine Hinweisadresse zu dem geeigneten Bereich des Attributetabellenbereiches 1104 vorgesehen. Das Format des Reihentabellenbereiches 1102 der Attributetabelle 1004 umfaßt für jeden Eintrag einen Reihenbeginnwert, einen Reihenendwert und ein der Reihe zugeordnetes Datenwort. Die Anordnung der Attributetabelle 1004 erleichtert die kompakte Speicherung der Attributeinformationen. Alternative Speicheranordnungen sind möglich, aber weniger wirksam bezüglich der Kompaktheit der Datenspeicherung.
Abb. 13 ist ein Fließbild der Attributesuchverarbeitung 1200. Die Attributesuchverarbeitung 1200 wird von der Attributeverarbeitungsvorrichtung 1000 durchgeführt und von der Verarbeitung für das nächste Textelement 900 in Block 914 in Abb. 9A oder Block 960 in Abb. 10A initiiert.
Die Attributesuchverarbeitung 1200 beginnt mit einer binären Suche unter Verwendung der Reihen innerhalb des Reihentabellenbereiches 1102 der Attributetabelle 1004. Wenn einmal die geeignete Reihe durch die binäre Suche identifiziert ist, wird das dieser Reihe zugeordnete Datenwort aus dem Reihentabellenbereich 1102 erhalten. Vorzug Weise ist das erste Bit des Datenwortes ein richtungsloses Bit. Dann wird eine Entscheidung 1206 auf der Basis getroffen, ob das richtungslose Bit des Datenwortes gesetzt ist. In dem Fall, wo das richtungslose Bit des Datenwortes nicht gesetzt ist, enthält das Datenwort selbst die Attribute für das laufende Zeichen, und daher wird das Datenwort, wie die Attribute, zurückgeführt 1208. Wenn auf der anderen Seite das richtungslose Bit des Datenwortes gesetzt ist, werden die Attribute aus dem Attrubutetabellenbereich 1104 unter Verwendung des Datenwortes erhalten, welches aus dem Reihentabellenbereich 1102 als ein Index oder Offset in den Attributetabellenbereich 1104 erhalten wird. Somit ist das Datenwort in diesem Fall ein Index oder Offset zu einem Datenbereich, welcher die Attribute für jedes Zeichen in der Reihe enthält. Nach entweder Block 1208 oder 1210 ist die Attributesuchverarbeitung 1200 beendet und springt zurück.
Die Abb. 14A und 14B sind schematische Diagramme, welche mit einer Abfragetabelle 1300 (410) verbunden sind, welche von der Abifageeinrichtung 408 benutzt wird, um die nächste Aktion zu bestimmen. Die Bestimmung der nächsten Aktion wird von Block 916 der Verarbeitung für das nächste Textelement (Abb. 9A) oder von Block 962 (Abb. 10A) aufgerufen. Es wird daran erinnert, daß die nächste Aktion bei der Bestimmung des nächsten Textelementes verwendet wird. · Abb. 14A illustriert ein bevorzugtes Format für die Abfragetabelle 1300 zur Verwendung mit der Erfindung. Die Abfragetabelle 1300 ist ein Zweirichtungs-Datenbereich mit "laufendem Zustand" als einem Index und "Klasse" als anderem Index. Die "Klasse" bezieht sich auf das Klassenattribut. Diese Indices wählen ein repräsentatives Element 1302 innerhalb der Abfragetabelle 1300 aus. Abb. 14B illustriert das repräsentative Element 1302 der Abfragetabelle 1300. Das repräsentative Element 1302 umfaßt einen nächsten Zustandsbereich 1304, welcher einen nächsten Zustand für die Abfrageeinrichtung 408 enthält, und der Aktionsbereich 1306 gibt die Aktion für die Abfrageeinrichtung 408 an. In der Tat implementiert die Abfrageeinrichtung 408 zusammen mit der Abfragetabelle 1300 ein Zustandsmodul, um zu bestimmen, wie die Abfrageeinrichtung vorgehen sollte.
Die Abfragetabelle 1300 liefert verschiedene nächste Zustände und Aktionen für verschiedene Zeichencodierungen.
Bezüglich des ersten, zweiten und vierten Aspekts der Erfindung ist Abb. 15 eine Tabelle 1400, welche sowohl eine bevorzugte Gestaltung als auch Informationen, welche in der Abfragetabelle 1300 gespeichert würden, darstellt. Die der Tabelle zugeordneten Bezeichnungen sind die folgenden:

Zeichenklassen:

CC - Steuerzeichen
OS - Anderes Zwischenraumzeichen
NS - zwischenraumloses Zeichen
LD - Lateinische Ziffer
Es - Bruchstrich
JL (f) - Jamos-Leitkonsonant (Füllzeichen)
TV (1) - Jamos-Vokal (Füllzeichen)
ST - Jamos-Kononantennachsatz
NU - Kein gültiges Unicode-Zeichen
ISS - Symmetrisches Swappingunterdrücken
ASS - Symmetrisches Swapping aktivieren

Nächste Zustände:

Zustand 0 - Ende, bestimmt, ob das Textelement basierend auf Zuständen von doppelten und halben diakritischen Zeichen rückspringen soll
Zustand 1 - Startzustand
Zustand 2 - Zwischenraumloses Zeichen hinzufügen (diakritisches Zeichen)
Zustand 3 - Numerische Bruchzahl überprüfen
Zustand 7 - Koreanisches Jamoszeichen

Aktionen:

Adv - [ADVANCE] weiter zu nächstem Zeichen (das laufende Zeichen kann, aber muß nicht in dem laufenden Textelement (TE) enthalten sein).
AdvMark - [ADVANCE + MARK] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen.
AdvMarkS - [ADVANCE + MARK + S] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und Neuordnungsmerker seazen.
AdvMarkASS - [ADVANCE + MARK + ASS] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und symmetrisches Swapping aktivieren.
AdvMarkISS - [ADVANCE + MARK + ISS] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und symmetrisches Swappsng unterdrücken
End - Ende Textelement mit letztem markierten Zeichen.
Bemerkungen: Alle Funktionen überprüfen, ob der Neuordnungsmerker gesetzt ist und ordnen die zwischenraumlosen Zeichen neu, beginnend bei der Starthinweisadresse. Es ist am besten, die gesamte Zeichenfolge zu überprüfen, da es mehr als einen Satz zwischenraumloser Zeichen geben kann, welcher neu geordnet werden muß. Natürlich wird nach der Neuordnung der Zeichen der Neuordnungsmerker gelöscht.
Bezüglich des dritten Aspekts der Erfindung enthalten die Abb. 16A und 16B eine Tabelle 1400, welche sowohl eine bevorzugte Gestaltung als auch Informationen darstellt, welche in der Abfragetabelle 410 gespeichert würden, um die Bestimmung sowohl des Textelementes als auch seines Kontextes innerhalb der Primärzeichenfolge zu erleichtern. Die der Tabelle zugeordneten Bezeichnungen sind die folgenden:

Zeichenklassen:

CC - Steuerzeichen
OS - Anderes Zwischenraumzeichen
NS - zwischenraumloses Zeichen
LD - Lateinische Zahl
FS - Bruchstrich
DD - doppeltes diakritisches Zeichen
HD - halbes diakritisches Zeichen
CH - Jamos-Leitkonsonant (Füllzeichen)
JO - Jamos-Vokal (Füllzeichen)
IV - Jamos-Konsonantennachsatz
NU - Kein gültiges Unicode-Zeichen
ISS - Symmetrisches Swapping unterdrücken
ASS - Symmetrisches Swapping aktivieren
HH - Hoher Halbbereich
LH - Niedriger Halbbereich
V - Virama
ZWNJ - Null breites Nicht-Verbindungszeichen
R - Rechtsverbindung
D - Doppelte Verbindung
C - Verbindung bewirkend
T - Transparent

Nächste Zustände:

Zustand 0 - Ende, bestimmt, ob das Textelement basierend auf Zuständen von doppelten und halben diakritischen Zeichen rückspringen soll
Zustand 1 - Startzustand
Zustand 2 - Zwischenraumloses Zeichen hinzufügen (diakritisches Zeichen)
Zustand 3 - Lateinische Ziffer
Zustand 4 - Lateinische Ziffernfolge
Zustand 5 - Lateinische Ziffernfolge gefolgt von einem Bruchstrich
Zustand 6 - Lateinische Ziffernfolge, Bruchstrich, lateinische Ziffernfolge
Zustand 7 - Choseong-Folge
Zustand 8 - Choseong-Folge gefolgt von Jungseong-Folge
Zustand 9 - Choseong-Folge, Jungseong-Folge, Jongseong
Zustand 10 - Hohes Halbzeichen
Zustand 11 - Hohes Halbzeichen gefolgt von niedrigem Halbzeichen
Zustand 12 - Virama gefolgt von null-breitem Verbindungszeichen oder null-breitem Nicht-Verbindungszeichen
Zustand 13 - Spezieller Start für Kontext
Zustand 14 - Rechtsverbindendes Zeichen (in speziellem Kontextzustand)
Zustand 15 - Doppeltverbindendes Zeichen (in speziellem Kontextzustand)
Zustand 16 - Verbindung bewirkendes Zeichen (in normalem oder speziellem Zustand)
Zustand 17 - Rechtsverbindendes Zeichen (in normalem Zustand)
Zustand 18 - Doppeltverbindendes Zeichen (in normalem Zustand)

Nächster Startzustand: [tatsächlich eine Untergruppe von nächsten Zuständen]:

Zustand 1 - Startzustand
Zustand 13 - Spezieller Startzustand für Kontext

Aktionen:

Adv - [ADVANCE] weiter zu nächstem Zeichen (das laufende Zeichen kann, aber muß nicht in dem laufenden Textelement (TE) enthalten sein).
AdvMark - [ADVANCE + MARK] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen.
AdvMarkS - [ADVANCE + MARK + S] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und Neuordnungsmerker setzen.
AdvMarkASS - [ADVANCE + MARK + ASS] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und symmetrisches Swapping aktivieren.
AdvMarkISS - [ADVANCE + MARK + ISS] laufendes Zeichen als letztes markieren und weiter zu nächstem Zeichen und symmetrisches Swapping unterdrücken
End - Ende Textelement mit letztem markierten Zeichen.
EndOutputxn - [END + Alone Context] Ende Textelement und anzeigen, daß der Kontext allein ist.
EndOutputXl - [End + Initial Context] Ende Textelement und anzeigen, daß der Kontext am Anfang ist
EndOutput Xr - [End + Finished Contextj Ende Textelement und anzeigen, daß der Kontext am Ende ist.
EndOutputXm - [End + Medial Context] Ende Textelement und anzeigen, daß der Kontext in der Mitte ist.
Bemerkungen: Alle Funktionen überprüfen, ob der Neuordnungsmerker gesetzt ist und ordnen die zwischenraumlosen Zeichen neu, beginnend bei der Starthinweisadresse. Es ist am besten, die gesamte Zeichenfolge zu überprüfen, da es mehr als einen Satz zwischenraumloser Zeichen geben kann, welcher neu geordnet werden muß. Natürlich wird nach der Neuordnung der Zeichen der Neuordnungsmerker gelöscht Drei Beispiele für die Verwendung der Abfragetabelle 1400 folgen. Die ersten beiden Beispiele betreffen den ersten, zweiten, dritten und vierten Aspekt der Erfindung, während das dritte Beispiel den dritten Aspekt betrifft.

Beispiel 1: Eingabezeichenfolge "AAB"

Die Zeichenklasse ist für alle drei Zeichen OS. Das erste Zeichen "A" wird erhalten. Beginnend bei dem Startzustand (Zustand 1) ist die erste Aktion AdvMark und der nächste Zustand ist Zustand 2. Dies bewirkt, daß das erste Zeichen "A" in das laufende Textelement eingefügt wird, und daß das nächste Zeichen (zweites Zeichen "A") erhalten wird. Dann ist die Aktion bei Zustand 2 End und der nächste Zustand ist Zustand 0. Somit beinhaltet das Textelement nur das erste Textelement. Dieselbe Abfolge wird für das zweite und dritte Zeichen dieser bestimmten Eingabezeichenfolge wiederholt. So wird jedes der Zeichen der Eingabezeichenfolge einem separaten, aber angrenzenden Textelement zugeordnet.

Beispiel 2: Eingabezeichenfolge "A'B"

Die Zeichenklasse ist OS für das erste und letzte Zeichen d.er Eingabezeichenfolge. Die Zeichenklasse für das zweite Zeichen ist NS, da es sich um ein Kombinationszeichen handelt. Das erste Zeichen "A" wird erhalten. Beginnend bei dem Startzustand (Zustand I) ist die erste Aktion AdvMark und der nächste Zustand ist Zustand 2. Dies bewirkt, daß das erste Zeichen "A" in das laufende Textelement eingefügt wird, und daß das nächste Zeichen (zweites Zeichen "') erhalten wird. Dann ist bei Zustand 2 die Aktion AdvMarkS und der nächste Zustand ist Zustand 2. Dies bewirkt, daß das zweite Zeichen in das laufende Textelement eingefügt wird. Das dritte Zeichen wird dann erhalten. Die Aktion bei Zustand 2 ist diesmal End und der nächste Zustand ist Zustand 0. Somit beinhaltet das Textelement das erste und zweite Zeichen der Eingabezeichenfolge. Das dritte Zeichen wird in seinen eigenen Textelementen angeordnet, wie es der Fall in Beispiel 1 war.
Beispiel 3: Eingabezeichenfolge "OS R D OS OS". [Es gibt keine Zwischenräume zwischen den Zeichen und jedes Zeichen wird durch seine Zeichenklasse dargestellt. Die R- und D- Zeichenklasse beinhaltet Zeichen mit auf dem Kontext basierenden Darstellungsformen, aber die OS-Zeichenklasse nicht.]
Das erste Zeichen gehört zu Zeichenklasse OS. Beginnend bei dem Startzustand (Zustand 1) ist die erste Aktion AdvMark, der nächste Zustand ist Zustand 2 und der nächste Startzustand ist 1. Dies bewirkt, daß das erste Zeichen in das laufende Textelement eingefügt, und daß das zweite Zeichen erhalten wird. Das zweite Zeichen gehört zu der Zeichenklasse R. Dann ist bei Zustand 2 die Aktion End, der nächste Zustand ist 0 und der nächste Startzustand ist 1. Somit beinhaltet das erste Textelement nur das erste Zeichen und die Kontextmerker werden auf nicht beachten gesetzt.
Bei der Bestimmung des nächsten Textelementes beginnt die Verarbeitung mit dem zweiten Zeichen und bei dem neuen Startzustand 1. Diesmal führt die Abfragetabelle eine Aktion AdvMark durch, wobei der nächste Zustand 17 und der nächste Startzustand 13 ist. Dies bewirkt, daß das zweite Zeichen in das laufende Textelement eingefügt, und daß das dritte Zeichen erhalten wird. Das dritte Zeichen gehört zu der Zeichenklasse R. Dann ist bei Zustand 17 die Aktion EndOutputXn, der nächste Zustand ist 0 und der nächste Startzustand ist 1. Somit beinhaltet das zweite Textelement nur das zweite Zeichen und der Kontext ist Xn (allein).
Bei der Bestimmung des nächsten Textelementes beginnt die Verarbeitung mit dem dritten Zeichen und in dem neuen Startzustand 13. Dieser neue Startzustand ist der nächste Startzustand, welcher von der Tabelle für das letzte Zeichen angegeben ist. Hierbei führt die Abfragetabelle eine Aktion AdvMark durch, der nächste Zustand ist 15 und der nächste Startzustand ist 13. Das dritte Zeichen ist dann Teil des laufenden Textelementes und bewirkt, daß das vierte Zeichen erhalten wird. Das vierte Zeichen gehört zu der Zeichenklasse OS. Dann ist bei Zustand 15 die Aktion EndOutputXr, der nächste Zustand ist 0 und der nächste Startzustand ist 1. Somit beinhaltet das dritte Textelement nur das dritte Zeichen und der Kontext ist Xr (Ende).
Bei der Bestimmung des nächsten Textelementes beginnt die Verarbeitung mit dem vierten Zeichen und in dem neuen Startzustand 13. Die Abfragetabelle führt eine Aktion AdvMark durch, der nächste Zustand ist 2 und der nächste Startzustand ist 1. Dies bewirkt, daß das vierte Zeichen in das laufende Textelement eingefügt, und daß das fünfte Zeichen erhalten wird. Das fünfte Zeichen gehört zu der Zeichenklasse OS. Dann bei Zustand 2 ist die Aktion End, der nächste Zustand ist 0 und der nächste Startzustand ist 1. Somit beinhaltet das vierte Textelement nur das vierte Zeichen und die Kontextmerker werden auf nicht beachten gesetzt.
Abb. 17A ist ein Fließbild, welches die Richtungsauflösungsverarbeitung 1500 in Übereinstimmung mit dem zweiten Aspekt der Erfindung illustriert. Die Richtungsauflösungsverarbeitung 1500 ist die Verarbeitung, welche von Block 906 innerhalb der Verarbeitung für das nächste Textelement 900 (Abb. 9A) durchgeführt wird. Die Richtungsauflösungsverarbeitung 1500 beginnt mit einer Entscheidung 1502, welche bestimmt, ob der aufgelöste Richtungszustand für die Abftageeinrichtlang 408 sich in seinem Anfangszustand befindet. In dem Anfangszustand weiß die Abfrageeinrichtung 408 nichts über die Richtung der Zeichen in dem Textelement. Wenn der aufgelöste Richtungszustand für die Abfrageeinrichtung 408 im Anfangszustand ist, dann wird eine Anfangsrichtung für die Eingabezeichenfolge bestimmt 1504. Die mit der Bestimmung 1504 der Anfangsrichtung verbundene Verarbeitung ist in Einzelheiten unten unter Bezugnahme auf Abb. 18 beschrieben. Wenn sich auf der anderen Seite der aufgelöste Richtungszustand für die Abfrageeinrichtung 408 nicht in dem Anfangszustand befindet, dann muß die Anfangsrichtung nicht bestimmt werden. In jedem Fall wird nach Block 1502 oder Block 1504 ein Unicode-Zeichen aus dem Eingabestrom erhalten 1506. Die dem Unicode-Zeichen zugeordneten Attribute werden dann gesucht 1508. Das Richtungsattribut ist das wichtige Attribut für die Richtungsauflösungsverarbeitung 1500. Die Blöcke 1506 und 1508 der Richtungsauflösungsverarbeitung 1500 führen die gleichen Operationen wie die Blöcke 912 und 914 der Verarbeitung für das nächste Textelement 900 durch, und müssen daher nicht weiter diskutiert werden.
Danach werden die Richtung, der nächste Zustand und die nächste Aktion bestimmt 1510. Die Richtung, der nächste Zustand und die nächste Aktion werden unter Verwendung des Richtungsattributes und des laufenden Zustands bestimmt und aus einer Richtungstabelle unter Verwendung eines Tabellensuchverfahrens erhalten. Die Richtungstabelle ist ein zweidimensionaler Datenbereich, welcher von dem Richtungsattribut und dem laufenden Zustand indiziert wird. Das von den Indices adressierte Element innerhalb der Richtungstabelle beinhaltet die Richtung des Zeichens, den nächsten Zustand und die Aktion, welche die Richtungsauflösungsverarbeitung 1500 nehmen soll. Die Richtung ist eine der folgenden: links, rechts, global und NO OUTPUT. Die möglichen Aktionen sind: NO ACTION, PUSH RO, PUSH RE, PUSH LE, PUSH LO, POP und RESET. Da sich die Richtung innerhalb einer Eingabezeichenfolge aufgrund expliziter Prioritätszeichen ändern kann, werden Vorabrichtungen in einem Richtungsstack gespeichert. Somit beziehen sich die Verwendung von "push" und "pop" auf Stackverarbeitungsbefehle, welche in der Technik gut bekannt sind. "RO" bezieht sich auf Rechts-nach links-Priorität, "LO" bezieht sich auf Links-nach rechts-Priorität, "RE" bezieht sich auf Rechts-nach-Links-Integrierung und "LE" bezieht sich auf Links-nach rechts- Integrierung. Vorzugsweise arbeiten die Richtungstabelle und die Richtungsauflösungsverarbeitung 1500 als ein Zustandsmodul. Das Zustandsmodul folgt im wesentlichen dem Zweirichtung salgorithmus, welcher in The Unicode Standard, Version 1.0, S. 611-621 (Anhang A) beschrieben ist, aber es erreicht das Ergebnis mit nur einem einzigen Durchlauf, wohingegen der in The Unicode Standard beschriebene Algorithmus mehrfache Durchläufe erfordert.
Die Abb. 17B-17D illustrieren die Zweirichtungszustandstabellen 1511 gemäß einer bevorzugten Implementierung des Zweirichtungsalgorithmus gemäß dem zweiten Aspekt der Erfindung. Die Zweirichtungszustandstabellen 1511 implementieren ein tabellengetriebenes Zustandsmodul. Jede Spalte ist ein einziger Zustand. Den Zuständen werden Namen gegeben, welche auf die Informationen hindeuten, die sie aufzeichnen. Jede Reihe erstreckt sich über die Abb. 17B-17D und ist mit einem der folgenden Zeichenklassennamen gekennzeichnet.
LR streng links nach rechts
KL streng rechts nach links
AL Arabischer Buchstabe (streng rechts nach links)
LRE links nach rechts Integrierungszeichen
RLE rechts nach links Integrierungszeichen
LRO links nach rechts Prioritätszeichen
KLO rechts nach links Prioritätszeichen
PDF pop Richtungsformatzeichen
AN Arabische Zahl
EN Europäische Zahl
ET Europäischer Zahlenterininator
Es Europäischer Zahlenseparator
CS Gemeinsamer Zahlenseparator
ON Anderes neutrales Zeichen
BS Blockseparator
Jede Zelle in der Zweirichtungszustandstabelle 1511 stellt eine Umwandlung mit zugeordneten Aktionen und Outputs dar. Die Zellen enthalten den Namen des neuen Zustands, eine zu nehmende optionale Aktion und einen Output, falls vorhanden. Der neue Zustand kann von der laufenden globalen Richtung abhängen. Dies wird angezeigt, indem ein (G) in dem neuen Zustandsnamen auftaucht. Es ist ein Fehler, eine dieser Umwandlungen auszuführen, wenn die globale Richtung nicht bekannt ist. Die möglichen Aktionen sind die folgenden:
push einen neuen Integrierungszustand in den Integrierungsstack eingeben. Der aktuelle einzugebende Wert hängt von der vorliegenden aktuellen Integrierungssteuerung ab. In der Implementierung gibt es 4 verschiedene Aktionen, um dies durchzuführen.
pop den laufenden Integrierungszustand aus dem Stack herausnehmen und die neue Spitze des Stacks zum laufenden Integrierungszustand machen. Wenn die neue Integrierung eine Priorität ist, wird ein Übergang zu dem OR-Zustand anstelle des in der Zelle gegebenen Zielzustands durchgeführt.
reset den Integrierungsstack löschen und zu START gehen, ohne ein Zeichen zu verarbeiten, d. h. eine Epsilon-Umwandlung durchführen. Es gibt keinen Output bei einem Reset.
error einen unmittelbaren Fehler erzeugen.
Outputs sind entweder L oder R, was jeweils links nach rechts und rechts nach links bedeutet, G, was Output der laufenden globalen Richtung bedeutet, oder ·, was kein Output bedeutet. Eine Umwandlung, welche einen Output hat, beendet die Abfrage. In jedem Zustand kann ein Name, welcher nicht mit einem Kleinbuchstaben "s" beginnt in das Modul eingegeben werden. Der START-Zustand ist für einen neuen Textblock bestimmt. Der sDIR-Zustand wird als eine Einsprungstelle zur Bestimmung der globalen Richtung benutzt. Es sollte möglich sein, diese Berechnung gleichzeitig mit der Hauptabfrage durchzuführen, aber aus Einfachheitsgründen wird sie getrennt durchgeführt.
Zurückkehrend zu Abb. 15A wird dann nach Block 510 eine Entscheidung 1512 auf der Basis getroffen, ob die Aktion "RESET" ist. Wenn die Aktion "RESET" ist, dann springt die Verarbeitung zum Anfang der Richtungsauflösungsverarbeitung 1500 zurück. Andernfalls läuft die Richtungsauflösungsverarbeitung 1500 weiter. Nach der Entscheidung 1512 wird nämlich die Aktion durchgeführt 1514.
Danach wird eine Entscheidung 1516 auf der Basis getroffen, ob die Richtung (bestimmt in Block 1510) "NO OUTPUT" ist. Wenn die Richtung nicht gleich "NO OUTPUT" ist, dann wird die Richtung in dem Kontext (für jede Instanz) gesetzt 1518 und der Zustand wird beibehalten 1520. Nach Block 1.520 ist die Richtungsauflösungsverarbeitung 1500 vollständig und springt zurück.
In dem Fall jedoch, wenn die Entscheidung 1516 bestimmt, daß der Output "NO OUTPUT" ist, darin wird eine Entscheidung 1522 auf der Basis getroffen, ob die gesamte Eingabezeichenfolge verarbeitet wurde. Wenn die gesamte Eingabezeichenfolge nicht verarbeitet wurde, kehrt die Verarbeitung zum Beginn der Richtungsauflösungsverarbeitung 1500 zurück, so daß ein zusätzliches Unicode-Zeichen erhalten und verarbeitet werden kann, da bislang die Richtung des Textelementes nicht bestimmt wurde. Wenn auf der anderen Seite die Entscheidung 1522 bestimmt, daß die gesamte Eingabezeichenfolge verarbeitet wurde, dann bestimmt eine Entscheidung 1524, ob die Verarbeitung das Ende des Textes erreicht hat. Dies bedeutet, ob der in die Zielcodierung umzuwandelnde Text vollständig von der Richtungsauflösungsverarbeitung 1500 verarbeitet wurde. Wenn es noch zusätzlichen umzuwandelnden Text gibt, dann führt dies zu einem Fehler 1528, da für das laufende Zeichen der Eingabezeichenfolge keine Richtung berechnet werden konnte. Wenn es jedoch keinen zusätzlichen Text gibt, dann wird die Richtung für einen Blockseparator aus der Gesamtrichtung des Blockes (siehe 1504) bestimmt 1526. Nach Block 1526 werden die Blöcke 1518 und 1520, wie zuvor beschrieben, durchgeführt und dann ist die Richtungsauflösungsverarbeitung 1500 beendet und springt zurück.
Abb. 18 ist ein Fließbild der Verarbeitung zur Bestimmung der Anfangsrichtung 1600 gemäß dem zweiten Aspekt der Erfindung. Die Verarbeitung zur Bestimmung der Anfangsrichtung 1600 ist verbunden mit den von Block 1504 in Abb. 17A durchgeführten Operationen.
Die Verarbeitung zur Bestimmung der Anfangsrichtung 1600 beginnt mit einer Verzweigungsoperation 1602 basierend auf Steuerungsmerkern. Die Steuerungsmerker zeigen eins von: NO OUTPUT, L-nach-R oder R-nach-L an. Diese Steuerungsmerker werden von der Anwendung gesetzt, welche das Unicode-Codeumwandlungssystem 400 aufruft (d. h. Steuerungsmerker sind Eingaben in den Umwandler). In dem Fall, wenn die Steuerungsmerker R-nach-L anzeigen, wird die globale Richtung auf R-nach-L gesetzt 1604. Wenn die Steuerungsmerker auf L-nach-R gesetzt werden, wird die globale Richtung auf L-nach-R gesetzt. Wenn die Steuerungsmerker auf NO OUTPUT gesetzt werden, dann wird eine kleine Schleife initiiert, um die Unicode-Zeichen der Eingabezeichenfolge abzufragen, bis die Richtung bestimmt werden kann. Die Schleife beginnt mit dem Setzen 1608 des Zustands auf "START ZUSTAND". Danach wird ein Unicode-Zeichen von der Eingabezeichenfolge erhalten 1610. Die Attribute für das Unicode-Zeichen werden dann gesucht 1612. Die Attribute werden unter Verwendung desselben Verlaufs gesucht; wie er in Block 914 in Abb. 9A durchgeführt und in Einzelheiten in Abb. 12 beschrieben wird. Die Richtung des Unicode-Zeichens wird dann unter Verwendung der Attribute (nämlich des Richtungsattributes) bestimmt 1614. Dann wird eine Entscheidung 1616 auf der Basis getroffen, ob die Richtung gleich "NO_OUTPUT" ist. Wenn die Richtung "NO_OUTPUT" ist, dann wird eine Entscheidung 1618 auf der Basis getroffen, ob das Ende der. Eingabezeichenfolge erreicht wurde. Wenn das Ende der Eingabezeichenfolge nicht erreicht wurde, springt die Verarbeitung zur Wiederholung der Blöcke 1610-1618 zurück. Wenn einmal das Ende der Zeichenfolge erreicht ist, bewirkt die Entscheidung 1618, daß die spezielle Richtungsabfrageschleife beendet wird, ohne die Richtung zu finden (z. B. NO_OUTPUT). Alternativ wird die Abfrageschleife beendet, wenn die Entscheidung 1616 die Richtung bestimmt.
In jedem Fall wird nach der Richtungsverarbeitung, welche mit der Verzweigungsoperation 1602 verbunden ist, eine Verzweigungsoperation 1620 basierend auf der Richtung aufgerufen. Wenn die bestimmte Richtung "NO_OUTPUT" ist, dann wird die laufende Stufe auf integrierten Tiefstpunkt gesetzt 1622. Wenn auf der anderen Seite die Richtung L-nach-R ist, dann wird die laufende Stufe auf 1 gesetzt, die vorherige Stufe wird auf den Tiefstpunkt gesetzt und der Prioritätszustand wird auf neutral gesetzt 1626. Die Stufen beziehen sich auf Integrierungsstufen, wie in The Unicode Standard beschrieben. Obwohl die spezielle Richtungsabifageschleife (z. B. 1610-1618) der Verarbeitung zur Bestimmung der Anfangsrichtung 1600 als eine separate Schleife in Abb. 18 illustriert ist, könnte die gesamte Systemverarbeitungsefflzienz verbessert werden, indem die spezielle Richtungsabfrageschleife in die Hauptrichtungsabfrageschleife integriert wird.
Abb. 19 ist ein Fließbild der Textelementsuchverarbeiturig 1630. Die Textelementsuchverarbeitung 1630 wird von der Suchvorrichtung 412 durchgeführt und wird von dem Block 708 innerhalb der Unicodeumwandlerverarbeitung 700 (Abb. 7) aufgerufen. Die Textelementsuchverarbeitung 1630 beginnt damit, eine Variantenliste nach einem Eintrag abzusuchen 1632, welcher zu aktuellen Attributen und der geforderten Variante paßt. Die Suche 1632 nach der Variante wird in Einzelheiten unten unter Bezugnahme auf Abb. 24 beschrieben.
Danach wird eine Entscheidung 1634 auf der Basis getroffen, ob eine Entsprechung gefunden wurde. Wenn keine Entsprechung gefunden wurde, führt dies zu einem Fehler 163 6. Wenn auf der anderen Seite eine Entsprechung gefunden wird, dann wird die entsprechende Bitmaske aus der Variantenliste erhalten 1638. Vorzugsweise weist die Variantenliste drei Felder auf: eine Variantenidentifizierung, einen Satz Attribute und eine Bitmaske. Wenn die Variantenidentifizierung und der Satz Attribute innerhalb der Variantenliste zu den aktuellen Attributen und der geforderten Variante passen, dann wird die entsprechende Bitmaske aus der Variantenliste ausgewählt. Nach Block 1638 wird die Bitmaske mit einer Toleranzbitmaske kombiniert 1640, um Auswahlmerker zu erzeugen. Die Auswahlmerker bilden die Auswahlmaske, welche bei der Auswahl der Untertabellen der Abbildungstabelle 414 verwendet wird, wie oben diskutiert wurde. Vorzugsweise ist das Kombinieren 1640 in dem zweiten Aspekt der Erfindung eine bitweise Operation. Vorzugsweise ist das Kombinieren 1640 in dem ersten, dritten und vierten Aspekt der Erfindung eine bitweise OR-Operation. Danach wird eine Entscheidung 1642 auf der Basis getroffen, ob es eine Tabelle innerhalb der Abbildungstabelle 414 gibt für die Länge des laufenden Textelementes. Wenn nicht, führt dies zu einem Fehler 1644. Wenn es auf der anderen Seite eine Tabelle für die Länge des laufenden Textelementes gibt, werden die Suchtabelle und ihr Format für die Länge des laufenden Textelementes erhalten 1644. Dann wird eine Verzweigungsoperation 1648 an dem Format durchgeführt. Die in dieser Implementierung erhältlichen Formate sind: Liste, Segmentdatenbereich, Reihe und Kette. Wenn das Format ein Listenformat ist, dann wird die Listenformatverarbeitung 1650 durchgeführt. Wenn das Format ein Segementdatenbereich ist, dann wird die Verarbeitung für den Segmentdatenbereich 1652 durchgeführt. Wenn das Format eine Reihe ist, dann wird die Reihenformatverarbeitung 1654 durchgeführt. Wenn das Format eine Kette ist, dann wird die Kettenformatverarbeitung 1656 durchgeführt. Nach den Blöcken 1650-1656 wird das Ergebnis zurückgeführt 1658, wodurch die Textelementsuchverarbeitung 163() beendet wird.
Bezüglich des ersten Aspekts der Erfindung ist Abb. 20 ein Fließbild der Kettenformatverarbeitung 1660. Die Kettenformatverarbeitung 1660 ist eine Verarbeitung, welche von der in Abb. 19 gezeigten Kettenformatverarbeitung durchgeführt wird.
Die Kettenformatverarbeitung 1660 erhält 1662 eine Kettenzählung der Anzahl von Tabellen in der Kette. Die laufende Zählung wird dann auf Null gesetzt 1664. Danach wird eine Entscheidung 1666 auf der Basis getroffen, ob die laufende Zählung größer als oder gleich der Kettenzählung ist. Wenn die laufende Zählung größer als oder gleich der Kettenzählung ist, dann springt die Kettenformatverarbeitung 1660 zurück 1668, wobei ein Fehler angezeigt wird, da kein Ergebnis gefunden wurde. Andernfalls, wenn die laufende Zählung nicht größer als oder gleich der Kettenzählung ist, dann werden die laufende Suchtabelle und ihr Format erhalten 1670. Die in dieser Implementierung verwendeten Formate sind dieselben wie die in Abb. 19 benutzten. Eine Verzweigungsoperation 1672 wird dann basierend auf dem Format durchgeführt. Wenn das Format eine Liste ist, dann wird die Listenformatverarbeitung 1674 durchgeführt. Wenn das Format ein Segementdatenbereich ist, dann wird die Verarbeitung für den Segmentdatenbereich 1676 durchgeführt. Wenn das Format eine Reihe ist, dann wird die Reihenformatverarbeitung 1680 durchgeführt. Wenn das Format eine Kette ist, dann wird die Kettenformatverarbeitung 1682 durchgeführt. Nach den Blöcken 1614-1622 wird die laufende Zählung erhöht 1684. Dann wird eine Entscheidung 1686 auf der Basis getroffen, ob ein Ergebnis gefunden wurde. Wenn kein Ergebnis gefunden ist, dann geht die Kettenformatverarbeitung 1660 in einer Schleife zurück zu Entscheidungsblock 1666, um die nächste Suchtabelle innerhalb der Kette von Tabellen abzusuchen. Wenn die Entscheidung 1686 jedoch bestimmt, daß das Ergebnis gefunden wurde, dann wird das Ergebnis zurückgeführt 1688, wodurch die Kettenformatverarbeitung 1660 beendet wird.
Bezüglich des ersten Aspekts der Erfindung ist Abb. 21 ein Fließbild der Reihenfomxatverarbeitung 1700. Die Reihenformatverarbeitung 1700 ist die Verarbeitung, welche von Block 1654 in Abb. 19 und Block 1678 in Abb. 20 durchgeführt wird. Das Reihenformat ist eine Liste von Zeichenreihen mit einem Deltawert, welcher jedem Feld zugeordnet ist.
Die Reihenformatverarbeitung 1700 beginnt mit einer Entscheidung 1702 auf der Basis, ob die Untergruppenmerker für diese Untertabelle zu den Auswahlmerkern passen. Die Auswahlmerker sind für die Auswahlmaske und die Untergruppenmerker sind für die Untertabellenmaske. Wenn nicht, springt die Reihenformatverarbeitung 1704 zurück, wobei sie unter Verwendung eines Fehlercodes anzeigt, daß kein Ergebnis gefunden wurde. Wenn auf der anderen Seite die Entscheidung 1702 anzeigt, daß die Untergruppenmerker für diese Untertabelle zu den Auswahlmerkern passen, dann wird eine Entscheidung 1706 auf der Basis getroffen, ob die Länge des Textelementes größer als eins ist. Wenn die Länge des Textelementes größer als eins ist, dann wird dieses Format fehlerhafterweise ausgewählt, da die Anordnung der Abbildungstabellen für diese bestimmte Implementierung derart ist, daß das Reihenformat nur für ein Textelement mit einer Länge von eins ist. Wenn das Textelement somit größer als eins ist, dann wird Block 1704 durchgeführt, um zu der Anzeige zurückzukehren, daß kein Ergebnis gefunden wurde. Wenn auf der anderen Seite die Textelementlänge nicht größer als eins ist, fährt die Reihenformatverarbeitung 1700 fort. Eine Untertabelle mit dem Reihenformat hat einen Datenbereich aus Reihen, wobei jede Reihe einen ihr zugeordneten Deltawert aufweist. Der Reihendatenbereich wird dann abgesucht 1708, um die geeignete Reihe für das umzuwandlende Unicode-Zeichen zu finden. Dann wird eine Entscheidung 1710 auf der Basis getroffen, ob eine Reihe gefunden wurde. Wenn keine Reihe gefunden wurde, dann springt die Reihenformatverarbeitung 1700 zurück zu 1704, wobei unter Verwendung eines Fehlercodes angezeigt wird, daß kein Ergebnis gefunden wurde. Wenn jedoch eine Reihe gefunden ist, dann wird der entsprechende Deltawert für die Reihe erhalten 1712. Der Deltawert wird dann dem Unicodewert hinzugefügt 1714. Danach wird das Ergebnis einer Ausgabefolge zugeordnet 1716. Die mit der Zuordnung 1716 des Ergebnisses zu der Ausgabefolge verbundene Verarbeitung wird in Einzelheiten unten unter Bezugnahme auf die Abb. 22A-22C erläutert. Nach Block 1716 ist die Reihenformatverarbeitung 1700 beendet und springt zurück.
Bezüglich des ersten Aspekts der Erfindung ist Abb. 22 ein Fließbild der Listenformatverarbeitung 1800. Die Listenformatverarbeitung 1800 ist die Verarbeitung, welche von Block 1650 in Abb. 19 und Block 1674 in Abb. 20 durchgeführt wird. Das Listenformat ist eine geordnete Liste von Textelementen und der Index I in die geordnete Liste ist ein Index in eine entsprechende Liste von Suchzielzeichen.
Die Listenformatverarbeitung 1800 beginnt mit einer Entscheidung 1802 auf der Basis, ob die Untergruppenmerker für diese Untertabelle zu den Auswahlmerkern passen. Wenn nicht, wenn nicht, springt die Listenformatverarbeitung 1800 zurück zu 1804, wobei sie unter Verwendung eines Fehlercodes anzeigt, daß kein Ergebnis gefunden wurde. Wenn auf der anderen Seite die Untergruppenmerker für diese Untertabelle zu den Auswahlmerkern passen, dann wird eine optimierte binäre Suche an den Textelementen in der Liste durchgeführt 1806. Dann wird eine Entscheidung 1808 auf der Basis getroffen, ob die Suche ein Textelement in der Liste gefunden hat. Wenn nicht, springt die Listenverarbeitung wieder zurück 1804, wobei angezeigt wird, daß keine Zuordnung gefunden wurde. Wenn das Textelement jedoch gefunden ist, dann wird der Index i, bei welchem das Textelement gefunden wurde, erhalten 1810. Der Index i wird dann benutzt, um ein Suchzielzeichen zu erhalten 1812. Das Suchzielzeichen wird dann der Ausgabefolge zugeordnet 1814. Die Listenformatverarbeitung 1800 ist dann beendet und springt zurück.
Bezüglich des ersten Aspekts der Erfindung illustrieren die Abb. 23A und 23B die Verarbeitung des Segmentdatenbereichformates 1900. Die Verarbeitung des Segmentdatenbereichformates 1900 ist die Verarbeitung, welche von Block 1652 in Abb. 19 und Block 1676 in Abb. 20 durchgeführt wird. Das Segmentdatenbereichformat beinhaltet einen ersten Textelementdatenbereich, einen letzten Textelelementdatenbereich und einen Offsetdatenbereich. Die Offsets in dem Offsetdatenbereich zeigen auf verschiedene Listen von Suchzielzeichen.
Die Verarbeitung für das Segmentdatenbereichformat 1900 beginnt mit einer Entscheidung 1901 auf der Basis, ob die Untergruppenmerker für diese Untertabelle zu den Auswahimerkern passen. Wenn die Untergruppenmerker zu den Auswahlmerkern passen, dann wird eine optimierte Suche durchgeführt 1902. Die optimierte Suche findet den kleinsten Eintrag in dem letzten Textelelementdatenbereich, welcher größer als oder gleich den gesuchten Textelementen ist, und erhält den Index i für diesen Eintrag. Danach wird eine Entscheidung 1904 auf der Basis getroffen, ob der ite Eintrag in dem ersten Textelementdatenbereich kleiner als oder gleich dem gesuchten Textelement ist. Wenn nicht, springt die Verarbeitung für das Segmentdatenbereichformat 1900 zurück zu 1906, wobei ein Fehlercode anzeigt, daß keine Zuordnung gefunden wurde. Auch in dem Fall, in welchem die Entscheidung 1901 fehlschlägt, wird der Block 1906 auch durchgeführt. Wenn auf der anderen Seite die Entscheidung 1904 anzeigt, daß der ite Eintrag in dem ersten Textelementdatenbereich kleiner als oder gleich dem gesuchten Textelement ist, dann ist klar, daß der ite Eintrag dem gesuchten Textelement entspricht. Dann wird eine Liste mit Suchzielzeichen über den iten Eintrag in dem Offsetdatenbereich erhalten 1908. Dies bedeutet, daß der von dem iten Eintrag in dem Offsetdatenbereich gelieferte Offset die Liste der Suchzielzeichen identifiziert. Ein Index j in die Liste der Suchzielzeichen wird dann bestimmt 1910. Dem Index j wird der Wert des gesuchten Textelementes abzüglich des ersten Textelementes in der erhaltenen Liste (oder Reihe) der Suchzielzeichen gegeben 1908. Das Suchzielzeichen mit Index j wird dann aus der Liste der Suchzielzeichen erhalten 1912. Dann wird eine Entscheidung 1914 auf der Basis getroffen, ob das Suchzielzeichen gleich Null ist. Wenn das Suchzielzeichen gleich Null ist, dann springt die Verarbeitung für das Segmentdatenbereichformat zurück 1916, wobei unter Verwendung eines Fehlercodes angezeigt wird, daß keine Zuordnung gefunden wurde. Wenn auf der anderen Seite das Suchzielzeichen nicht gleich Null ist, dann wird das Suchzielzeichen der Ausgabefolge zugeordnet 1918. Nach Block 1918 ist die Verarbeitung für das Segmentdatenbereichformat 1900 beendet und springt zurück.
Abb. 24 ist ein Fließbild, welches die Verarbeitung für die Suchvariantenliste 2000 illustriert. Die Verarbeitung für die Suchvariantenliste 2000 ist die Verarbeitung, welche von Block 1632 in Abb. 19 durchgeführt wird. Mit anderen Worten ist die Verarbeitung für die Suchvariantenliste 2000 Teil der Verarbeitung für das Suchen des Textelementes 1630, welche von der Suchvorrichtung 412 in Verbindung mit der Abbildungstabelle 414 durchgeführt wird.
Die Verarbeitung für die Suchvariantenliste 2000 erhält 2002 eine Gesamtzählung der Elemente in der Variantenliste. Dann wird die laufende Zählung auf Null initialisiert 2004. Dann wird eine Entscheidung 2006 auf der Basis getroffen, ob die laufende Zählung größer als und gleich der Gesamtzählung ist. Wenn die laufende Zählung größer als oder gleich der Gesamtzählung ist, dann springt die Verarbeitung für die Suchvariantenliste 2000 zuruck zu 2008, wobei ein Fehlercode anzeigt, daß die Variante nicht gefunden ist. Wenn auf der anderen Seite die laufende Zählung nicht größer als oder gleich der Gesamtzählung ist, dann wird eine Entscheidung 2010 auf der Basis getroffen, ob der Eintrag in die Variantenliste, welcher der laufenden Zählung zugeordnet ist, zu den aktuellen Attributen und der gesuchten. Variante paßt. Wenn sie zusammenpassen, dann werden die Variantenmerker von dem Eintrag in die Variantenliste zurückgeführt 2012. Andernfalls wird die laufende Zählung erhöht 2014 und dann springt die Verarbeitung zu Block 2006 zurück, um fortzufahren, die Schleife durch die verfügbaren Varianten in der Variantenliste zu durchlaufen, bis entweder eine paßt oder alle Varianten berücksichtigt sind.
Die Abb. 25A und 25B sind schematische Diagramme der Variantenliste 2100. Wie in Abb. 25A gezeigt, beinhaltet die Variantenliste 2100 einen Variantenbereich 2102, einen Bereich der gewünschten Attribute 2104 und einen Bereich der Variantenmerker 2106. Abb. 25B illustriert eine aktuelle Attributebitmaske in Übereinstimmung mit einer bevorzugten Implementierung. Die aktuelle Attributebitmaske 2108 ist eine 32-Bit-Variable mit einem ersten Abschnitt 2110 (Bits 0 und 1), welcher den symmetrischen Swappingzustand anzeigt, einem zweiten Abschnitt 2112 (Bits 2 und 3), welcher vertikale oder horizontale Formen anzeigt, einem dritten Abschnitt 2114 (Bits 8 und 9), welcher die aufgelöste Richtung anzeigt, und einem vierten Abschnitt 2116 (Bits 16-19), welcher den Kontext anzeigt. Bezüglich des dritten Aspekts der Erfindung werden die Bits des vierten Abschnitts 2116 von der Kontextmaske gesetzt, welche in der Kontextverarbeitung 984 (Abb. 10C). Ferner bezüglich des ersten bis vierten Aspekts der Erfindung stellt jedes Bit innerhalb eines Abschnitts einen Merker dar. Die Bits enthalten den Wert "0", wenn der Merker unbekannt oder nicht gesetzt ist, und sie enthalten den Wert "1", wenn sie gesetzt sind. Die Aufrufeinrichtung setzt den zweiten Abschnitt 2110 und die Abifageeinrichtung 408 setzt den ersten, dritten und vierten Abschnitt 2110, 2114 und 2116.
Eine gewünschte Attributebitmaske ist formatiert wie die aktuelle Attributebitmaske, aber sie setzt die Bits abhängig davon, welches der Attribute wichtig ist, um die korrekte Zuordnung Ihr die bestimmte Tabelle und Variante zu erhalten (wie von der Gestaltung der Abbildungstabelle 414 bestimmt). Die Bits in der gewünschten Attributebitmaske werden für jedes Attribut auf "1" gesetzt, welches bei dem Verfahren der Zuordnungsbestimmung zu berücksichtigen ist, aber wenn alle Bits eines Abschnitts auf "1" gesetzt werden, wird das Attribut während der Zuordnung ignoriert. Wenn beispielsweise Bit 0 "1" ist und Bit 1 "0" ist, dann ist das symmetrische Swapping aktiviert und wird während der Durchführung der Zuordnung berücksichtigt. Wenn auf der anderen Seite beide Bits 0 und 1 "1" sind, wird das symmetrische Swapping vollständig ignoriert. Die restlichen unbenutzten Bits der gewünschten Attributebitmaske werden auf "L" gesetzt, und später können ihnen bei Bedarf Werte zugeordnet werden. Einige Beispiele für die gewünschte Attributebitmaske folgen.
Angenommen, die Richtung ist links nach rechts und keines der anderen Attribute ist wichtig. Dann wäre die gewünschte Attributebitmaske: xFFFFFDFF. Wohingegen, wenn die Richtung rechts nach links ist mit aktiviertem symmetrischen Swapping, dann wäre die gewünschte Attributebitmaske: xFFFFFEFD. Wenn die Richtung rechts nach links ist mit deaktiviertem symmetrischen Swapping, dann wäre die gewünschte Attributebitmaske: XFFFFFEFE. Mit jeder der o. g. unterschiedlichen gewünschten Attributebitmasken kann ein anderer Umwandlungscode ausgewählt werden. Beispielsweise bei der Zuordnung des Unicode-Zeichens u0028 zu MacArabic liefert x28 die gewünschte Attributebitmaske xFFFFFDFF, xA8 die gewünschte Attributebitmaske xFFFFFEFD und xA9 die gewünschte Attributebitmaske XFFFFFEFE.
Bezüglich des ersten Aspekts der Erfindung sind die Abb. 26A, 26B und 26C Fließbilder, welche die Verarbeitung für die Zuordnung eines Suchzielzeichens zu einer Ausgabefolge 2200 illustrieren. Die Verarbeitung für die Zuordnung eines Suchzielzeichens zu einer Ausgabefolge 2200 ist mit Block 1814 in Abb. 22 und Block 1918 in Abb. 23A verbunden.
Die Verarbeitung für die Zuordnung eines Suchzielzeichens zu einer Ausgabefolge 2200 beginnt mit einer Entscheidung 2202 auf der Basis, ob Richtungslosigkeit zulässig ist. Wenn Richtungslosigkeit nicht zulässig ist, dann wird das Suchzielzeichen in die Ausgabefolge in "Charsize"-Blöcken kopiert 2204. "Charsize" bezieht sich auf die Mindestgröße eines Zeichens in der Zielcodierung und wird in der Kopfreile 500 der Abbildungstabelle 414 spezifiziert. Nach Block 2204 ist die Verarbeitung 2200 beendet und springt zurück zu 2206, wobei angezeigt wird, daß ein Ergebnis gefunden wurde. Wenn auf der anderen Seite Entscheidung 2202 bestimmt, daß Richtungslosigkeit zulässig ist, dann wird eine Entscheidung 2208 auf der Basis getroffen, ob das hohe Bit des Suchzielzeichens gleich eins ist. Wenn das hohe Bit nicht gleich eins ist, dann wird eine Entscheidung 2210 auf der Basis getroffen, ob das erste Byte eine Nullausgabefolge (d. h. eine Ausgabefolge mit der Länge 0) anzeigt. Wenn das erste Byte x7F anzeigt, dann wird eine Nullausgabefolge angezeigt 2212 (eine Zuordnung gefunden, aber es werden keine Zeichen zu der Ausgabefolge hinzugefügt). Ansonsten, wenn das erste Byte keine Nullausgabefolge anzeigt, werden "Charsize"-Blöcke in die Ausgabefolge kopiert 2214. In diesem Fall zeigt das erste Byte vorzugsweise die Länge der Ausgabefolge an. Nach den Blöcken 2212 und 2214 wird Block 2206 durchgeführt, um dadurch die Verarbeitung 2200 zu beenden und rückzuspringen, wobei ein gefundenes Ergebnis angezeigt wird.
In dem Fall jedoch, wo die Entscheidung 2208 bestimmt, daß das hohe Bit des Suchzielzeichens gleich eins ist, dann ist eine zusätzliche Verarbeitung erforderlich, da das Suchzielzeichen einen indirekten Hinweis auf die gewünschte Ausgabefolge liefert. Insbesondere wird ein Offset zu einer indirekten Folge unter Verwendung des restlichen Abschnitts des Suchzielzeichens spezifiziert 2216. Dann wird eine Entscheidung 2218 auf der Basis getroffen, ob das hohe Bit des restlichen Abschnitts des Suchzielzeichens gleich eins ist. Wenn nicht, dann werden "Charsize"-Blöcke in die Ausgabefolge kopiert 2220, und dann wird die Verarbeitung 2200 beendet, indem sie eine Anzeige, daß die Zuordnung gefunden wurde, rückspringen läßt 2222. Wenn auf der anderen Seite bestimmt wird 2218, daß das hohe Bit des restlichen Abschnitts des Suchzielzeichens gleich eins ist, dann wird eine Zählung von Folgen in der sequentiellen Kette erhalten 2224, und eine lineare Suche 2226 wird durch die Folgen durchgeführt, um eine Zuordnung zu identifizieren. Nach Block 2226 werden zuvor beschriebene Blöcke 2220 und 2222 durchgeführt.
Abb. 26C erläutert in Einzelheiten die von Block 2226 in Abb. 26B durchgeführten Operationen. Es wird daran erinnert, daß Block 2226 in Abb. 26C eine lineare Suche durch die Folgen durchführt. Zu Anfang wird die laufende Zählung auf Null gesetzt 2228. Eine Entscheidung 2230 wird auf der Basis getroffen, ob die laufende Zählung größer als oder gleich der Folgenzählung ist. Wenn die laufende Zählung größer als oder gleich der Folgenzählung ist, dann springt die Zuordnung des Suchzielzeichens zu der Ausgabefolge 2200 zurück 2232 mit einer Anzeige, daß die Zuordnung nicht gefunden wurde. Wenn auf der anderen Seite die laufende Zählung nicht größer als oder gleich der Folgenzählung ist, dann werden eine nächste Ausgabefolge und ihre Folgenmaske erhalten 2234. Die Folgenmaske ist eine Maske, welche benutzt wird, um eine oder mehrere Ausgabenfolgen auszuwählen. Dann wird eine Entscheidung 2236 auf der Basis getroffen, ob die Untergruppenmerker benutzt werden. Wenn die Untergruppenmerker nicht benutzt werden, dann bestimmt eine Entscheidung 2238, ob die aktuellen Attribute, welche logisch mit einer UND-Verbindung mit der Folgenmaske verbunden sind, bitweise gleich den aktuellen Attributen sind. Wenn ja, führt die Verarbeitung die zuvor beschriebenen Blöcke 2220 und 2222 durch, da die Zuordnung gefunden wurde. Wenn die Entscheidung 2236 jedoch bestimmt, daß die Untergruppenmerker verwendet werden, dann wird eine Entscheidung 2240 auf der Basis getroffen, ob die Auswahlmerker, welche logisch mit einer UND-Verbindung mit der Folgenmaske verbunden sind, bitweise gleich der Folgenmaske sind. Wenn ja, werden die zuvor beschriebenen Blöcke 2220 und 2222 durchgeführt, da die Zuordnung gefunden wurde. Somit stellen die Blöcke 2238 und 2240 zwei verschiedene Wege dar, die korrekte Ausgabefolge zu erhalten. Wenn auf der anderen Seite entweder der Entscheidungsblock 2238 oder 2240 anzeigt, daß die laufende Folge nicht die korrekte Zuordnung ist, dann wird die laufende Zählung erhöht 2242 und die Verarbeitung geht zu Block 2230 zurück, um die Operationen für die nächste Folge in der Kette zu wiederholen.
Abb. 27 ist ein Fließbild, welches die Ersatzvorrichtungsverarbeitung 2300 in Übereinstimmung mit der Erfindung illustriert. Die Ersatzvorrichtungsverarbeitung 2300 ist die Verarbeitung, welche von der Ersatzvorrichtung 416 durchgeführt und von Block 716 der in Abb. 7 gezeigten Unicdoeumwandlerverarbeitung 700 aufgerufen wird.
Die Ersatzvorrichtungsverarbeitung 2300 sucht 2302 das Textelement mit Ersatzoptionen. Die Suche 2302 ist ähnlich der Verarbeitung für die Textelementsuche 1630, welche oben bezüglich Abb. 19 beschrieben wurde. Der einzige wesentliche Unterschied besteht darin, daß jetzt die Ersatzoptionen gesetzt werden, so daß zusätzliche Untertabellen über die Auswahlmerker, welche sich geändert haben, berücksichtigt werden. Danach wird eine Entscheidung 2304 auf der Basis getroffen, ob ein Umwandlungscode für das Textelement gefunden wurde. Wenn ein Umwandlungscode gefunden wurde, dann wird ein Fehlercode gesetzt 2306, um anzuzeigen, welcher Ersatz benutzt wurde, um die Umwandlung oder Zuordnung zu erhalten. Nach Block 2306 ist die Ersatzvorrichtungsverarbeitung 2300 beendet und springt zurück.
Wenn auf der anderen Seite die Bestimmung 2304 anzeigt, daß der Umwandlungscode nicht gefunden wurde, dann wird eine Verzweigungsoperation 2308 basierend auf den Ersatzoptionen durchgeführt. Die Ersatzoptionen sind: Standard, Aufrufer definiert, Standard gefolgt von Aufrufer definiert, oder Aufrufer definiert gefolgt von Standard. Wenn die Ersatzoption Standard ist, dann bewirkt die Verzweigungsoperation 2308, daß die Standardverarbeitung 2310 durchgeführt wird. Wenn die Ersatzoption Aufrufer definiert ist, dann bewirkt die Verzweigungsoperation 2308, daß die Verarbeitung für Aufrufer definiert 2312 durchgeführt wird. Wenn die Ersatzoption Standard gefolgt von Aufrufer definiert ist, dann bewirkt die Verzweigungsoperation 2308, daß die Standardverarbeitung durchgeführt wird 2314, gefolgt von einer Entscheidung 2316 und einer Verarbeitung für Aufrufer definiert 2318. Die Entscheidung 2316 leitet die Verarbeitung für Aufrufer definiert 2318 um, wenn eine Standardverarbeitung 2314 erfolgreich ist. Wenn die Ersatzoption Aufrufer definiert ist, gefolgt von der Standardverarbeitung, dann bewirkt die Verzweigungsoperation 2308, daß die Verarbeitung für Aufrufer definiert durchgeführt wird 2330, gefolgt von einer Entscheidung 2322 und der Standardverarbeitung 2324. Die Entscheidung 2322 leitet die Standardverarbeitung 2324 um, wenn die Verarbeitung für Aufrufer definiert 2320 erfolgreich ist. Nach der mit der Verzweigungsoperation 2308 verbundenen Verarbeitung wird eine Entscheidung 2326 auf der Basis getroffen, ob die Ersatzverarbeitung 2300 erfolgreich eine Zuordnung oder einen Umwandlungscode identifiziert hat. Wenn die Ersatzverarbeitung 2300 nicht erfolgreich war, dann wird eine Standardersatzzeichenfolge für den Zeichensatz erhalten 2328. Die Standardersatzzeichenfolge besteht aus dem (den) Umwandlungscode(s), welcher benutzt wird, wenn die Ersatzsuche 2302 keinen Umwandlungscode identifizieren kann. Vorzugsweise ist die Standardersatzzeichenfolge in der Kopfzeile der Abbildungstabellen 414 enthalten. Für ASCII beispielsweise ist das Standardersatzzeichen typischerweise "?". Dann nach Block 2328 oder nach Entscheidungsblock 2326 wird in dem Fall, wenn die Ersatzverarbeitung erfolgreich beim Erhalt einer Zuordnung oder eines Umwandlungscodes war, ein Fehlercode gesetzt 2306, um anzuzeigen, das Ersatzoptionen benutzt wurden, und die Ersatzvorrichtungsverarbeitung 2300 ist beendet und springt zurück.
Abb. 28 ist ein Fließbild, welches die Standardverarbeitung 2400 illustriert. Die Standardverarbeitung 2400 ist mit der Verarbeitung verbunden, welche von den Blöcken 2310, 2314 und 2324 in Abb. 27 durchgeführt wird.
Eine Standardverarbeitung 2400 setzt zu Anfang 2402 eine laufende Zählung auf Null. Danach wird eine Entscheidung 2404 auf der Basis getroffen, ob die laufende Zählung größer als oder gleich der Textelementlänge ist. Wenn dies so ist, dann ist die Standardverarbeitung 2400 beendet und springt zurück. Andernfalls wird eine Suchverarbeitung 2406 für ein einziges Unicode-Zeichen durchgeführt, wobei Ersatzmerker gesetzt werden. Hierbei zielt die Suche auf einzelne Zeichen des Textelementes ab, wohingegen sich die Suche zuvor (Block 2302) auf das gesamte Textelement bezog. Dann wird eine Entscheidung 2408 auf der Basis getroffen, ob ein Umwandlungscode für das einzige Unicode-Zeichen gefunden wurde. Wenn nicht, dann springt die Standardverarbeitung 2400 zurück 2410, wobei ein Fehlercode anzeigt, daß keine einzelne Zuordnung für das Unicode-Zeichen erhältlich war. Wenn auf der anderen Seite ein Umwandlungscode gefunden wurde, dann wird die laufende Zählung erhöht 2412 und die Verarbeitung springt zu Block 2404 zurück für die Verarbeitung des nächsten Unicode-Zeichens innerhalb des Textelementes.
Obwohl die oben diskutierten Abb. 4-28 die Umwandlung aus dem Unicode in eine Zielcodierung (Aus-Unicode) betreffen, ist das Unicode-Codeumwandlungssystem 300, wie oben erwähnt, ebensogut in der Lage, aus einer anderen Primärcodierung in den Unicode umzuwandeln (In-Unicode). Die In-Unicode-Verarbeitung ist ähnlich der Verarbeitung für Aus- Unicode, aber sie ist wesentlich weniger komplex. Die In-Unicode-Verarbeitung muß gewöhnlich die Textelemente nicht abfragen oder mehrfache Zeichenfolgen absuchen, um die Zielcodierungen zu bestimmen. Stattdessen muß die In-Unicode-Verarbeitung nur die Primärzeichenfolge in einzelne Zeichen unterteilen und dann den entsprechenden Codepunkt in dem Unicode finden. In dem seltenen Fall jedoch, wo eine Zuordnung für ein Zeichen von dem Zeichen, welches ihm nachfolgt, beeinflußt werden kann (z. B. Indische Schriftarten wie Devanagari) kann eine Abfragung, wie oben diskutiert, durchgeführt werden.
Abb. 29 illustriert ein Blockdiagramm einer Ausführung eines Unicode- Codeumwandlungssystems 2500 gemäß der Erfindung. Das Unicode-Codeumwandlungssystem 2500 wandelt in den Unicode um (d. h. In-Unicode-Verarbeitung). Das Unicode- Codeumwandlungssystem 2500 umfaßt einen In-Unicode-Umwandler 2502, welcher eine Primärzeichenfolge 2504 empfängt und eine Unicode-Zeichenfolge 2506 herstellt. Der In- Unicode-Umwandler 2502 führt das Codeumwandlungsverfahren über den In-Unicode- Umwandler 2502 durch, welcher mit einer Abfrageeinrichtung 2508 zusammenwirkt. Die Abifageeinrichtung 2508 fragt in Verbindung mit einer Abfragetabelle 2510 die Primärzeichenfolge 2504 ab, um die Primärzeichenfolge 2504 in Zeichen zu zerlegen. Hierbei wird, im Gegensatz zu der Aus-Unicodesituation, die Primärzeichenfolge einfach in einzelne Zeichen unterteilt. Der In-Unicode-Umwandler 2502 benutzt dann eine Suchvorrichtung 2512, um die einzelnen Zeichen zu suchen, um die Unicode-Codierungen dafür zu erhalten. Die Suchvorrichtung 2512 benutzt die Abbildungstabelle 2514, um das Zeichen in dem Unicode zu erhalten. Zusätzlich kann der In-Unicode-Umwandler 2502 auch eine Ersatzvorrichtung 2516 benutzen. Die Ersatzvorrichtung 2516 arbeitet zusammen mit der Abbildungstabelle 2514, um ein oder mehrere Zeichen in der Zielcodierung zu identifizieren, welche als eine Ersatzzuordnung für das Textelement in den Fällen benutzt werden können, wo die Suchvorrichtung 2512 nicht in der Lage war, ein Unicode-Zeichen zu identifizieren.
Die Abfrageeinrichtung 2508, die Abfragetabelle 2510, die Suchvorrichtung 2512, die Abbildungstabelle 2514, die Ersatzvorrichtung 2516, die Zustandsverwaltungsvorrichtung 2518 sind ähnlich, aber wesentlich weniger komplex als die entsprechenden Vorrichtungen in Abb. 4. Somit können diese Vorrichtungen so gestaltet werden, daß sie sowohl die In-Unicode- als auch die Aus-Unicode-Verarbeitung implementieren. Wenn ferner ein gegebenes Computersystem oder eine andere elektronische Vorrichtung in der Lage ist, sowohl die In-Unicode- als auch die Aus-Unicode-Verarbeitung durchzuführen, kann das Computersystem oder die andere elektronische Vorrichtung als eine Buchse dienen. Die Buchse kann dann dazu dienen, zwischen verschiedenen nationalen Zeichensätzen, welche Unicode-gestützt sind, umzuwandeln.
Beispielsweise würde ein nationaler Primärzeichensatz zuerst in den Unicode und dann in einen nationalen Zielzeichensatz umgewandelt werden.
Bezüglich des ersten Aspekts der Erfindung verwenden die oben beschriebenen Tabellen vorzugsweise die oben diskutierten Formate, um eine Komprimierung der innerhalb der Tabellen zu speichernden Daten vorzunehmen. Zusätzlich bezüglich des ersten Aspekts der Erfindung kann die Komprimierung signifikant sein, beispielsweise ist die Attributetabelle fünfzigmal (50 zu 1) kleiner in komprimierter Form. Bezüglich des ersten Aspekts der Erfindung werden jedoch die Fachleute erkennen, daß das Format der Tabellen viele Formen annehmen kann, wobei einige einfacher zu implementieren sind als andere. Die einfachste Implennentierung ist typischerweise eine Tabelle ohne irgendeine Komprimierung, obwohl dies die meiste Datenspeicherung erfordert. Ferner bezüglich des ersten Aspekts der Erfindung, könnte, obwohl Tabellen in den oben diskutierten Implementierungen verwendet werden, das von diesen Tabellen bewirkte Verhalten stattdessen direkt codiert werden. Eine direkte Codierung würde jedoch die Änderung der Funktionsweise des Codeumwandlungssystems schwierig machen, wohingegen bei typischen Tabellen nur die Tabellen geändert werden müßten, um solche Änderungen zu implementieren.
Die vielen Eigenschaften und Vorteile der vorliegenden Erfindung gehen aus der niedergeschriebenen Beschreibung hervor, und somit ist beabsichtigt, mit den anhängenden Ansprüchen alle diese Eigenschaften und Vorteile der Erfindung abzudecken. Da ferner zahlreiche Modifizierungen und Änderungen den Fachleuten leicht in den Sinn kommen werden, ist nicht beabsichtigt, die Erfindung auf genau die Bauweise und Funktionsweise zu begrenzen, welche illustriert und beschrieben ist. Somit können alle geeigneten Modifizierungen und Äquivalente als in den Rahmen der Erfindung fallend betrachtet werden.

Claims

1. Verfahren zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge, wobei das Verfahren aufweist:

(a) Empfang einer Primärzeichenfolge mit einer ersten Zeichencodierung;

(b) sequentielle Unterteilung der Primärzeichenfolge in Textelemente, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge umfaßt;

(c) Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente in einer Abbildungstabelle; und

(d) Kombinieren der Umwandlungscodes für die Textelemente, um eine Zielzeichenfolge der zweiten Zeichencodierung zu bilden.

2. Verfahren gemäß Anspruch 1, wobei das Verfahren weiterhin aufweist:

(e) nach der Unterteilung (b), aber vor dem Suchen (e) Aufzeichnung bestimmter Zeichen innerhalb jedes Textelementes, wenn die bestimmten Zeichen in den Textelementen vorhanden sind.

3. Verfahren gemäß Anspruch 2, bei welchem die Aufzeichnung (e) vorzugsweise durchgeführt wird, indem Gewichtungswerte für die verschiedenen Zeichenklassen verwendet werden.

4. Verfahren gemäß Anspruch 1, bei welchem jedes der Zeichen eine ihm zugeordnete Zeichenklasse aufweist, und bei welchem die Unterteilung (b) wenigstens teilweise auf der Zeichenklasse der Zeichen innerhalb der Primärzeichenfolge basiert.

5. Verfahren gemäß Anspruch 1, bei welchem die Unterteilung (b) aufweist:

(b1) Erhalt eines nächsten Primärzeichens aus der Primärzeichenfolge;

(b2) Bestimmung, ob das erhaltene Primärzeichen in ein laufendes Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll;

(b3) Anordnung des Primärzeichens in das laufende Textelement oder das neue nächste Textelement in Übereinstimmung mit der Bestimmung (b2); und

(b4) Wiederholung von (b1) bis (b3) bis die Primärzeichenfolge vollständig in Textelementen angeordnet ist.

6. Verfahren gemäß Anspruch 5, bei welchem die Bestimmung (b2) aufweist:

(i) Suchen von dem Primärzeichen zugeordneten Attributen, wobei die Attribute wenigstens eine Klassenanzeige beinhalten; und

(ii) Bestimmung auf der Basis der Klassenanzeige, ob das erhaltene Primärzeichen in das laufende Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll.

7. Verfahren gemäß Anspruch 5, bei welchem die Bestimmung aufweist:

(i) Suchen von dem Primärzeichen zugeordneten Attributen, wobei die Attribute wenigstens eine Klassenanzeige beinhalten;

(ii) Bereitstellung eines Zustandsmoduls mit einer Vielzahl von Zuständen, wobei das Zustandsmodul für die Bestimmung, ob das erhaltene Primärzeichen in das laufende Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll, basierend auf der Klassenanzeige und einem laufenden Zustand des Zustandsmoduls verwendet wird; und

(iii) Aktualisierung des laufenden Zustands des Zustandsmoduls.

8. Verfahren gemäß Anspruch 1; bei welchem das Kombinieren (d) aufweist:

(d1) Bestimmung einer Zielzeichengröße für die zweiten Zeichencodierungen; und

(d2) Bildung der Zielzeichenfolge durch Kopieren der Umwandlungscodes für die Textelemente, welche gesucht worden sind, in die Zielzeichenfolge in Einheiten der Zielzeichengröße.

9. Verfahren gemäß Anspruch 8, bei welchem der gesuchte (c) Umwandlungscode eine Verschiebung zu einer indirekten Codierungssequenz spezifiziert:

10. Verfahren gemäß irgendeinem der Ansprüche 1-9, wobei das Verfahren weiterhin aufweist:

(e) vor dem Suchen (c) Bestimmung einer Richtung für die Primärzeichen der Primärzeichenfolge; wobei das Suchen (c) des der zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Primärzeichen in der Abbildungstabelle auf der ersten Zeichencodierung und der bestimmten Richtung basiert.

11. Verfahren gemäß Anspruch 10, bei welchem die Richtung jedes Primärzeichens eine von einer links_nach_echts-Richtung und einer rechts_nach_links-Richtung ist.

12. Verfahren gemäß Anspruch 10, bei welchem die Bestimmung (e) aufweist:

(e1) Bestimmung, ob die Richtung irrelevant ist; und

(e2) wenn die Richtung relevant ist, Bestimmung, ob die Richtung eine von einer links-nachrechts-Richtung und einer rechts nach links-Richtung ist.

13. Verfahren gemäß Anspruch 10, bei welchem die Bestimmung (e) die Richtung für die gesamte oder teilweise Primärzeichenfolge basierend auf der Richtung eines oder mehrerer Zeichen der Primärzeichenfolge bestimmt.

14. Verfahren gemäß Anspruch 10, bei welchem die Bestimmung (e) aufweist:

(ii) Bestimmung der Richtung des Primärzeichens basierend auf der Klassenanzeige.

15. Verfahren gemäß Anspruch 10, bei welchem die Bestimmung (e) aufweist:

(ii) Bereitstellung eines Zustandsmoduls mit einer Vielzahl von Zuständen, wobei das Zustandsmodul verwendet wird, um die Richtung des Primärzeichens basierend auf der Klassenanzeige und einem Zustand des Zustandsmoduls zu bestimmen; und

(iii) Aktualisierung des Zustands des Zustandsmoduls.

16. Verfahren gemäß Anspruch 15, bei welchem das Zustandsmodul außerdem dazu dient, basierend auf der Klassenanzeige und einem laufenden Zustand des Zustandsmoduls zu bestimmen, ob das Primärzeichen in ein laufendes Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll.

17. Verfahren gemäß Anspruch 15, bei welchem die Bestimmung (e) die Richtung des laufenden Textelementes bestimmt.

18. Verfahren gemäß irgendeinem der Ansprüche 1-17, wobei das Verfahren weiterhin aufweist:

(e) Bestimmung eines Kontexts für jedes der Textelemente, und wobei das Suchen (c) des der zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente in der Abbildungstabelle auf der ersten Zeichencodierung und dem Kontext für jedes der Textelemente basiert.

19. Verfahren gemäß Anspruch 18, bei welchem der Kontext jedes Primärzeichens abhängig von den in der Primärzeichenfolge daran angrenzenden Primärzeichen ist.

20. Verfahren gemäß Anspruch 18, bei welchem die Bestimmung (e) aufweist:

(e1) Bestimmung, ob der Kontext irrelevant ist; und

(e2) wenn der Kontext relevant ist, Bestimmung, ob der Kontext ein Anfangs-, Mitte-, End- oder Einzelkontext ist.

21. Verfahren gemäß Anspruch 20, bei welchem bei der Durchführung der Bestimmung (e2) die Primärzeichenfolge Zeichen für Zeichen abgetastet wird, so daß bezüglich der Bestimmung des Kontexts für ein bestimmtes Primärzeichen angrenzende Primärzeichen den Kontext für das bestimmte Primärzeichen bestimmen können.

22. Verfahren gemäß Anspruch 18, bei welchem die Bestimmung (e) aufweist:

(ii) Bestimmung des Kontexts des Primärzeichens basierend auf der Klassenanzeige.

23. Verfahren gemäß Anspruch 18, bei welchem die Bestimmung (e) aufweist:

(ii) Bereitstellung eines Zustandsmoduls mit einer Vielzahl von Zuständen, wobei das Zustandsmodul verwendet wird, um den Kontext des Primärzeichens basierend auf der Klassenanzeige und einem Zustand des Zustandsmoduls zu bestimmen; und

(iii) Aktualisierung des Zustands des Zustandsmoduls.

24. Verfahren gemäß Anspruch 23, bei welchem das Zustandsmodul außerdem dazu dient, basierend auf der Klassenanzeige und einem laufenden Zustand des Zustandsmoduls zu bestimmen, ob das Primärzeichen in ein laufendes Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll.

25. Verfahren gemäß irgendeinem der Ansprüche 1-24, bei welchem der Empfang (a) der Primärzeichenfolge beinhaltet, einen Abschnitt einer Primärzeichenfolge in einem Puffes aufzunehmen, und bei welchem die Bestimmung (b) umfaßt:

(b1) Bestimmung eines Textelementes innerhalb des Abschnitts der Primärzeichenfolge;

(b2) Bestimmung, ob das Textelement vollständig ist;

(b3) Einfügen des Textelementes in einen abgekürzten Abschnitt der Primärzeichenfolge, wenn das Textelement vollständig ist;

(b4) Wiederholung der Schritte (b1)-(b3) bis der Abschnitt der Primärzeichenfolge vollständig berücksichtigt ist; und

(b5) Sichern jedes verbleibenden Abschnitts der Primärzeichenfolge zur Verwendung bei einem nächsten in dem Puffer aufgenommenen Abschnitt der Primärzeichenfolge.

26. Verfahren gemäß irgendeinem der Ansprüche 1-25, bei welchem der Umwandlungscode aus einem oder mehreren Zeichen in der zweiten Zeichencodierung besteht.

27. Verfahren gemäß irgendeinem der Ansprüche 1-26, bei welchem die Textelemente aneinander angrenzend sind, und bei welchem für jedes der Textelemente, welches mehr als ein Zeichen umfaßt, die Zeichen in der Primärzeichenfolge aneinander angrenzend sind.

28. Verfahren gemäß irgendeinem der Ansprüche 1-27, bei welchem die Abbildungstabelle reguläre Abbildungen und Ersatzabbildungen beinhaltet, und bei welchem das Suchen (C) den Umwandlungscode für jedes der Textelemente unter Verwendung von Ersatzabbildungen bestimmt, wenn die Abbildungstabelle bei Verwendung der regulären Abbildungen keinen Umwandlungscode für die Textelemente enthält.

29. Verfahren gemäß Anspruch 1, bei welchem jedes der Primärzeichen eine ihm zugeordnete Zeichenklasse aufweist, und bei welchem die Unterteilung (f) wenigstens teilweise auf der Zeichenklasse der Primärzeichen innerhalb der Primärzeichenfolge basiert.

30. Verfahren gemäß irgendeinem der Ansprüche 1-29, bei welchem das Kombinieren (d) aufweist:

31. Codeumwandlungssystem zur Umwandlung einer Primärzeichenfolge in eine Zielzeichenfolge, wobei das System aufweist:

einen Wandler (402; 2502) zur Steuerung der Umwandlung der Primärzeichenfolge mit einer ersten Zeichencodierung in die Zielzeichenfolge mit einer zweiten Zeichencodierung;

eine Abfrageeinrichtung (408; 2508), welche operativ an den Wandler angeschlossen ist, um die Primärzeichenfolge in Textelemente zu unterteilen, wobei jedes Textelement ein oder mehrere Zeichen der Primärzeichenfolge beinhaltet;

eine Abbildungstabelle (414; 2514) zur Speicherung von Zielcodierungen für Textelemente der Primärcodierung; und

eine Suchvorrichtung (412; 2512), welche operativ an den Wandler und die Abbildungstabelle angeschlossen ist, zum Suchen eines einer zweiten Zeichencodierung zugeordneten Umwandlungscodes für jedes der Textelemente in der Abbildungstabelle.

32. Codeumwandlungssystem gemäß Anspruch 31, bei welchem die Abfrageeinrichtung außerdem eine Richtung der Zeichen in den Textelementen bestimmt, und bei welchem die Suchvorrichtung basierend auf der Richtung und der Primärcodierung für die Textelemente in der Abbildungstabelle den der Zielzeichencodierung zugeordneten Umwandlungseode für jedes der Textelemente sucht.

33. Codeumwandlungssystem gemäß Anspruch 31, bei welchem die Abfrageeinrichtung außerdem einen Kontext für jedes Textelement bestimmt, und bei welchem die Suchvorrichtung basierend auf dem Kontext und der zweiten Zeichencodierung für die Textelemente in der Abbildungstabelle den der Zielzeichencodierung zugeordneten Umwandlungscode für jedes der Textelemente in der Primärzeichenfolge sucht.

34. Codeumwandlungssystem gemäß Anspruch 33, bei welchem die Abbildungstabelle Zielcodierungen für Textelemente der Primärcodierung speichert, und bei welchem die Suchvorrichtung basierend auf dem Kontext und der Primärzeichencodierung für jedes der Textelemente in der Abbildungstabelle für jedes der Textelemente die Zielzeichencodierung sucht.

35. Codeumwandlungssystem gemäß Anspruch 31, wobei das Codeumwandlungssystem außerdem aufweist: e

inen Puffer (405) zur Aufnähme eines Abschnittes der Primärzeichenfolge zu einem Zeitpunkt, wobei die Primärzeichenfolge mehr als einen Abschnitt umfaßt;

eine Abkürzungsvorrichtung (407) zur Abkürzung des Abschnitts der Primärzeichenfolge, und wobei die Abfrageeinrichtung den abgekürzten Abschnitt der Primärzeichenfolge in Textelemente unterteilt, wobei jedes Textelement ein oder mehrere Zeichen des abgekürzten Abschnitts der Primärzeichenfolge beinhaltet.

36. Codeumwandlungssystem gemäß Anspruch 35, bei welchem die Abkürzungsvorrichtung in Verbindung mit der Abfrageeinrichtung den Abschnitt der Primärzeichenfolge abfragt, um die Textelemente innerhalb des Abschnitts zu bestimmen, und den abgekürzten Abschnitt als einen Unterabschnitt des Abschnitts der Primärzeichenfolge bestimmt, welcher aus vervollständigten Textelementen besteht.

37. Codeumwandlungssystem gemäß Anspruch 35, bei welchem die Abkürzungsvorrichtung den abgekürzten Abschnitt als einen Unterabschnitt des Abschnitts der Primärzeichenfolge bestimmt welcher in die Zielzeichenfolge umgewandelt werden kann, ohne von nachfolgenden Abschnitten der Primärzeichenfolge beeinflußt zu werden.

38. Codeumwandlungssystem gemäß irgendeinem der Ansprüche 31-37, wobei das System außerdem aufweist: eine Ersatzvorrichtung (416; 2516), welche operativ an den Wandler angeschlossen ist, um Ersatzumwandlungscodes in bestimmten Fällen bereitzustellen, wenn die Suchvorrichtung nicht in der Lage ist, einen Umwandlungscode für ein oder mehrere Textelemente zu liefern, wobei die Ersatzumwandlungscodes einen oder mehrere Codepunkte in der Zielcodierung enthalten, welche nicht genau äquivalent zu den Zeichen in dem Textelement sind, aber ein graphisches Aussehen haben, welches ähnlich ist.

39. Codeumwandlungssystem gemäß irgendeinem der Ansprüche 31-38, wobei das System außerdem aufweist: eine Abfragetabelle (410; 2510), welche operativ an die Abfrageeinrichtung angeschlossen ist, um die Abfrageeinrichtung bei der Bestimmung zu unterstützen, ob einzelne Zeichen in der Eingabezeichenfolge in ein laufendes Textelement eingefügt oder alternativ ein neues nächstes Textelement begonnen werden soll.

40. Codeumwandlungstabelle gemäß Anspruch 39, bei welcher die Zeichen der Primärzeichenfolge eine ihnen zugeordnete Zeichenklasse aufweisen, und bei welcher die Abfragetabelle einen Datenbereich von Elementen aufweist, wobei der Datenbereich mit Zeichenklassen indiziert ist.

41. Codeumwandlungssystem gemäß irgendeinem der Ansprüche 3340, bei welchem die Zeichen in der Primärzeichenfolge Unicode-Zeichen sind.

42. Codeumwandlungssystem gemäß irgendeinem der Ansprüche 33-40, bei welchem die Zeichen in der Zielzeichenfolge Unicode-Zeichen sind.