UTF-8 support for Filezilla

 

Figure-FileZilla

Take advantage of Jia soft and take another article aboutFilezillaBut when it comes to filezilla's UTF-8 support (that is, the so-called garbled code problem), it is really a bit of laughter.

The problem is very simple, that is, rfc 2640, which stipulates the process as follows:

Client: feat // here is a question about the features supported by the server.

Server: blabla UTF8 blabla // server supports UTF-8

Then, when the client receives the UTF8 text, the communication encoding must be UTF-8, and the server is the same, so there will be no garbled characters. Of course, the server welcome message before feat may still contain garbled characters, but other commands are fine, because all the preceding commands only use the first 127 characters in the ascii code (maybe not) and are compatible with UTF-8.

Of course, this idea is very good. Everyone supports unicode, and then the world is peaceful. However, according to Murphy's Law, everything will always go in the bad direction.

First of all, not all servers must support responding to the feat command, and not all clients must issue the feat command. So what should we do if one side has a problem? Is it UTF-8 or local ansi?

The second is more common. The client will ask feat but does not support UTF-8. In this case, if the server fully supports rfc 2640, the server is talking about UTF-8 and the client is talking about local ansi. Both parties will not realize the error, but the fact is wrong.

Therefore, rfc 2640 completely discards the client that does not support UTF-8. Of course, the logic is also problematic, because the feat command is only used to query the feature supported by the server. As for the feature used by the client, it is completely the freedom and right of the client, now rfc 2640 is "server I support UTF-8, and you must use UTF-8 unconditionally", which clearly violates the principles of network protocol negotiation.

Therefore, most servers and clients that support UTF-8 now use the following method: when the client asks feat and the server responds with UTF8, when the client asks "OPTS UTF8 ON" and the server responds correctly, both parties began to use UTF-8 for transmission.

Although OPTS UTF8 ON is not a command in rfc, it is more reasonable, so most servers/clients support this command.

Therefore, tommy submitted a patch, which generally adds an option. You can use UTF-8 only when you receive OPTS UTF8 ON and use UTF-8 when UTF8 responds to feat. But the author is not very kind. He gave Tom's account to ban.

Alcohol adds acid to the new version. After I run it, isn't it a yasu? Originally, yasu became a daemon tool proprietary. I didn't expect dt to have the built-in function of shielding virtual optical drive detection, making yasu useless in dt, and sticking a hot face with a cold ass. Now, alcohol also has a proprietary yasu, which is quite interesting.

[Update]

The 64-bit system memory consumption is high because int64 accounts for a portion of int32.

First, the 32-bit program running on the 64-bit system still uses int32, which does not occupy more memory. For 64-bit programs, the usage of int64 is different from that of int32, the two are co-existent, not the relationship between who replaces who, and at least the default int in C is int32, whether it is for the x86-64 program.

Second, the real reason for the 64-bit system to occupy a large amount of memory is that the system needs to load the dual dll, one for the 32-bit program call, one for the 64-bit program call. 7-zip, whether it is a 64-bit or 32-bit version, its right-click menu cannot work completely in a 64-bit system, because 64-bit 7-zip only has 64-bit right-click menu dll, 32-bit programs such as tc cannot be called, while 32-bit 7-zip only has 32-bit dll, therefore, it cannot work in the 64-bit explorer. Winrar is much more intelligent, a 32-bit exe + 32/64-bit dll, so you do not need to select the installation file and can use it normally in the 64/32-bit program. Of course, there are still some skills to coordinate 64-bit dll with 32-bit exe. For example, mark's process explorer is a 32-bit program, however, when running in a 64-bit system, a 64-bit executable file will be released to work with the original executable file, so far, I have not seen such writing skills in other places than mark.

[Update]

The behavior of filezilla3 client is verified. When the server of the other party is not filezilla and the received feat contains UTF8, it will indeed send OPTS UTF8 ON. The sauce purple is good, however, feat has always been processed with utf8. If it is ansi's welcome message, it will be garbled. However, whatever the rules, the welcome message may contain garbled characters, unless the client can accurately determine the encoding like some text editors.

In terms of server, filezilla remains the same. When the feat sent by the client responds to UTF8, The UTF8 processing will not be disabled in the future, regardless of how the client responds. Of course, if the client supports UTF8, it will send OPTS UTF8 ON, and then filezilla server will return a don't care (Khan), and then both parties can use UTF-8 for communication; for a client that does not support UTF-8, such as the very fucking cuteftp, it will not send OPTS UTF8 ON or use UTF-8, and then both parties will talk about UTF-8 and ansi, and garbled characters will appear.

In addition, when filezilla's server communicates with the client, the server sends an MDTM feat, and the client randomly selects a file for time difference correction. This is very interesting, because even if the MDTM is received, the client of filezilla will not connect to the server of another house, that is, only filezilla's own client can connect to the server.

Based on the description in the article, it is not difficult to find that the UTF-8 support error of Filezilla has been solved. I hope it will help you!