Unicode Exceptions
Most of the EFT interface supports Unicode characters. (Refer to Unicode File Transfers for details. The table below lists exceptions to Unicode support in EFT.
Area |
Storage (Internal Representation on Disk) |
GUI (Allowed and Displayed) |
Usage |
Remarks |
---|---|---|---|---|
General |
||||
Unicode |
Unicode |
7-bit ASCII |
IDN (Internationalization of Domain Names) support by converting Unicode to Punycode upon use. From a user (presentation) perspective and EFT’s internal representation, it will be Unicode. |
|
All email address fields |
Unicode |
7-bit ASCII |
7-bit ASCII |
Conversion to Unicode for storage, but downgrade on usage. No risk/potential for loss of fidelity, as all chars limited to <128 ASCII. You can paste in Punycode ASCII characters directly for the domain portion if you must have Unicode domains for email addresses. |
Unicode |
7-bit ASCII |
7-bit ASCII |
Conversion to Unicode for storage, but downgrade on usage. No risk/potential for loss of fidelity, as all chars limited in GUI/usage to <128 ASCII. |
|
Installer |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
See Installer – ASCII ONLY below for potential problems |
Keys and OpenPGP |
||||
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
RFC allows for Unicode but OpenSSL handles the value as ASCII |
|
SSL priv. key pass |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
Passwords stored as octets sequence using same encoding as UI (ASCII) |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
Passwords stored as octets sequence using same encoding as UI (ASCII) |
|
OpenPGP priv. key pass |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
Veridis limitation. Passwords stored as octets sequence, 8-bit ASCII. |
OpenPGP filename and pathnames |
n/a |
n/a |
8-bit ASCII |
Unicode filenames will be supported, but the will be temporarily converted to ASCII. |
OpenPGP key name |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
OpenPGP module does not support Unicode |
OpenPGP public and private keyring paths |
8-bit ASCII |
8-bit ASCII |
8-bit ASCII |
OpenPGP module does not support Unicode |
ARM |
||||
ARM report content |
Unicode (audited) |
8-bit ASCII (reported) |
8-bit ASCII (reported) |
Loss of fidelity for UTF-8 chars that don’t match local code page for ext. ASCII. The VSReport Designer does not support Unicode. |
AS2 |
||||
AS2 outbound |
n/a |
n/a |
8-bit ASCII |
AS2 does not support Unicode encoded filenames. We can’t downgrade to ASCII as we would be violating Drummond, thus we will simply disallow and log error. |
AS2 inbound |
n/a |
n/a |
8-bit ASCII |
AS2 does not support Unicode encoded filenames. Unlike offloads, EFT inbound can’t detect whether the incoming file is Unicode encoded or not, thus we will always hand the file off to the AS2 component, with potential for mixed results. The outcome will be: a) an ASCII encoded filename, b) a failed transaction, or c) an ASCII encoded unique filename. Reference the AS2 Inbound Operations Use Case Cheat Sheet for additional guidance. |
EFT client action HTTP/S credentials |
Unicode |
n/a |
Base64 encoding of UTF-8 string |
|
EFT client action HTTP/S Proxy |
Unicode |
n/a |
Base64 encoding of UTF-8 string |
Q: Why is there no AS2 outbound cheat sheet?
A: EFT controls outbound and disallows UTF-8 encoded filenames from being transferred (see main exceptions above). EFT is more lenient on the inbound side, depending on the use cases described above.
PGP SDA Exceptions
If source filename is: |
If source path is: |
Resulting SDA name: |
If extract path is: |
Result |
---|---|---|---|---|
Unicode |
n/a |
n/a |
n/a |
Will fail to generate SDA |
ASCII |
Unicode |
ASCII |
ASCII |
Works perfect. Everything preserved |
ASCII |
||||
ASCII |
Unicode |
ASCII |
Unicode |
Will fail to extract |
ASCII |
EFT’s installer is not Unicode compliant. You cannot define Unicode values in the installer for app data path, administrator name, etc. The values can be changed in EFT, but with serious ramifications.