EBCDIC Translation of ^ (Carrot) Does not Work

[toddtmw]

When downloading a file from an IBM Z/OS mainframe to a PC using the Mac client (3.63.2) if the file contains a Carrot, which is 0xB0 in EBCDIC and 0x5E in ASCII, the character does not get converted resulting in a non-printable 0xB0 on the Mac file. This can create issues with other programs trying to process the file.
Is it possible to update the ASCII translations to properly handle this character?

FileZilla Client

---

Version: 3.63.2

Build information:

Compiled for: x86_64-apple-darwin22.3.0
Compiled on: x86_64-apple-darwin22.3.0
Build date: 2023-02-23
Compiled with: Apple clang version 14.0.0 (clang-1400.0.29.202)
Compiler flags: -O2 -g -Wall -Wextra -pedantic -O2 -g -Wall -Wextra -pedantic -mmacosx-version-min=10.13.0 -Werror=partial-availability

Linked against:

wxWidgets: 3.2.1
SQLite: 3.39.4
GnuTLS: 3.8.0

Operating system:

Name: macOS Ventura Version 13.3.1 (Build 22E261)
Version: 13.3
CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 aes pclmulqdq lm
Settings dir: /Users/<redacted>/.config/filezilla/

[Tim Kosse]

Please clarify, is this about the name of the file, or the contents of the file?

[toddtmw]

Sorry. It is in the contents of the file.

[toddtmw]

Is anyone looking at this?

[Tim Kosse]

File contents are never modified by FileZilla, with the sole exception being line ending transformations for ASCII mode transfers as defined in the specifications.

Consider converting all text files to UTF-8, there is no need to use any other encoding in 2023. All modern software defaults to UTF-8.

[toddtmw]

Hi.

Thank you for taking the time to respond.

Would you please share the specifications on how Filezilla translates EBCDIC to ASCII?

It seems that this would be a case where Filezilla *IS* changing the contents of the file (out of necessity).

Transferring from an IBM mainframe (which Filezilla appears to be trying to support) is, by definition, a situation where encoding in 2023 does not default to UTF-8.

This is a simple mapping error between EBCDIC and ASCII. Making the statement that everyone in 2023 should be using UTF-8 does not fix the defect in Filezilla. (Even in UTF-8, this translation is incorrect)

I'm sure there are bigger issues that the team wants to work on, and I certainly understand that there are limits to what can be done. I'm not claiming that this issue should be fixed over and above other things. I also do not claim to know how much work it might take to fix this.

I do, however, take exception to the implied statement above, that this only affects ISO-8859-1, so it's not a bug and the ticket can be closed.

Thanks, again, for your time.

[toddtmw]

Upon further research, it looks like perhaps this translation is happening on the server side. So, it is not something Filezilla is doing or has control over.

I apologize for the distraction.

Thank you.

[Tim Kosse]

Your conclusion is correct, any such translation must be happening server-side.

FileZilla supports two data types for transfer: Binary (to be precise, 8 bits per bytes) where files are transferred as-is. And ASCII, where all files are supposed to be 7-bit ASCII, or any unspecified superset (these days UTF-8).

With all platforms FileZilla runs under are natively using supersets of ASCII, no translation is necessary to transform the wire format to local format, with the exception being the line endings in the case the client isn't running on Windows, where the line ending format matches the specified wire format.