Ein URI ist eine kompakte Darstellung einer Ressource, die einer Anwendung im Intranet oder im Internet zur Verfügung steht. Die Uri-Klasse definiert die Eigenschaften und Methoden zur Behandlung von URIs. Dazu gehören Analysieren, Vergleichen und Verbinden. Die Eigenschaften der Uri-Klasse sind schreibgeschützt. Ein Objekt, das geändert werden kann, erstellen Sie mithilfe der UriBuilder-Klasse.
Relative URIs (z. B. "/new/index.htm") müssen in Bezug auf ein Basis-URI erweitert werden, damit sie absolut werden. Die MakeRelative-Methode steht zur Verfügung, um bei Bedarf absolute URIs in relative URIs zu konvertieren.
Die Uri-Konstruktoren versehen eine URI-Zeichenfolge nicht mit Escapezeichen, wenn die Zeichenfolge des URIs einschließlich Schemabezeichner formal korrekt ist.
Die Uri-Eigenschaften geben eine kanonische Darstellung der Daten mit Escapecodierung zurück, wobei alle Zeichen mit Unicode-Werten über 127 durch ihre hexadezimale Entsprechung ersetzt werden. Zum Überführen eines URIs in kanonische Form führt der Uri-Konstruktor folgende Schritte durch:
Das URI-Schema wird in Kleinbuchstaben konvertiert.
Konvertiert den Hostnamen in Kleinschreibung.
Wenn der Hostname eine IPv6-Adresse ist, wird die kanonische IPv6-Adresse verwendet. ScopeID und andere optionale IPv6-Daten werden entfernt.
Standardanschlussnummern und leere Anschlussnummern werden entfernt.
Kanonisiert den Pfad für hierarchische URIs, indem Sequenzen wie /./, /../, //, einschließlich mit Escapezeichen versehener Darstellungen, komprimiert werden. Beachten Sie, dass für einige Schemas die mit Escapezeichen versehenen Darstellungen nicht komprimiert werden.
Wenn der Host für hierarchische URIs nicht mit einem Schrägstrich (/) endet, wird dieser hinzugefügt.
Standardmäßig werden alle reservierten Zeichen im URI in Übereinstimmung mit RFC 2396 als Escapezeichen angegeben. Dieses Verhalten ändert sich, wenn die Analyse von International Resource Identifier oder International Domain Name aktiviert wird. In diesem Fall werden reservierte Zeichen im URI in Übereinstimmung mit RFC 3986 und RFC 3987 mit Escapezeichen versehen.
Im Rahmen der Kanonisierung im Konstruktor für einige Schemas werden mit Escapezeichen versehene Darstellungen komprimiert. Zu den Schemas, für die der URI-Konstruktor mit Escapezeichen versehene Sequenzen komprimiert, zählen Folgende: file, http, https, net.pipe und net.tcp. Für alle anderen Schemas werden mit Escapezeichen versehene Sequenzen nicht komprimiert. Wenn Sie beispielsweise die beiden Punkte ".." mit dem Prozentsymbol als "%2E%2E" codieren, komprimiert der URI-Konstruktor diese Sequenz für einige Schemas. Im folgenden Beispiel wird ein URI-Konstruktor für das http-Schema veranschaulicht.
Uri uri = new Uri("http://myUrl/%2E%2E/%2E%2E");
Console.WriteLine(uri.AbsoluteUri);
Console.WriteLine(uri.PathAndQuery);
Bei Ausführung dieses Codes wird die folgende Ausgabe erhalten, in der die mit Escapezeichen versehene Sequenz komprimiert ist.
Im folgenden Codebeispiel wird ein URI-Konstruktor für das ftp-Schema veranschaulicht.
Uri uri = new Uri("ftp://myUrl/%2E%2E/%2E%2E");
Console.WriteLine(uri.AbsoluteUri);
Console.WriteLine(uri.PathAndQuery);
Bei Ausführung dieses Codes wird die folgende Ausgabe erhalten, in der die mit Escapezeichen versehene Sequenz nicht komprimiert ist.
ftp://myUrl/%2E%2E/%2E%2E
/%2E%2E/%2E%2E
Der Inhalt der Uri-Klasse kann mit der ToString-Methode von einem Verweis auf einen mit Escapezeichen codierten URI in einen Verweis auf einen lesbaren URI umgewandelt werden. Beachten Sie, dass einige reservierte Zeichen in der Ausgabe der ToString-Methode immer noch mit Escapezeichen versehen sein können. Auf diese Weise wird die unmissverständliche Rekonstruktion eines URIs des Werts unterstützt, der von ToString zurückgegeben wird.
Einige URIs schließen einen Fragmentbezeichner oder eine Abfrage oder beides ein. Bei einem Fragmentbezeichner handelt es sich um Text, der einem Nummernzeichen (#) folgt, ohne das Nummernzeichen einzuschließen. Der Fragmenttext wird in der Fragment-Eigenschaft gespeichert. Bei Abfrageinformationen handelt es sich um Text, der im URI auf ein Fragezeichen (?) folgt. Der Abfragetext wird in der Query-Eigenschaft gespeichert.
In .NET Framework, Version 1.1, fügt die Uri-Klasse nach dem Doppelpunkt "//" ein, wenn die für einen Konstruktor angegebene Zeichenfolge ein unbekanntes Schema und "c:\" enthält. Zum Beispiel wird der URI xyz:c:\abc in xyz://c:/abc konvertiert. In .NET Framework, Version 2.0, wurde dieses Verhalten entfernt, und die Beispielzeichenfolge wird in xyz:c:/abc konvertiert.
 Hinweis |
|---|
Die URI-Klasse unterstützt bei der Verwendung von IP-Adressen sowohl die Quadschreibweise für IPv4 als auch die Hexadezimalschreibweise für IPv6. IPv6-Adressen müssen in eckigen Klammern angegeben werden, z. B. http://[::1]. |
IRI-Unterstützung (International Resource Identifier)
Webadressen werden typischerweise mit URIs (Uniform Resource Identifiers) ausgedrückt, die aus einem stark einschränkten Zeichensatz bestehen:
Die Spezifikationen für URIs sind in RFC 2396, RFC 2732, RFC 3986 und RFC 3987 dokumentiert, die von der IETF (Internet Engineering Task Force) veröffentlicht wurden.
Mit dem stetigen Anwachsen des Internets müssen Ressourcen zunehmend auch in anderen Sprachen als Englisch angegeben werden. Bezeichner, die dieser Anforderung gerecht werden und Nicht-ASCII-Zeichen (Zeichen im Unicode/ISO 10646-Zeichensatz) zulassen, sind IRIs (International Resource Identifiers). Die Spezifikationen für IRIs sind in RFC 3987 dokumentiert, die von der IETF veröffentlicht wurde. Wenn IRIs verwendet werden, kann eine URL auch Unicode-Zeichen enthalten.
Die vorhandene Uri-Klasse wurde in .NET Framework v3.5, 3.0 SP1 und 2.0 SP1 erweitert und bietet nun IRI-Unterstützung (International Resource Identifier) gemäß RFC 3987. Aktuelle Benutzer werden keinen Unterschied zum .NET Framework 2.0-Verhalten feststellen, es sei denn, sie aktivieren IRI explizit. Damit wird die Anwendungskompatibilität mit früheren Versionen von .NET Framework gewährleistet.
Zum Aktivieren der Unterstützung für IRI muss die folgende Änderung vorgenommen werden:
Durch das Aktivieren von IDN werden alle Unicode-Bezeichnungen in einem Domänennamen in ihre Punycode-Entsprechungen konvertiert. Punycode-Namen enthalten nur ASCII-Zeichen und beginnen immer mit dem Präfix xn--. Der Grund dafür besteht in der Unterstützung vorhandener DNS-Server im Internet, da die meisten DNS-Server nur ASCII-Zeichen unterstützen (siehe RFC 3940).
Das Aktivieren von IRI und IDN wirkt sich auf den Wert der Uri.DnsSafeHost-Eigenschaft aus. Das Aktivieren von IRI und IDN kann auch das Verhalten der Methoden Equals, OriginalString, GetComponents und IsWellFormedOriginalString ändern.
In Abhängigkeit von den verwendeten DNS-Servern gibt es drei mögliche Werte für IDN:
idn enabled = All
Durch diesen Wert werden alle Unicode-Domänennamen in ihre Punycode-Entsprechungen (IDN-Namen) konvertiert.
idn enabled = AllExceptIntranet
Durch diesen Wert werden alle Unicode-Domänennamen außerhalb des lokalen Intranets so konvertiert, dass die Punycode-Entsprechungen (IDN-Namen) verwendet werden. Wenn internationale Namen im lokalen Intranet verarbeitet werden sollen, müssen die DNS-Server im Intranet die Auflösung von Unicode-Namen unterstützen.
idn enabled = None
Durch diesen Wert werden keine Unicode-Domänennamen in ihre Punycode-Entsprechungen konvertiert. Dies ist der Standardwert, der dem .NET Framework 2.0-Verhalten entspricht.
Durch Aktivieren der IRI-Analyse (iriParsing enabled = true) werden Normalisierung und Zeichenüberprüfung nach den letzten IRI-Regeln in RFC 3986 und RFC 3987 ausgeführt. Der Standardwert ist false, bei dem Normalisierung und Zeichenüberprüfung gemäß RFC 2396 und RFC 2732 (für IPv6-Literale) ausgeführt werden.
Die IRI- und IDN-Verarbeitung in der Uri-Klasse kann auch mithilfe der Klassen System.Configuration.IriParsingElement, System.Configuration.IdnElement und System.Configuration.UriSection gesteuert werden, die Konfigurationseinstellungen enthalten. Die Einstellung System.Configuration.IriParsingElement aktiviert oder deaktiviert die IRI-Verarbeitung in der Uri-Klasse. Die Einstellung System.Configuration.IdnElement aktiviert oder deaktiviert die IDN-Verarbeitung in der Uri-Klasse. Mithilfe der Einstellung System.Configuration.IriParsingElement wird IDN auch indirekt gesteuert. Die IRI-Verarbeitung muss aktiviert sein, damit IDN-Verarbeitungsvorgänge ausgeführt werden können. Wenn die IRI-Verarbeitung deaktiviert ist, wird die IDN-Verarbeitung auf die Standardeinstellung festgelegt, in der das .NET Framework 2.0-Verhalten aus Kompatibilitätsgründen verwendet wird, und es werden keine IDN-Namen verwendet.
Die Konfigurationseinstellung für das System.Configuration.IriParsingElement und das System.Configuration.IdnElement wird einmal gelesen, wenn die erste System.Uri-Klasse erstellt wird. Änderungen an Konfigurationseinstellungen nach diesem Zeitpunkt werden ignoriert.
Die System.GenericUriParser-Klasse wurde außerdem so erweitert, dass das Erstellen eines anpassbaren Parsers möglich ist, der IRI und IDN unterstützt. Das Verhalten eines System.GenericUriParser-Objekts wird angegeben, indem eine bitweise Kombination der in der System.GenericUriParserOptions-Enumeration verfügbaren Werte an den System.GenericUriParser-Konstruktor übergeben wird. Der GenericUriParserOptions.IriParsing-Typ gibt an, dass der Parser die in RFC 3987 für IRI (International Resource Identifiers) angegebenen Analyseregeln unterstützt. Durch die oben beschriebenen Konfigurationswerte wird bestimmt, ob IRI verwendet wird.
Der GenericUriParserOptions.Idn-Typ gibt an, dass der Parser IDN-Analysen (Internationalized Domain Name) von Hostnamen unterstützt. Durch die oben beschriebenen Konfigurationswerte wird bestimmt, ob IDN verwendet wird.
Überlegungen zur Leistung
Wenn Sie eine Datei Web.config verwenden, die URIs zum Initialisieren Ihrer Anwendung enthält, wird die Dauer zum Verarbeiten der URIs zusätzlich verlängert, wenn die jeweiligen Schemabezeichner vom Standard abweichen. Initialisieren Sie die betroffenen Teile der Anwendung in diesem Fall erst dann, wenn die URIs benötigt werden, und nicht schon beim Start der Anwendung.
Aufgrund dieser Sicherheitsbedenken sollten Sie bei der Anwendung mit Umsicht vorgehen, wenn Sie Uri-Instanzen von nicht vertrauenswürdigen Quellen akzeptieren, und dontEscape auf true festgelegt ist. Sie können eine URI-Zeichenfolge auf Gültigkeit prüfen, indem Sie die IsWellFormedOriginalString-Methode aufrufen.
