Codepages
Der RFC führt die Konvertierung zwischen verschiedenen technischen Formaten (Integer Darstellung, Little versus Big Endian usw.) sowie zwischen den Codepages von Sender und Empfänger durch.
Wenn zwei SAP-Systeme unterschiedlicher Codepage miteinander Daten austauschen und diese keine Unicode-Codepages verwenden, wird die Codepage-Konvertierung auf der Seite des Empfängersystems durchgeführt. Die Binärcodes von Zeichen, die nicht in die Codepage des Empfängersystems konvertiert werden können, bleiben erhalten.
Wenn zwei SAP-Systeme unterschiedlicher Codepage miteinander Daten austauschen und eines der beiden Systeme eine Unicode-Codepage verwendet, wird die Codepage-Konvertierung immer auf der Seite des Systems gemacht, das die Unicode-Codepage verwendet. Die Binärcodes von Zeichen, die nicht in die Nicht-Unicode Codepage konvertiert werden können, werden durch ein Ersatzzeichen ersetzt.
Wenn zwei SAP-Systeme der selben Codepage (Nicht-Unicode oder Unicode) miteinander Daten austauschen, führt der RFC nur die technischen Konvertierungen und keine Codepage-Konvertierung durch.
RFC und Unicode
Der RFC zwischen einem Unicode-System und einem Nicht-Unicode System muss die Textdaten zwischen den auf den beiden Seiten verwendeten Codepages konvertieren. Dabei können folgende Situationen auftreten:
- Ein
Eingabezeichen ist nicht in die Ausgabe-Codepage konvertierbar.
Beispiel: ein chinesisches Unicode Zeichen ist in keiner europäischen Codepage nach ISO8859 darstellbar. - Die
Konvertierung führt zum Überlauf des Ausgabepuffers.
Beispiel: eine Folge von japanischen Unicode Zeichen kann bei Konvertierung in die japanische Multi-Byte Codepage Shift-JIS einen Ausgabepuffer gleicher Länge zum Überlauf bringen. -
Zeichen in den Eingabedaten sind falsch; zum Beispiel sind in Nicht-Unicode
Multi-Byte Codepages nicht alle Kombinationen aus 2 Bytes zulässig.
Beispiel: die japanische Codepage Shift-JIS (SAP Nummer 8000) ist eine Multi-Byte Codepage mit Byte-Paaren, deren erste Hälfte im Bereich 0x80-0xEF, und deren zweite Hälfte im Bereich 0x40-0xFC liegt. Alle anderen Byte-Paare sind illegal und daher nicht konvertierbar.
Daten mit solchen Zeichen sind also bereits vor der Konvertierung fehlerhaft; sie können auf unkontrollierten Kanälen von außen in das System gelangt oder durch Anwendung ungeeigneter Textverarbeitungsoperationen im System entstanden sein.
RFC zwischen Unicode- und MDMP-Systemen
Findet der RFC zwischen einem Unicode-System und einem Non-Unicode System mit mehreren Codepages (MDMP System) statt, dann liegen die Daten auf der MDMP-Seite in verschiedenen Codepages vor. Der RFC berücksichtigt in diesem Fall die in den Daten enthaltenen Sprachschlüssel und ordnet jeder Sprache die im MDMP-System verwendete Codepage zu.
Das hier beschriebene Verfahren wird auf Tabellen vom Typ 1 angewandt (im Prinzip handelt es sich dabei um Tabellen, die eine flache Zeilenstruktur haben). Tiefe Strukturen überträgt der RFC in XML-Darstellung und codiert Textdaten darin in UTF-8. Empfängt ein Non-Unicode System solche Daten, dann konvertiert es sie in die Codepage der Anmeldesprache. Sendet ein Non-Unicode System solche Daten, dann konvertiert es aus der aktuell eingestellten Codpage.
Die sprachgerechte Konvertierung der Daten findet in den Unicode-Systemen statt. Die Unicode-Systeme emulieren dabei Non-Unicode Systeme und gewährleisten damit die Kompatibilität mit alten Non-Unicode Systemen (Abwärtskompatibilität).
Bei der Konvertierung ordnet das Unicode-System den Sprachen die MDMP-Codpage wie folgt zu:
MDMP-System ruft Unicode-System |
Das MDMP-System übermittelt seine Zuordnung von Sprachen
zu Codpages innerhalb des RFC-Protokolls. S. auch Einstellungen für Codepages. |
Unicode-System ruft MDMP System |
Die Zuordnung ist bei der RFC-Destination im Unicode-System hinterlegt. SM59 erlaubt die Anzeige und Pflege der Zuordnung. |
Strukturen mit LANG Feldern
Der RFC entnimmt die Sprache den LANG-Feldern, die in den transportierten Tabellen vom Typ 1 enthalten sind. Das jeweils relevante LANG-Feld ist durch ein DDIC-Attribut als Textsprache gekennzeichnet. Die Transaktion SE11 erlaubt die Anzeige und Pflege dieses Kennzeichens.
Nimmt eine Struktur durch .INCLUDE oder .APPEND Bezug auf eine andere Struktur mit LANG-Feldern, dann muss das Kennzeichen in der referierenden Struktur gegebenenfalls neu gesetzt werden; die referierte Struktur kann dazu aufgeklappt werden und zeigt das pflegbare Kennzeichenfeld.
In einer Struktur mit 1 LANG-Feld gilt dieses implizit als Textsprache; das DDIC-Attribut wird beim Anlegen einer solchen Struktur eingeschaltet Diese Einstellung kann in der Transaktion SE11 zurückgesetzt werden.
Werden Tabellen als tiefe Strukturen in einen Import-, Export-, oder Changing Parameter definiert, so wird die Sprache nicht ausgewertet!
Strukturen ohne LANG Felder
Wenn eine Struktur kein LANG-Feld besitzt oder wenn keines der LANG-Felder als Textsprache gekennzeichnet ist, dann konvertiert das Unicode System wie folgt:
MDMP-System ruft Unicode-System |
Entsprechend der vom Absender mitgegebenen Codepage |
Unicode-System ruft MDMP-System |
In die
normalerweise der Anmeldesprache (am Unicode-System) zugeordnete non-Unicode
Code Page. |
Insbesondere IDocs, die in den ALE-Schnittstellen verwendet werden, verfügen nicht über ein Sprachkennzeichen.
Unbekannte Sprachen
Die übertragenen Daten können eine Sprache enthalten, die in der Konfiguration des MDMP-Systems unbekannt ist. Dies kann in beiden Übertragungsrichtungen und unabhängig von der Client/Server-Rolle der beteiligten Systeme geschehen.
Gelegentlich enthalten Daten ein LANG-Feld mit Wert „ „ (Space), obwohl dieser Wert gemäß Wertetabelle unzulässig ist. Hier gelten die gleichen Regelen wie für Strukturen ohne LANG-Felder, siehe oben.
Unicode-System ruft MDMP- System |
Der RFC bricht mit Fehler SYSTEM_FAILURE ab. In diesem Fall können Sie den Benutzer-Trace (SM04) einschalten und finden in der Ausgabe Informationen über die unbekannte Sprache. |
MDMP-System ruft Unicode-System |
Der RFC bricht mit Fehler SYSTEM_FAILURE ab und setzt die
Fehlernachricht auf „Connection closed (no data)“. |