Sollten Zeichenkodierungen außer UTF-8 (und möglicherweise UTF-16 / UTF-32) veraltet sein?

31

Ein Tier von mir schaut sich so viele Softwareprojekte an, die Berge von Code für die Unterstützung von Zeichensätzen haben. Verstehen Sie mich nicht falsch, ich bin alle für die Kompatibilität, und ich bin froh, dass Sie mit Texteditoren Dateien in mehreren Zeichensätzen öffnen und speichern können. Was mich ärgert, ist, dass die Verbreitung von nicht universellen Zeichenkodierungen eher als "richtige Unicode-Unterstützung" als als "Problem" bezeichnet wird.

Lassen Sie mich zum Beispiel auf PostgreSQL und dessen Zeichensatzunterstützung eingehen . PostgreSQL befasst sich mit zwei Arten von Codierungen:

  • Client-Codierung: Wird für die Kommunikation zwischen dem Client und dem Server verwendet.
  • Serverkodierung: Zum internen Speichern von Text in der Datenbank.

Ich kann verstehen, warum es eine gute Sache ist, viele Client-Codierungen zu unterstützen. Es ermöglicht Clients, die nicht in UTF-8 arbeiten, mit PostgreSQL zu kommunizieren, ohne selbst eine Konvertierung durchführen zu müssen. Was ich nicht bekomme, ist: Warum unterstützt PostgreSQL mehrere Serverkodierungen ? Datenbankdateien sind (fast immer) von einer PostgreSQL-Version zur nächsten inkompatibel, daher ist die versionsübergreifende Kompatibilität hier nicht das Problem.

UTF-8 ist der einzige standardmäßige, ASCII-kompatible Zeichensatz, der alle Unicode-Codepunkte codieren kann (wenn ich mich irre, lassen Sie es mich wissen). Ich bin im Lager, dass UTF-8 der beste Zeichensatz ist, aber ich bin bereit, mich mit anderen universellen Zeichensätzen wie UTF-16 und UTF-32 abzufinden.

Ich glaube, dass alle nicht universellen Zeichensätze veraltet sein sollten. Gibt es einen zwingenden Grund, warum sie es nicht sollten?

Joey Adams
quelle
4
@mario: Die ursprüngliche Definition von UTF-8 erlaubte bis zu 6 Bytes. Es wurde später künstlich eingeschränkt, um nur die Zeichen abzudecken, die UTF-16 unterstützen konnte.
Dan04
6
Zumindest PostgreSQL befasst sich bewusst mit mehreren Zeichenkodierungen. Es ist schade, sich mit einer zufälligen Mischung aus UTF-8 und Windows-1252 auseinandersetzen zu müssen, weil es einfach niemanden interessiert.
Dan04
5
@ dan04: Die Arbeit mit russischen Texten war eine Herausforderung, da sie mehrere Codierungen verwendeten, die sich erheblich voneinander unterschieden und normalerweise nur die Arbeit mit verschiedenen Schriftarten hackten (was häufig an der in ihren Metadaten verwendeten Codierung lag). Alles in allem ein schreckliches Durcheinander. Ich vermute jedoch, dass sie aufgeräumt haben - wahrscheinlich durch den Wechsel zu UTF-8 -, weil die Anzahl der Support-Anfragen aus dieser Richtung sofort abgenommen hat.
Donal Fellows
3
Der theoretische Unicode-Bereich reicht von 0 bis 0x10ffff. Nichts mehr. Das sagt der Unicode-Standard. UTF-8 verarbeitet den gesamten Unicode und wird dies auch immer tun. Es deckt nicht den hypothetischen Bereich einer Codierung ab, die nicht Unicode ist, sondern den gesamten Unicode-Bereich.
gnasher729

Antworten:

16

Da Sie PostgreSQL erwähnt haben, kann ich mit einiger Autorität sagen, dass der Hauptgrund, warum serverseitige Nicht-UTF8-Codierungen so detailliert unterstützt werden, darin besteht, dass die Japaner es brauchen. Offensichtlich ist eine identische Round-Trip-Konvertierung zwischen Unicode und den verschiedenen japanischen "Legacy" -Codierungen nicht immer möglich, und in einigen Fällen unterscheiden sich die Konvertierungstabellen sogar zwischen den Anbietern. Es ist wirklich verwirrend, aber anscheinend ist es so. (Die umfassende Unterstützung von Zeichensätzen ist auch einer der Gründe, warum PostgreSQL in Japan so beliebt ist.)

Da es sich um ein Datenbanksystem handelt, besteht eine der Hauptaufgaben darin, Daten, wie vom Benutzer definiert, zuverlässig speichern und abrufen zu können, sodass eine verlustbehaftete Zeichensatzkonvertierung manchmal nicht funktioniert. Wenn Sie mit dem einem Web - Browser zu tun haben, sagt sie, wo alles , was wirklich zählt , ist , ob das Ergebnis sieht OK, dann könnte man wahrscheinlich mit Unterstützung weniger Codierungen wegkommen, aber in einem Datenbanksystem haben Sie zusätzliche Anforderungen.

Einige der anderen in anderen Antworten genannten Gründe gelten auch als Argumente. Solange die Japaner ihr Veto einlegen, kann die Unterstützung für die Charaktererstellung nicht reduziert werden.

Peter Eisentraut
quelle
Aufgrund dieser Kodierungen ist die Konvertierung von Text in UTF-8 und zurück im Allgemeinen verlustbehaftet? Auch wenn die Umstellung sofort erfolgt (statt in 6 Monaten)?
Joey Adams
Joey Adams: Anscheinend schon.
Peter Eisentraut
3
Google für "Han-Vereinigung", um zu sehen, warum
Petr Viktorin
7

Zwei offensichtliche Gründe: Je nach den von Ihnen gespeicherten Daten kann das Konvertieren in ein anderes Format viel Zeit und zusätzlichen Platz in Anspruch nehmen. Wenn Sie 400 Megabyte an Informationen speichern, ist es keine große Sache, den Speicherbedarf zu verdoppeln. Wenn Sie jedoch 400 Terabyte speichern, bedeutet dies etwas mehr. Das Konvertieren von 400 Terabyte Daten von Shift-JIS nach UTF-x kann ebenfalls einige Zeit in Anspruch nehmen.

Dies wird besonders schwierig, wenn Sie (zum Beispiel) Verfügbarkeitsgarantien haben, die besagen, dass die Datenbank für alle verfügbar ist, jedoch beispielsweise für 10 Minuten in einem bestimmten Jahr, und wenn Sie eine Datenbank haben, die mehrere hundert Mal pro Sekunde aktualisiert wird. Wohlgemerkt, es ist in einer solchen Situation immer noch möglich , größere Conversions zu verwalten, aber es ist nicht leichtfertig zu handhaben . In einigen Fällen kann es Jahre dauern , sich auf eine solche Umstellung vorzubereiten.

Wenn Sie mit einer Datenbank begonnen haben, die (zum Beispiel) nur ASCII unterstützt, gibt es möglicherweise gute Gründe zu diskutieren, ob es sinnvoll ist, die Unterstützung für alle diese Codierungen zu erweitern. Wenn Sie sie jedoch bereits unterstützen, kann das Löschen nur wenig bewirken Unterstützung für sie.

Beachten Sie insbesondere, dass Sie bei der Vereinfachung des Codes oder dergleichen wahrscheinlich so gut wie nichts gewinnen würden. Sie würden ohnehin noch alle Konvertierungsroutinen benötigen, um die Konvertierungen zwischen Client und Server durchführen zu können. Daher würde das Löschen der Unterstützung das Löschen eines (geringfügigen) Funktionsaufrufs in den Pfaden "Write to Disk" und "Read from Disk" bedeuten, jedoch wenig (wenn überhaupt). Wenn Sie sogar zwei Kodierungen auf der Festplatte unterstützen, würden Sie das nicht einmal erreichen - Sie hätten immer noch den Funktionsaufruf dort, und Sie würden wirklich nur den Bereich der Kodierungen einschränken, die von dieser Funktion unterstützt werden.

Zumindest wenn ich dies entwerfe, würde ich wahrscheinlich den Kern der Datenbank für die Arbeit in UCS-4 schreiben und dann Konvertierungsroutinen zwischen dem Kern und der Festplatte sowie zwischen dem Kern und dem Benutzer haben. In beiden Fällen würde ich die gleichen Routinen verwenden. Der einfachste Weg wäre also, dass der Festplattenspeicher genau die gleichen Codierungen verwendet, die Clients verwenden durften.

Jerry Sarg
quelle
1
Shift-JIS ist nicht selbstsynchronisierend, was das Suchen umständlich macht. Sie würden eine erhebliche Vereinfachung erzielen, wenn Sie dies nicht unterstützen.
Dan04
@ dan04: Wenn Sie bereits über bewährte Such- / Indizierungsroutinen für Shift-JIS verfügen, würde ein Wechsel zu UTF-8 oder sogar UCS2 die Leistung wahrscheinlich nur unwesentlich verbessern. Für eine neue Datenbank wählen Sie möglicherweise eine bessere, bequemere und regelmäßigere Codierung wie UCS2 oder UTF-16.
9000
@ dan04: wenn du davonkommen könntest, es überhaupt nicht zu unterstützen, würdest du ziemlich viel gewinnen. Solange Sie es unterstützen, von / zu Kunden zu gehen, werden Sie mit dem größten Teil seiner Hässlichkeit stecken bleiben ...
Jerry Coffin
5

Es gibt einige Probleme beim Speichern von UTF-8 auf dem Server:

  1. Was ist die Grenze einer VARCHAR(20)Spalte? Sind das 20 Bytes oder 20 "Zeichen" (und in Unicode, was ist ein "Zeichen", wenn Sie Zeichen, Ligaturen usw. kombinieren?). Schlimmer noch, was ist mit CHAR(20)dem Ort, an dem tatsächlich der gesamte mögliche Speicherplatz reserviert werden muss? Ich glaube, MySQL reserviert die vierfache Anzahl von Bytes für eine UTF-8-codierte Spalte (also 80 Bytes für CHAR(20)), um den schlimmsten Fall zu bewältigen.
  2. Sie müssen konstante Codierungskonvertierungen zwischen der Server-Codierung und Ihrer Client-Codierung durchführen. Sie könnten argumentieren, dass Sie nicht mehr mehrere Client-Codierungen unterstützen möchten, aber wenn Sie dies nicht tun, müssen alle Zeichenfolgen die ganze Zeit konvertiert werden. Wenn Sie Ihre Server- und Clientcodierung abgleichen können, sind die Konvertierungen nicht erforderlich.
  3. Wie bereits erwähnt, ist UTF-8 für die Speicherung von englischem Text recht effizient, für andere Sprachen - insbesondere für ostasiatische Sprachen - jedoch sehr ineffizient . Sie könnten die Verwendung von UTF-16 oder UTF-8 als Anzug zulassen, nehme ich an. Oder komprimieren Sie Text, aber das macht die Indizierung und Suche ineffizient.

Trotzdem stimme ich Ihnen zu: Legacy-Codierungen sind größtenteils sinnlos, und Unicode ist im Allgemeinen die beste Codierung für alle neuen Anwendungen. Wenn ich heute einen Datenbankserver von Grund auf neu schreiben würde, würde ich nur Unicode und überhaupt keine Legacy-Codierung unterstützen.

Der Unterschied besteht darin, dass PostgreSQL und die meisten anderen heute verwendeten Datenbankserver vorhanden waren, bevor Unicode eine praktikable Option war. Sie hatten also bereits Unterstützung für Legacy-Codierungen (sie waren damals natürlich keine Legacy-Codierungen), und es macht einfach nicht viel Sinn, den gesamten Code aus weitgehend ideologischen Gründen herauszureißen.

Dean Harding
quelle
10
"Aber es ist sehr ineffizient für andere Sprachen - insbesondere für ostasiatische Sprachen." Auch in der Praxis? Betrachten Sie diese chinesische Wikipedia-Seite . Obwohl es sehr viele chinesische Zeichen anzeigt, überwältigen ASCII-Zeichen sie in der Seitenquelle fast 7: 1.
Joey Adams
2
Wenn das N in Ihrer CHAR (N) -Spalte Teil eines genau definierten Bezeichnerformats ist (z. B. ist eine VIN mit genau 17 Zeichen definiert), müssen wahrscheinlich keine Zeichen oder Ligaturen kombiniert werden. Wenn nicht, ist N nur eine willkürliche Grenze, die großzügig interpretiert werden sollte, um das Abschneiden von Daten zu vermeiden.
Dan04
5
@Joey Adams: Das gilt für HTML und XML, bei denen das Markup selbst einen großen Teil des Texts ausmacht (und aus diesem Grund ist UTF-8 meiner Meinung nach eine gute Wahl für das Web), aber in einer Datenbank, die Sie nicht oft speichern HTML. Am Ende des Tages ist es nur ein Faktor von zwei (oder weniger) Unterschieden, was eigentlich nicht so viel ist.
Dean Harding
5
Aufzählungspunkt 2 in dieser Antwort ist irrelevant: Es gilt, ob Unicode verwendet wird oder nicht. Aufzählungspunkt Nr. 3 überträgt die Ineffizienz und ihren Umfang absolut. Gleichzeitig werden in dieser Antwort die Probleme, die durch Legacy-Codierungen verursacht werden, weitestgehend unterschätzt. Es ist leicht anzunehmen, dass das Problem keine so große Sache ist, wenn alles, was Sie jemals in Ihrem Leben benutzen, Englisch ist.
Timwi
2
@Dean: Ich wusste nicht, dass es nicht erlaubt ist, eine Antwort zu kommentieren, ohne eine eigene zu posten.
Timwi
3

Nicht universelle (und insbesondere Einzelbyte-) Codierungen haben ihren Platz: Auf Systemen, die:

  • Nicht genügend Speicher zum Speichern der Unicode-Zeichendatenbank.
  • Haben Sie eine Single-Byte-Schriftart im ROM fest codiert.
  • Sie haben keinen Internetzugang, um eine Quelle für unterschiedlich codierte Dateien bereitzustellen.

Das gilt heute für einige Arten von eingebetteten Geräten. Aber auf dem Desktop und im Serverraum sollten Nicht-Unicode-Codierungen inzwischen längst überholt sein.

dan04
quelle
3
Früher hatte ich solche Heimcomputer. Die meisten habe ich in den frühen 80ern beseitigt.
David Thornley
2

UTF-8 ist das Beste für Sie, wenn Sie egozentrisch 1 Englisch sprechen. Wenn Sie Japaner wären, würden ungefähr 99% Ihrer Zeichen 3-4 Bytes anstelle von zwei in UTF-16 benötigen.

Nicht-lateinische Dialekte leiden auf der Größenebene wirklich unter UTF-8. Vergessen Sie nicht, dass die meisten Ihrer Kunden innerhalb weniger Jahre Chinesen sind und dass chinesisches Schreiben Millionen von Zeichen hat. Mit UTF-8 können Sie das nicht effizient aufrechterhalten.

Ansonsten, ich hasse es , wenn ich Textdokumente, die nicht in UTF- sind etwas . Ich werde oft aus dem Weg gehen, wenn ich eine ordnungsgemäße Codierung haben muss. In meinem Buch sind Nicht-Unicode-Codierungen tot.

1. Nimm den egozentrischen Teil nicht persönlich. Ich wollte eine bunte Illustration machen und ich meine es nicht wirklich.

zneak
quelle
3
@Matthew - 4x ist eindeutig viermal größer als x (für positives x). Ich verstehe nicht, wie relevant die asymptotische Notation hier ist. Ich habe noch nie eine Festplatte mit einer asymptotischen Wachstumsrate gesehen. Normalerweise bleibt die Größe während der gesamten Lebensdauer des Laufwerks gleich.
Steve314
3
Millionen von Zeichen passen sowieso nicht in Unicode. Dem Wikipedia-Artikel zufolge gibt es derzeit etwa sechzigtausend Han-Zeichen. Da Unicode nicht nur chinesisch ist, bedeutet dies, dass eine angemessene Anzahl chinesischer Zeichen in UTF-16 vier Bytes benötigt, was so lange dauert, wie UTF-8 heutzutage ist. Es wäre interessant, Statistiken zu Längen von chinesischen Texten in UTF-8 und UTF-16 zu sehen.
David Thornley
6
@David:> 99% aller japanischen und chinesischen Schriften verwenden Zeichen, die nur 2 Byte in UTF-16 und 3 in UTF-8 erfordern. Die Zeichen, die mehr erfordern, sind sehr selten und / oder historisch.
Timwi
8
Beachten Sie, dass Japanisch und Chinesisch im Allgemeinen weniger Zeichen pro Wort verwenden. Ich arbeite mit einer App, die große Sprachdateien in Englisch, Japanisch und Chinesisch enthält, die alle in utf-8 codiert sind. Die chinesische Datei ist tatsächlich die kleinste, während die japanische Datei etwa 15% größer ist als das englische Original.
Gort the Robot
3
Unsinn. Alles, was in UTF-16 zwei Bytes benötigt, benötigt in UTF-8 nicht mehr als 3 Bytes. Alles, was in UTF-8 vier Bytes umfasst, entspricht in UTF-16 vier Bytes. Es gibt keine "Millionen" chinesischen Schriftzeichen, und offensichtlich würden sie nicht in 16 Bit passen.
gnasher729
1

Unicode ist grundsätzlich fehlerhaft und wird wahrscheinlich nie repariert. Es muss durch etwas Besseres, etwas wirklich Universelles ersetzt werden. Wenn etwas veraltet sein muss, ist es Unicode.

Beispielprobleme mit Unicide:

  • UTF8 ist ein vernünftiger Hack, aber die meisten UTF16-basierten Software ist defekt. Die meisten Windows-Apps, die Unicode unterstützen, verwenden UTF16, einschließlich des Betriebssystems. Das häufigste Problem besteht darin, nicht mehr als die Grundebene zu unterstützen, dh Zeichen mit mehreren Wörtern.

  • Die Han-Vereinigung ist eine absolute Katastrophe. Es ist unmöglich, japanischen / chinesischen / koreanischen Text ohne zusätzliche Metadaten in einem einzigen Dokument zu mischen, und es ist schwierig zu erkennen, welche Schriftart verwendet werden soll.

  • Kombinationszeichen sind eine weitere Katastrophe. Sinnvollere Codierungsschemata ordnen ein Zeichen einem Code zu, wodurch die Verarbeitung von Zeichenfolgen relativ sinnvoll ist. Unicode nicht. Unicode ist nicht einmal konsistent - Han-Zeichen sind meist Kombinationen, werden jedoch nicht als solche codiert, wie dies bei europäischen Kombinationszeichen der Fall ist.

  • Die Namen einiger Personen können in Unicode nicht richtig geschrieben werden oder neigen aufgrund der oben genannten Probleme dazu, falsch gerendert zu werden. Dies kann schwerwiegende Folgen haben, z. B. wenn Sie versuchen, ein Flugzeug mit einem Pass zu betreten, der nicht mit dem übereinstimmt, was (falsch) auf dem Ticket angegeben ist.

Aufgrund dieser und weiterer Probleme können viele nicht-englische Programme Unicode nicht verwenden und sind auf lokale Zeichenkodierungen angewiesen. Dies ist insbesondere bei japanischer und chinesischer Software der Fall.

Im Idealfall sollte Unicode veraltet sein. Die TRON-Zeichenkodierung ist ein ziemlich guter Ersatz für Unicode und weitgehend kompatibel mit vorhandener Software, die nicht aktualisiert wird.

Benutzer
quelle
Ihre Behauptung, dass es unmöglich ist, die verschiedenen Varianten von Zeichen (Japanisch / Koreanisch / Chinesisch) zu mischen, scheint seit 15 Jahren, dem Unicode-3.2-Standard von 2002, veraltet zu sein. Unicode-Unterstützung Variationsselektoren, Codepunkte, die nach einem Han-Codepunkt explizit angeben, welche Form sollte angezeigt werden. Außerdem werden die kombinatorischen Zeichen sowohl als "diakritische Zeichen kombinieren" mit Basiszeichen (a °) als auch als Sonderzeichen (å) angegeben. Der Prozess der Konvertierung ist "Normalisierung". Also, nein, Unicode ist nicht grundsätzlich kaputt.
Thorsten S.
Sie veranschaulichen viele der Mängel. Einige Sprachen verwenden kombinatorische Zeichen, andere nicht und Unicode kann nicht entscheiden, welche es bevorzugt. Wie ich bereits erwähnt habe, verstehen die meisten Programme, die angeblich Unicode unterstützen, diese Probleme sowieso nicht und zeigen sie auch bei den Selektoren falsch an. Von Programmierern sollte nicht erwartet werden, dass sie Sprachexperten sind, was der andere grundlegende Fehler in Unicode ist.
Benutzer
0

Vielleicht zum Schreiben, aber nicht zum Lesen.

Es gibt eine Menge existierender Inhalte, die diese Kodierungen verwenden, und einige Kodierungen wie base64 werden nicht verwendet, da einige Textprotokolle dies als Möglichkeiten zum Einbetten von Binärdaten vorschreiben.

Ein echtes Problem ist die automatische Erkennung von Codierungen, die zu Sicherheitslücken führt. Es würde mir nichts ausmachen, wenn einige obskure Codierungen wie UTF-7 einfach verschwinden.

Die automatische Erkennung hat auch die Tendenz, mit Inhalten, die durch die naive Verkettung von Bytefolgen erzeugt werden, schlecht umzugehen.

Mike Samuel
quelle
7
Base64 ist keine Zeichenkodierung.
Dan04
0

Ich kann zustimmen, dass die Standardzeichenkodierung für Datenbanken und neue Anwendungen eine Art UTF-Variante sein sollte. Ich persönlich würde mich für UTF-16 entscheiden, da es ein vernünftiger Kompromiss zwischen Platzbedarf und Komplexität zu sein scheint (mehr als UTF-8). Dennoch sind einige Zeichenkodierungen in bestimmten Fällen immer noch sinnvoll.

  • Wenn Sie base64-Text speichern / übertragen, benötigen Sie nur ASCII und können sogar mit 7-Bit-verschlüsselten Protokollen wie E-Mail davonkommen. Der zusätzliche Aufwand für UTF-8 ist nicht erforderlich.
  • Auf diesen älteren Zeichenkodierungen bauen mehrere Dateien und vorhandene Daten auf. Es ist wichtig, sie lesen zu können.

Beachten Sie, dass es 4 Standard-UTF-Normalisierungsalgorithmen gibt. Wenn Sie sich Gedanken über Zeichen mit mehreren Codepunkten machen, können Sie einen der beiden Normalisierungsalgorithmen verwenden, mit denen diese zu einem entsprechenden Zeichen mit einem Codepunkt zusammengefasst werden. Der Unterschied zwischen ihnen hat mit der logischen Äquivalenz und der physischen Äquivalenz von Zeichen zu tun.

Berin Loritsch
quelle
1
Können Downvoter bitte sagen, warum sie Downvotes abgegeben haben?
Berin Loritsch
3
Ich habe nicht abgelehnt, aber der springende Punkt bei base64 ist die Übertragung von Binärdaten über einen Textkanal. Wenn Sie auswählen könnten, welche Codierung für diesen Kanal verwendet werden soll, würden Sie überhaupt keine Textcodierung verwenden. Selbst wenn Ihr Kanal wirklich reines ASCII ist, verwendet Base 64 nur 6 von 7 Bits - ein erheblicher Overhead.
Steve314
Ich hoffe, jemand hat nicht nur die Aufzählungszeichen gelesen. Dies waren die Ausnahmen bei der Verwendung von UTF. Und Sie sind falsch in Bezug auf die Basis 64, wenn Sie nur 6 von 8 Bytes verwenden. Der erste Satz von ASCII- "Zeichen" sind nicht druckbare Steuerzeichen, wodurch einige der Zeichen in base64 gezwungen werden, 7 der 8 Bytes zu verwenden. Es wird absichtlich das hohe Bit vermieden, da nicht garantiert wird, dass alle diese Zeichen in jeder Codepage vorhanden sind, während dies bei den Zeichen von 0 bis 127 der Fall ist.
Berin Loritsch
2
@Berin - (1) nein, aber das "Ich stimme zu" Zeug ist nicht viel ohne die Aufzählungszeichen, und (2) Basis 64 hat 64 "Ziffern". 64 Stellen sind 6 Bits wert, weil 2 ^ 6 == 64. Wie Sie das in einem 7-Bit-Code-Raum darstellen (oder 8 Bits oder sogar 8 Bytes, wenn Sie müssen), ist unabhängig davon, wie viele Daten tatsächlich vorhanden sind. Das Vermeiden von nicht druckbaren Zeichen usw. ist der Grund für den Overhead. Dies bedeutet nicht, dass der Overhead nicht vorhanden ist. Wählen Sie einen Kanal, der für Binärdaten ausgelegt ist, und dieser Overhead ist nicht vorhanden.
Steve314
3
Denken Sie daran, dass base64 für das Senden von Binärdaten über einen Nur-Text-Kanal entwickelt wurde. Es ist als ineffizient bekannt (3: 4-Erweiterung), befasst sich jedoch mit technischen Einschränkungen bei bestimmten Transportmöglichkeiten. Vorgänger wären E-Mail- und UseNet-Foren, aber eine modernere Anwendung würde Binärdaten in XML einbetten. Manchmal ist der richtige Kanal nicht vorhanden , und Sie müssen die Einschränkungen der vorhandenen Kanäle überwinden.
Berin Loritsch