2016-05-21 7 views
0

Ich habe eine &Path und ich muss den Dateinamen der endgültigen Komponente in zwei Teile am ersten Doppelpunkt aufteilen.Wie spalte ich die letzte Komponente eines & Pfades auf ein bestimmtes Zeichen?

Ich kann die letzte Komponente als &OsStr() bekommen - aber dann bin ich ein bisschen fest auf tatsächlich etwas mit dem Inhalt. Die documentation gibt mir ein paar Optionen: (! Die nicht garantiert ist)

  • to_str() oder to_string_lossy(), die entweder nicht oder eine beschädigte Zeichenfolge zurückgeben, wenn es nicht UTF-8
  • to_bytes() oder to_cstring(), aber sie‘ seit Rust 1.6 als veraltet markiert
  • Ganz unten sehe ich impl OsStrExt mit einer as_bytes() Methode. OsStrExt ist std::os::unix::ffi::OsStrExt, die als "Unix-spezifische Erweiterungen zu OsStr" beschrieben wird. std::os::unix ist jedoch anscheinend "Experimentelle Erweiterungen für Standard-Unix-Plattformen."

Habe ich etwas mehr Standard verpasst?

Wie es passiert, ich bin glücklich, auf Unix für diese Anwendung zu beschränken, so dass die OsStrExt::as_bytes aussieht wie die beste Option für jetzt; Aber ist es wirklich noch experimentell oder ist die Dokumentation veraltet?

+0

Was möchten Sie mit dem Inhalt tun (wie 'file_name')? – malbarbo

+0

Ich mache Dinge mit Nachrichten in [Maildirs] (https://cr.yp.to/proto/maildir.html); Der Dateiname ist ein unspezifizierter eindeutiger Teil, gefolgt von "": "und einigen Flag-Zeichen. Ich möchte die Flaggen untersuchen oder modifizieren, ohne den einzigartigen Teil zu berühren. –

+0

* ist es wirklich noch experimentell * - wenn es nicht 'unstable' ist, solltest du darauf zählen können, dass es für alle Rust 1.x existiert. – Shepmaster

Antwort

2

Es gibt keine Standardmethode zum Umgang mit Dateisystempfaden, da nicht alle Plattformen die gleichen Regeln für die Darstellung und Gültigkeit von Pfaden haben.

Auf Unix-basierten Systemen (Linux, Mac OS X usw.) sind Pfade eine Bytefolge (u8), die keine Nullbytes enthalten darf. Das Modul std::os::unix ist auf diesen Plattformen verfügbar. Obwohl die Beschreibung des Moduls "experimentell" lautet, ist das meiste davon stabil, so dass die stabilen Funktionen in zukünftigen Rust 1.x-Versionen garantiert verfügbar bleiben.

Unter Windows NT sind Pfade eine Folge von 16-Bit-Wörtern (die normalerweise als UTF-16-Codeeinheiten interpretiert werden), die ungepaarte Surrogate enthalten können. Intern konvertiert Rust diese Pfade in WTF-8 (das ist nur UTF-8 mit dem Zusatz, dass die Codierung von ungepaarten Surrogate erlaubt wird, U + D800 – U + DFFF). Das Modul std::os::windows ist auf dieser Plattform verfügbar. Es wird nicht auf der Dokumentationswebsite von Rust angezeigt, aber wenn Sie die Dokumentation für std lokal erstellen, sollte es da sein. The source for this module is here. Es bietet differentOsStrExt and OsStringExt traits, die Sie eine zu möglicherweise schlecht ausgebildeten UTF-16 codieren oder einen möglicherweise schlecht geformten UTF-16-Pfad zu einem OsString dekodieren, aber keinen Zugriff auf die WTF-8-Darstellung bieten.

+0

Danke, das beantwortet meine Zweifel perfekt! –

+0

Unter Windows gibt es sowohl ASCII- als auch Unicode-Versionen vieler Funktionen. Die Konvertierung in den internen WTF-8 könnte möglicherweise über die ASCII-kodierten Versionen den Systembibliotheken überlassen werden, anstatt einen Ansatz innerhalb von Rust zu finden. Nicht sicher, aber welche Wahl ist besser? In einem eingebetteten Projekt haben wir eine tragbare Einrichtung geschaffen, die sowohl für * nix als auch für Windows (Desktop, CE, ...) indem Sie eine Gruppe von Klassen schreiben, die ähnlich wie die entsprechenden Objekte in der .NET-Bibliothek arbeiten. Wir waren damit glücklich. – BitTickler

+0

Rust verwendet die Unicode-Versionen, da die "ANSI" -Versionen keine Zeichen außerhalb der "ANSI" -Codepage verwenden können. Daher kann es Dateien geben, auf die Ihre Anwendung nicht zugreifen kann. Ich vermute, dass Rust potenziell schlecht ausgebildetes UTF-16 (WTF-16?) In WTF-8 umwandelt, weil die große Mehrheit der Pfade legales UTF-16 ist und daher in legales UTF-8 umgewandelt werden kann, was diese Pfade bedeuten kann als UTF-8 wie der Rest der Saiten in Rust abgerufen werden. –