If an extension to the file name character set of ISO646 to an 8-bit character code is imminent, a switch to character mode should be considered as a matter of foresight, as this can be done more easily from ISO646 than if a switch has been made in the meantime to an 8-bit character code.
If UTF-8 is used as character code for file names in the instances of an openFT application, it is recommended to select character mode. Character mode can be most effectively used if all instances code their file names in UTF-8 (this already applies in principle on Windows instances thanks to the use of character mode).
Caution!
If instances from several language areas are coupled with each other in an application of openFT, and if "national" or "regional" code settings, such as ISO8859-1, are used for file names in specific instances instead of UTF-8, file transfer requests in character mode, whose specification cannot be mapped for the remote file name in the code set there, are rejected.
Notes on Windows systems
The change to character mode is not a problem for file systems on Windows.
File names in the output of commands, such as ftshwl, ftshwr, ftshwp etc. are represented in Unicode on Windows systems. However, ftshwl | more replaces characters outside the locally set code table with ? or other substitute characters.
It is advisable for larger output to set OPENFTOUT=UTF8 as the environment variable, to reroute the output to a file and then to look at it with ftedit -ro -ccs=utf8.If openFT on Windows creates files on a directory, which is not on a local drive (e.g. a directory connected via SAMBA), this can result in character replacements in the file name, which would occur during the local copying of a Windows file to this directory.
Notes on Unix systems
Care is required in the case of a change in character coding for file names on a Unix system, for example when changing from transparent mode to character mode. This can result in inconsistently coded file trees (such as UTF-8 coded file names mixed with ANSI file names in an old directory, which also contains an ANSI umlaut in the name), with which not only openFT is likely to have difficulties.
All file and directory names, references to file names, etc., which are still to be accessed after the change, would have to be renamed to suit the new coding (e.g. ISO8859-1 -> UTF-8). Only if ISO646 characters have until now been exclusively used in file names, is a switch possible without this additional effort.If openFT on Unix only accesses inbound files for an application, which are in a defined directory, this can be specified as a file name prefix in an admission profile. If character mode openFT requests use the access authorization of this admission profile, it is sufficient that the file names relative to this prefix correspond to the code setting; there are no limitations in this case for the directory name. For example, coded umlauts would also be allowed in ISO8859-1, even if ftmodo -fnccs=utf8 is set.
Transfer admissions
Care should also be taken when defining transfer admissions with characters outside the ISO646 character set. In the case of file transfer requests and file management requests the specified transfer admissions is always processed according to transparent mode - even if character mode was selected (for file names). However, when specifying transfer admissions on a local Unix, as well as via remote administration in character mode, this is created in the local character code set there (in the case of remote administration in character code, which is defined with ftmodo -fnccs=... ).
Trace evaluations
Trace evaluations can also contain UTF-8 strings in file name specifications. It may thus be expedient to look at an evaluated trace with ftedit -ro -ccs=utf8 in order to see these file names in their correct character presentation. Byte sequences in the trace evaluation, which do not correspond to the correct UTF-8, are nevertheless not suppressed or replaced with ?, _ or the like, but are evaluated via heuristics as a ISO8859-1 character. As a result, the information as to whether an umlaut is coded in ISO or in UTF-8 is lost. In order to establish this it makes sense to look at the trace without the switch -ccs=utf8, too.