Steht eine Ausweitung des Dateinamens-Zeichenvorrats von ISO646 auf einen 8-Bit-Zeichencode an, so sollte vorausschauend ein Umstieg auf den Zeichenmodus in Erwägung gezogen werden, da dieser von ISO646 ausgehend wesentlich leichter möglich ist als dann, wenn in der Zwischenzeit auf einen 8-Bit-Zeichencode umgestiegen wurde.
Wird in den Instanzen einer openFT-Anwendung UTF-8 als Zeichencode für Dateinamen verwendet, so empfiehlt es sich, den Zeichenmodus zu wählen. Der Zeichenmodus kann am effektivsten genutzt werden, wenn alle Instanzen ihre Dateinamen in UTF-8 codieren (auf Windows-Instanzen gilt dies prinzipiell schon durch Verwendung des Zeichenmodus).
ACHTUNG!
Sind in einer Anwendung von openFT Instanzen aus mehreren Sprachräumen miteinander gekoppelt, und werden in bestimmten Instanzen anstelle von UTF-8 "nationale" oder "regionale" Code-Einstellungen wie ISO8859-1 für Dateinamen verwendet, so werden Dateiübertragungsaufträge im Zeichenmodus abgelehnt, deren Angaben für den fernen Dateinamen im dort eingestellten Code nicht abbildbar sind.
Hinweise für Windows-Systeme
Der Wechsel zum Zeichenmodus ist für Dateisysteme auf Windows unproblematisch.
Auf Windows werden Dateinamen in den Ausgaben von Kommandos wie ftshwl, ftshwr, ftshwp etc. in Unicode dargestellt. ftshwl | more ersetzt jedoch Zeichen außerhalb der lokal eingestellten Codetabelle durch ? oder andere Ersatzzeichen.
Für größere Ausgaben empfiehlt es sich, OPENFTOUT=UTF8 als Umgebungsvariable zu setzen, die Ausgabe auf eine Datei umzuleiten und diese dann anzuschauen mit ftedit -ro -ccs=utf8.Wenn openFT auf Windows Dateien auf einem Verzeichnis anlegt, das nicht auf einem lokalen Laufwerk liegt (z.B. ein per SAMBA angebundenes Verzeichnis), so kann dies zu Zeichenersetzungen beim Dateinamen führen, die auch beim lokalen Kopieren einer Windows-Datei auf dieses Verzeichnis entstehen würden.
Hinweise für Unix-Systeme
Vorsicht ist geboten bei einem Wechsel der Zeichencodierung von Dateinamen auf einem Unix-System, zum Beispiel anlässlich eines Umstiegs von transparentem Modus auf Zeichenmodus. Dies kann zu uneinheitlich codierten Dateibäumen führen (wie UTF-8 codierte Dateinamen gemischt mit ANSI-Dateinamen in einem alten Verzeichnis, das im Namen noch einen ANSI-Umlaut enthält), mit denen nicht nur openFT Schwierigkeiten haben dürfte. Es müssten alle Datei- und Verzeichnisnamen, Referenzen auf Dateinamen etc., auf die nach dem Wechsel noch zugegriffen werden soll, auf die neue Codierung umbenannt werden (z.B. ISO8859-1 -> UTF-8). Nur wenn bisher ausschließlich ISO646-Zeichen in Dateinamen verwendet wurden, ist ein Umstieg ohne diesen Zusatzaufwand möglich.
Sofern openFT auf Unix für eine Anwendung nur auf Dateien inbound zugreift, die in einem definierten Verzeichnis liegen, kann dieses in einer FTAC-Zugangsberechtigung als Dateinamenspräfix festgelegt werden. Wenn openFT bei Aufträgen im Zeichenmodus diese Zugangsberechtigung verwendet, genügt es, wenn die Dateinamen relativ zu diesem Präfix der Code-Einstellung entsprechen; für den Verzeichnisnamen gibt es in diesem Fall keine Beschränkungen. Er dürfte zum Beispiel auch in ISO8859-1 codierte Umlaute enthalten, selbst wenn ftmodo -fnccs=utf8 eingestellt ist.
Zugangsberechtigungen
Vorsicht ist geboten bei der Definition von Zugangsberechtigungen mit Zeichen außerhalb des ISO646-Zeichenvorrats. Bei Dateiübertragungsaufträgen und File-Management-Aufträgen wird die angegebene Zugangsberechtigung grundsätzlich entsprechend dem transsparenten Modus verarbeitet, auch wenn (für Dateinamen) Zeichenmodus gewählt wurde. Bei der Festlegung einer Zugangsberechtigung auf einem lokalen Unix-System wie auch über Fernadministration im Zeichenmodus wird diese jedoch im dort eingestellten lokalen Zeichencode angelegt, bei Fernadministration im Zeichencode, der mit ftmodo -fnccs=... definiert ist.
Trace-Auswertungen
Trace-Auswertungen können bei Dateinamensangaben auch UTF-8-Strings enthalten. Es kann deshalb zweckmäßig sein, einen ausgewerteten Trace mit ftedit -ro -ccs=utf8 anzuschauen, um diese Dateinamen in der korrekten Zeichendarstellung zu sehen. Bytefolgen in der Trace-Auswertung, die nicht korrektem UTF-8 entsprechen, werden allerdings nicht unterdrückt oder durch ?, _ oder ähnlichem ersetzt, sondern über eine Heuristik als ISO8859-1-Zeichen ausgewertet. Dadurch geht die Information verloren, ob ein Umlaut in ISO oder in UTF-8 codiert ist. Um dies festzustellen, ist es sinnvoll, auch mal ohne den Schalter -ccs=utf8 den Trace anzuschauen.