Re: UTF8 beim FTP-Protokoll
- From: Kurt Stege <kurt.stege@xxxxxxxxxxx>
- Date: Fri, 22 Jun 2007 11:37:40 +0200
Lothar Kimmeringer wrote:
Carsten Petschel wrote:
Wenn der Server einem solchen Client gleich in UTF8 antwortet, dann liegt in meinen Augen undefiniertes Verhalten vor. Rein logisch.
IRL passiert aber genau das bei der Mehrheit der Server, die
UTF8 bei FEAT ausgeben. Da die Standardsprache allerdings
Englisch ist, faellt das normalerweise nicht bei den Meldungen
auf und man faellt erst auf die Nase, wenn es um das Lesen
von Dateilisten geht.
Jetzt hast Du es geschafft, mich neugierig zu machen.
Was genau machen denn die verschiedenen Implementierungen
der Server?
Der von Dir gelinkte Draft vom RFC ist doch ganz eindeutig
formuliert:
Sowohl Server als auch Client sprechen von Haus aus nur
ASCII (oder auch EBCDIC), wie im Original-FTP-Protokoll
vorgesehen.
FTP kennt bereits ein Kommando FEAT, daß der Client an
den Server schickt, um eine Liste der Implementierten
Features und Erweiterungen des Servers zu erhalten.
Wenn der Server die hier vorgeschlagene Erweiterung
unterstützt, tut er dies an dieser Stelle kund durch
Erwähnung des Features "UTF-8". Die Abfrage der Features
ändert gar nichts; insbesondere aktiviert sie nicht
das UTF8-Feature.
Wenn der Server UTF-8 nach diesem RFC unterstützt, erkennt
er ein neues Kommando vom Client, nämlich "OPTS UTF-8"
oder wahlweise auch "OPTS UTF-8 NLST". Wenn der Client
dieses Kommando abschickt antwortet der Server, ob die
Verbindung ab sofort erfolgreich auf UTF-8 umgestellt
ist oder nicht.
Der RFC für die UTF-8-Erweiterung empfiehlt es als
schönen Stil, wenn der Client erst mit FEAT abfragt,
ob der Server überhaupt UTF-8 unterstützt, bevor er
mittels OPTS UTF-8 versucht, auf UTF-8 umzuschalten.
Der Client darf es ausdrücklich aber auch einfach
so versuchen, weil der alte FTP-RFC bereits geregelt
hatte, wie der Server auf undefinierte und nicht
implementierte Kommandos reagieren soll.
Umschalten auf UTF-8 schaltet nicht die komplette
Kommunikation um. Es geht lediglich um die Kodierung
von Dateinamen! Bei allem anderen werden sowieso nur
7-Bit-Ascii-Zeichen übertragen, bei denen der Unterschied
zwischen Ascii und UTF-8 nicht erkennbar ist. Deshalb
ist es sinnfrei, darüber zu reden, ob die Antwort des
Servers auf "FEAT" oder auf "OPTS UTF-8" bereits in
UTF-8 kodiert ist oder noch in Ascii gesendet wird.
Wenn der Client bei OPTS UTF-8 auch noch das Flag NLST
angibt, werden auch Dateinamen, die über den Datenkanal
geschickt werden, in UTF-8 kodiert. Sonst bezieht sich
die Umstellung lediglich auf den Kontrollkanal. Hintergrund
ist, daß diese beiden Socket-Verbindungen mit
unterschiedlichen Rechnern und somit unterschiedlichen
FTP-Clients verbunden sein können.
Soviel dazu, wie ich den von Dir gelinkten RFC-Draft auf
<http://www3.ietf.org/proceedings/02nov/I-D/draft-ietf-ftpext-utf-8-option-00.txt>
verstanden habe.
Wo weichen die Server von diesem RFC ab, bzw. wo ist
der RFC unklar formuliert und läßt unterschiedliche
Verhaltensweisen des Servers zu?
Viele Grüße,
Kurt.
.
- Follow-Ups:
- Re: UTF8 beim FTP-Protokoll
- From: Lothar Kimmeringer
- Re: UTF8 beim FTP-Protokoll
- From: Rainer Weikusat
- Re: UTF8 beim FTP-Protokoll
- References:
- UTF8 beim FTP-Protokoll
- From: Carsten Petschel
- Re: UTF8 beim FTP-Protokoll
- From: Lothar Kimmeringer
- UTF8 beim FTP-Protokoll
- Prev by Date: Re: UTF8 beim FTP-Protokoll
- Next by Date: Re: UTF8 beim FTP-Protokoll
- Previous by thread: Re: UTF8 beim FTP-Protokoll
- Next by thread: Re: UTF8 beim FTP-Protokoll
- Index(es):
Relevant Pages
|
