nicht angemeldet
Matthias Apsel
Felix Riesterer
MudGuard
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Der Martin
Der Martin
dedlfix
dedlfix
Hey Leute, ich habe ein kleines Problem mit einem image in einem Newsletter.
leider wird es nicht Dargestellt. Bis auf das eine funktionieren alle Bilder. Das besagte Bild unterscheidet sich von den anderen, da hier eine große "20%" abgebildet ist. Füge ich jedoch an der selben Stelle ein anderes Bild(ohne zahlen und %-Zeichen) ein, funktioniert es. Nur bei den 20%-Bildnicht.... kann es sein, das es daran leigt das dort die 20% angebildet sind?
Hallo Mike,
leider wird es nicht Dargestellt. Bis auf das eine funktionieren alle Bilder. Das besagte Bild unterscheidet sich von den anderen, da hier eine große "20%" abgebildet ist. Füge ich jedoch an der selben Stelle ein anderes Bild(ohne zahlen und %-Zeichen) ein, funktioniert es. Nur bei den 20%-Bildnicht.... kann es sein, das es daran leigt das dort die 20% angebildet sind?
Das denke ich nicht. Wie lautet denn der Dateiname der Grafik?
Bis demnächst
Matthias
Hallo
die 20% stehen wahrscheinlich für ein Leerzeichen. Ersetze die also mal durch ein Leerzeichen.
Insgesamt sollten für Order- und Dateinamen nur die Buchstaben des englischen Alphabets, Zahlen und der Unterstrich verwendet werden. Das vermeidet viele Probleme bereits im Vorfeld.
Gruss
MrMurphy
Lieber Mike,
da hier eine große "20%" abgebildet ist.
Du meinst "%20" als URL-kodiertes Leerzeichen? Vermeide Zeichen in Dateinamen, die keine Kleinbuchstaben sind und nicht im englischen Alphabet vorkommen. Zusätzlich zu den englischen Kleinbuchstaben sind noch ".", "-" und "_" erlaubt. Alles andere führt unweigerlich zu vermeidbaren Problemen!
Liebe Grüße,
Felix Riesterer.
Hi,
Du meinst "%20" als URL-kodiertes Leerzeichen? Vermeide Zeichen in Dateinamen, die keine Kleinbuchstaben sind und nicht im englischen Alphabet vorkommen. Zusätzlich zu den englischen Kleinbuchstaben sind noch ".", "-" und "_" erlaubt. Alles andere führt unweigerlich zu vermeidbaren Problemen!
Du siehst "datei123.txt" als problematischen Dateinamen an?
Ziffern (die aus dem ASCII-Bereich) solltest Du schon zulassen.
Ansonsten stimme ich Dir zu - alle anderen Zeichen führen früher oder später zu Problemen.
cu,
Andreas a/k/a MudGuard
Liebe) MudGuard,
Du siehst "datei123.txt" als problematischen Dateinamen an?
Du hast recht, die Ziffern habe ich in der Eile vergessen.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
Vermeide Zeichen in Dateinamen, die keine Kleinbuchstaben sind und nicht im englischen Alphabet vorkommen.
Ja nee is klar, IRIs sind des Teufels. Internationalisierung allgemein ist des Teufels. Wer braucht schon Lokalisierung, die ganze Welt spricht schließlich englisch und beschränkt sich auf 26 Buchstaben. Und die Welt ist eine Scheibe.
So naïve sind nicht einmal Englisch-Muttersprachler.
Alles andere führt unweigerlich zu vermeidbaren Problemen!
Unsinn. Die Probleme vermeidet man durch kontextgerechtes Escapen. Von „unweigerlich“ keine Spur.
LLAP 🖖
Tach!
Die Probleme vermeidet man durch kontextgerechtes Escapen.
Ich bitte um Hinweise, wie die Regeln lauten für den Kontext, den du dir da gerade vorstellst.
dedlfix.
@@dedlfix
Die Probleme vermeidet man durch kontextgerechtes Escapen.
Ich bitte um Hinweise, wie die Regeln lauten für den Kontext, den du dir da gerade vorstellst.
Ich stelle mir keinen Kontext vor. Felix tat das auch nicht, als er generell von der Verwendung von allem außer Kleinbuchstaben, Ziffern (später ergänzt), ".", "-" und "_" abriet.
Wenn der Kontext URI ist, wäre (für Dateinamen, also Bestandteile des Pfades) das %-Escapen kontextgerecht. Meist übernehmen das die UAs (Browser, …), sodass sich Nutzer und Seitenautoren darum nicht kümmern müssen.
LLAP 🖖
Vermeide Zeichen in Dateinamen, die keine Kleinbuchstaben sind und nicht im englischen Alphabet vorkommen.
Ja nee is klar, IRIs sind des Teufels. Internationalisierung allgemein ist des Teufels. Wer braucht schon Lokalisierung, die ganze Welt spricht schließlich englisch und beschränkt sich auf 26 Buchstaben. Und die Welt ist eine Scheibe.
Ja nee is klar, Mr. Polemik. Was den Inhalt angeht, haben wir mittlerweile einen stabilen Zeichensatz und Kodierung. Im Dateisystem sieht die Scheibe, ähem die Welt aber noch anders aus. Kann Dir als Frontendler natürlich egal sein.
@@Mitleser
Was den Inhalt angeht, haben wir mittlerweile einen stabilen Zeichensatz und Kodierung. Im Dateisystem sieht die Scheibe, ähem die Welt aber noch anders aus.
Ach ja, sieht es? Welcher Webserver genau hat denn bitte Probleme damit, bei Anfrage von /directory%20with%20spaces/%D7%98%D7%A2%D7%A1%D7%98.html die Datei טעסט.html aus dem Verzeichnis directory with spaces auszuliefern?
Meiner jedenfalls nicht. Und wenn jemanden Server damit Probleme hat, sollte derjenige vermutlich den Hoster wechseln.
LLAP 🖖
Ach ja, sieht es? Welcher Webserver genau hat denn bitte Probleme damit, bei Anfrage von
/directory%20with%20spaces/%D7%98%D7%A2%D7%A1%D7%98.htmldie Dateiטעסט.htmlaus dem Verzeichnisdirectory with spacesauszuliefern?Meiner jedenfalls nicht. Und wenn jemanden Server damit Probleme hat, sollte derjenige vermutlich den Hoster wechseln.
Wie viele der potentiellen Use-Cases eines Dateisystems deckst Du Deiner Einschätzung nach damit ab?
Hallo Mitleser,
Wie viele der potentiellen Use-Cases eines Dateisystems deckst Du Deiner Einschätzung nach damit ab?
In Deutschland wahrscheinlich Null %. Aber warum sollten, Araber, Chinesen oder … nicht ihre Dateien in ihrer Sprache bezeichnen dürfen?
Allerdings: Es gibt weniger Probleme, wenn man sich bei den Dateibezeichnungen auf arabische Ziffern, lateinische Buchstaben ohne Umlaute, Tremata und sonstige Betonungs- oder Aussprachezeichen und eine andere Zeichen beschränkt.
Bis demnächst
Matthias
Hallo
Wie viele der potentiellen Use-Cases eines Dateisystems deckst Du Deiner Einschätzung nach damit ab?
In Deutschland wahrscheinlich Null %.
Wieso? Wir haben schließlich auch unsere Schriftzeichen(-kombinationen), die außerhalb des lateinischen Alphabets liegen (Umlaute, ß, Akzente).
Aber warum sollten, Araber, Chinesen oder … nicht ihre Dateien in ihrer Sprache bezeichnen dürfen?
Oder auch die meisten Europäer, denn nicht-nativ-lateinische-Zeichen gibt es in den meisten europäischen Schriftsprachen.
Tschö, Auge
@@Auge
Oder auch die meisten Europäer, denn nicht-nativ-lateinische-Zeichen gibt es in den meisten europäischen Schriftsprachen.
Und nicht-lateinische Zeichen gibt es auch in etlichen europäischen Schriftsprachen.
LLAP 🖖
Hallo,
Wie viele der potentiellen Use-Cases eines Dateisystems deckst Du Deiner Einschätzung nach damit ab?
Die Frage ist falsch. Man sollte fragen: Gibt es einen Use-Case, der damit nicht abgedeckt ist?
Gruß
Kalk
Tach,
Ja nee is klar, Mr. Polemik. Was den Inhalt angeht, haben wir mittlerweile einen stabilen Zeichensatz und Kodierung. Im Dateisystem sieht die Scheibe, ähem die Welt aber noch anders aus. Kann Dir als Frontendler natürlich egal sein.
ich als Servermensch frage mich: Welches Dateisystem bzw welche Tools haben damit noch ein Problem?
mfg
Woodfighter
ich als Servermensch frage mich: Welches Dateisystem bzw welche Tools haben damit noch ein Problem?
Tach,
ich als Servermensch frage mich: Welches Dateisystem bzw welche Tools haben damit noch ein Problem?
- Alte Backuplösungen seitens des Providers, merkt man leider zu spät
- Kunden mit defekten internen Setups(z.B. Samba) / Übertragungswegen
also defekte oder falsch konfigurierte und veraltete Software
- Aufwändigeres Pipen / Escapen beim Arbeiten auf der Shell
sowie ein paar Anführungszeichen, die man in seinen Scripten alleine aus Sicherheitsgründen eh verwenden sollte?
mfg
Woodfighter
also defekte oder falsch konfigurierte und veraltete Software
Das kannst Du so sehen. Faktisch schlagen solche Fälle als vermeidbarer Support auf, braucht kein Mensch. Außerdem habe ich keinen Bock, dem Kunden zu erklären, dass "sein Provider" oder sein Onkel, der die EDV bei ihm in der Firma macht, Schuld ist.
- Aufwändigeres Pipen / Escapen beim Arbeiten auf der Shell
sowie ein paar Anführungszeichen, die man in seinen Scripten alleine aus Sicherheitsgründen eh verwenden sollte?
Nicht in Scripten, beim tagtäglichen Rumwuseln auf der Shell.
Tach,
sowie ein paar Anführungszeichen, die man in seinen Scripten alleine aus Sicherheitsgründen eh verwenden sollte?
Nicht in Scripten, beim tagtäglichen Rumwuseln auf der Shell.
dann sind es halt da ein paar Anführungszeichen bzw. Backspace (meist nur ein Backspace, da sich eh Tab Completion um den Rest kümmert); nichts, was mich im Alltag davon abhält Leerzeichen in Dateinamen zu verwenden.
mfg
Woodfighter
Hallo,
ich als Servermensch frage mich: Welches Dateisystem bzw welche Tools haben damit noch ein Problem?
ja, jetzt kommen wir der Sache langsam näher. Das Problem, das ich sehe, liegt im Fehlen jeglicher Information, welche Zeichencodierung das Dateisystem bzw. dessen API verwendet.
Das ist noch nicht wirklich ein Problem, solange nur eine Anwendung (z.B. der Webserver) darauf zugreift; ggf. sehen die Dateinamen dann halt für die Shell ein bissl "kaputt" aus. Aber da sie bei jedem Zugriff auf dieselbe Art interpretiert werden, ist die Eindeutigkeit immer noch gegeben.
Dumm nur, wenn mehrere Anwendungen (z.B. der Webserver und PHP) auf Dateien zugreifen und unabhängig voneinander verschiedene Codierungen annehmen - wenn etwa der Webserver UTF-8 annimmt, ein PHP-Script aber Dateinamen in irgendeiner ISO-Latin-Codierung ans OS übergibt.
Dann bekommt dann der gutgemeinte Rat, möglichst nur Zeichen aus dem ASCII-Bereich zu verwenden, durchaus wieder einen Sinn.
So long,
Martin
@@Der Martin
wenn etwa der Webserver UTF-8 annimmt
Gute Annahme.
ein PHP-Script aber Dateinamen in irgendeiner ISO-Latin-Codierung ans OS übergibt.
Der Bug ist in diesem PHP-Script zu fixen.
Dumm nur, wenn mehrere Anwendungen (z.B. der Webserver und PHP) auf Dateien zugreifen und unabhängig voneinander verschiedene Codierungen annehmen
Hallo-o, es ist 2015! Es sollte bei der Kommunikation zwischen Systemen nirgends mehr eine andere Zeichencodierung als UTF-8 Verwendung finden.
LLAP 🖖
Hallo Gunnar,
Dumm nur, wenn mehrere Anwendungen (z.B. der Webserver und PHP) auf Dateien zugreifen und unabhängig voneinander verschiedene Codierungen annehmen
Hallo-o, es ist 2015! Es sollte bei der Kommunikation zwischen Systemen nirgends mehr eine andere Zeichencodierung als UTF-8 Verwendung finden.
willkommen in der Wirklichkeit. Bei meinen letzten paar Linux-Installationen (Mint, Ubuntu, Debian, Raspbian) war die Default-Zeichencodierung in der Shell irgendein ISO-8859-x, und UTF-8 musste ich erst ausdrücklich nachinstallieren. Ähnliches gilt für Samba: Auch hier ist die Defaulteinstellung irgendwas anderes; ich weiß nicht mehr genau, was es war.
Das babylonische Problem der Zeichencodierungen ist also immer noch sehr real.
Ciao,
Martin
Tach,
willkommen in der Wirklichkeit. Bei meinen letzten paar Linux-Installationen (Mint, Ubuntu, Debian, Raspbian) war die Default-Zeichencodierung in der Shell irgendein ISO-8859-x, und UTF-8 musste ich erst ausdrücklich nachinstallieren.
dann machst du aber keine Standardinstallationen; Debian nutzt seit mindestens Etch UTF-8 als Standard; Ubuntu basiert darauf und auch da habe ich noch keinen anderen Standard gesehen.
Ähnliches gilt für Samba: Auch hier ist die Defaulteinstellung irgendwas anderes; ich weiß nicht mehr genau, was es war.
Nö, also so lange du nicht über die Kommunikation zu Win9x/DOS redest: https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/unicode.html
mfg
Woodfighter
Hallo,
willkommen in der Wirklichkeit. Bei meinen letzten paar Linux-Installationen (Mint, Ubuntu, Debian, Raspbian) war die Default-Zeichencodierung in der Shell irgendein ISO-8859-x, und UTF-8 musste ich erst ausdrücklich nachinstallieren.
dann machst du aber keine Standardinstallationen
doch, im Grunde schon: Live-CD runterladen, booten und dann den angebotenen Installer nutzen. Als Standardsprache habe ich immer Englisch ausgewählt.
Debian nutzt seit mindestens Etch UTF-8 als Standard; Ubuntu basiert darauf und auch da habe ich noch keinen anderen Standard gesehen.
Das "reine" Debian habe ich vor einiger Zeit mal in einer 6.x-Version installiert (keine Ahnung, welcher Codename dazu gehört), das kam mit Standard-locale ISO-8859-1, AFAIR. Ubuntu habe ich von Version 7 bis 11 gehabt, die hatten alle in der Default-Installation kein UTF-8. Und von Mint habe ich die Versionen 12 (Lisa), 13 (Maya) und die aktuelle 17 (Qiana) intensiv kennengelernt; erst die 17 kam mit UTF-8 als Default, bei 12 und 13 musste ich ein UTF-8-locale noch manuell nachinstallieren.
Dasselbe gilt für Raspbian, wenn das nicht in den letzten 8..10 Monaten geändert wurde.
Ähnliches gilt für Samba: Auch hier ist die Defaulteinstellung irgendwas anderes; ich weiß nicht mehr genau, was es war.
Nö, also so lange du nicht über die Kommunikation zu Win9x/DOS redest: https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/unicode.html
Hier muss ich mich korrigieren, sorry, ich meinte in der Tat genau das Gegenteil: Um mit Windows-Clients kompatibel zu sein, muss man Samba sehr gezielt konfigurieren. Da hatte ich anfangs große Schwierigkeiten, richtig reibungslos funktionierte es erst mit der Kombination der Direktiven
Auge
Tabellenkalkunix charset = utf-8
dos charset = 437
display charset = utf-8
in der smb.conf.
So long,
Martin
Tach,
Debian nutzt seit mindestens Etch UTF-8 als Standard; Ubuntu basiert darauf und auch da habe ich noch keinen anderen Standard gesehen.
Das "reine" Debian habe ich vor einiger Zeit mal in einer 6.x-Version installiert (keine Ahnung, welcher Codename dazu gehört), das kam mit Standard-locale ISO-8859-1, AFAIR. Ubuntu habe ich von Version 7 bis 11 gehabt, die hatten alle in der Default-Installation kein UTF-8. Und von Mint habe ich die Versionen 12 (Lisa), 13 (Maya) und die aktuelle 17 (Qiana) intensiv kennengelernt; erst die 17 kam mit UTF-8 als Default, bei 12 und 13 musste ich ein UTF-8-locale noch manuell nachinstallieren.
Dasselbe gilt für Raspbian, wenn das nicht in den letzten 8..10 Monaten geändert wurde.
deine Erinnerung trügt, Etch war Debian 4.0; bei Ubuntu war es lt. Doku mindestens ab Feisty Fawn, das war 7.04, so. Für Mint kann ich nicht sprechen, da habe ich keine Erfahrung mit, aber beim Debian-basierten Raspbian würde es mich wundern (und dieser Artikel von 2012 spricht auch von einem UTF8-Locale als Standard).
Hier muss ich mich korrigieren, sorry, ich meinte in der Tat genau das Gegenteil: Um mit Windows-Clients kompatibel zu sein, muss man Samba sehr gezielt konfigurieren. Da hatte ich anfangs große Schwierigkeiten, richtig reibungslos funktionierte es erst mit der Kombination der Direktiven
unix charset = utf-8 dos charset = 437 display charset = utf-8in der smb.conf.
Die sind nicht nötig, da das die Standards sind.
mfg
Woodfighter
Hi,
deine Erinnerung trügt, Etch war Debian 4.0; bei Ubuntu war es lt. Doku mindestens ab Feisty Fawn, das war 7.04, so. Für Mint kann ich nicht sprechen, da habe ich keine Erfahrung mit, aber beim Debian-basierten Raspbian würde es mich wundern (und dieser Artikel von 2012 spricht auch von einem UTF8-Locale als Standard).
hmm, dann frage ich mich natürlich, was ich "falsch" gemacht habe.
unix charset = utf-8 dos charset = 437 display charset = utf-8Die sind nicht nötig, da das die Standards sind.
Seit wann? Ich habe diese Kombination mit geduldigem Trial & Error und regelmäßiger Konsultation des Samba-Manuals herausgefunden. In allen anderen getesteten Varianten gab es immer Probleme bei Non-ASCII-Zeichen mit Windows-Clients, teilweise sogar mit Linux-Clients. Aber das was so um 2009, 2010. Mag sein, dass sich seitdem einiges geändert hat, aber diese drei Direktiven habe ich seither immer in meiner smb.conf drin.
So long,
Martin
Tach,
unix charset = utf-8 dos charset = 437 display charset = utf-8Die sind nicht nötig, da das die Standards sind.
Seit wann?
Samba 3 (released on 23 September 2003), das war damals 'ne größere Umstellung und es könnte etwas gedauert haben bis das in den Distris ankam, in Debian war es ab Sarge (2005).
mfg
Woodfighter
Tach!
ein PHP-Script aber Dateinamen in irgendeiner ISO-Latin-Codierung ans OS übergibt.
Der Bug ist in diesem PHP-Script zu fixen.
Unmöglich. Es gibt keine Konfigurationseinstellungen oder Funktionen in PHP, mit denen man eine Kodierung für das Dateisystem vorgeben könnte. Es ist auch nirgends erwähnt, welche verwendet werden soll.
Dumm nur, wenn mehrere Anwendungen (z.B. der Webserver und PHP) auf Dateien zugreifen und unabhängig voneinander verschiedene Codierungen annehmen
Hallo-o, es ist 2015! Es sollte bei der Kommunikation zwischen Systemen nirgends mehr eine andere Zeichencodierung als UTF-8 Verwendung finden.
Sag das bitte den Systemen, die immer noch nicht fertig sind mit der Implementierung von Mehrbyte-Kodierungen.
dedlfix.
Tach,
ein PHP-Script aber Dateinamen in irgendeiner ISO-Latin-Codierung ans OS übergibt.
Der Bug ist in diesem PHP-Script zu fixen.
Unmöglich. Es gibt keine Konfigurationseinstellungen oder Funktionen in PHP, mit denen man eine Kodierung für das Dateisystem vorgeben könnte. Es ist auch nirgends erwähnt, welche verwendet werden soll.
ich gehe davon aus, dass PHP unter Linux auf den Inhalt von $LANG schauen wird, so wie so ziemlich alles andere auch, unter Windows gibt es heutzutage da eh keine Alternativen mehr.
PHP 5.3 hat mit
<?
$fp = fopen("/tmp/ſẞ….tmp","w");
fclose($fp);
und LANG=en_US.utf8 kein Problem; hätte mich auch gewundert, da die Funktionen eh nur Wrapper für die entsprechenden C-Funktionen sind.
mfg
Woodfighter
Tach!
ich gehe davon aus, dass PHP unter Linux auf den Inhalt von $LANG schauen wird,
Das kann ich jetzt so nicht beobachten. Mein System steht laut localectl auf LANG=en_US.UTF-8. Ein UTF-8-kodiertes Script legt die Dateinamen lesbar an. Soweit so gut. Konvertiert nach ISO-8859-1 gibt es Kästchen. LANG=es_US.iso88591 php test.php ändert daran nichts. Erwartet hätte ich dann einen lesbaren Dateinamen vorzufinden. Ich weiß aber nicht, ob das Linux dann Zeichenkodierungen übersetzt, so wie es beispielsweise MySQL zwischen der Verbindungskodierung und den Feldkodierungen macht.
PHP sagt einem nicht, welche Kodierung das System erwartet und eine Funktion zum Ermitteln von LANG gibt es meines Wissens nicht. Kann man anscheinend nur über einen Shell-Aufruf rausfinden.
dedlfix.
Tach,
ich gehe davon aus, dass PHP unter Linux auf den Inhalt von $LANG schauen wird,
Das kann ich jetzt so nicht beobachten.
ich auch nicht. Aber ich habe herausgefunden, dass das bei Debian installierte PHP erwartet, dass Scripte UTF-8 sind unabhängig vom eingestellten Locale; laut Doku sollte PHP eigentlich ISO8859-1 erwarten, solange es nicht mit „--enable-zend-multibyte“ kompiliert bzw. mit „zend.multibyte=On“ eingeschaltet wurde sowie ein anderer Standardwert gesetzt ist. Auf meinem System ist dem aber nicht so, auch mit zend-multibyte und declare liest die PHP-CLI ISO-kodierte Dateien nicht korrekt. Ich habe es auch mal auf UTF-16 gestellt, und wenn zend.multibyte an ist, stolpert PHP zumindest schonmal nicht mehr über das BOM, aber kann dann auch keine Multibyte-Strings lesen oder verarbeiten oder ausgeben: echo "ä" in einer UTF-16 kodierten Datei gibt die Bytes e4 3f 3f aus e400 wäre das ä in UTF-16 und 3f sind Fragezeichen in UTF-8, aber so richtig Sinn ergibt das nicht (Ausgabe bleibt auch gleich egal ob default_charset auf UTF-8 oder UTF-16 steht)
PHP sagt einem nicht, welche Kodierung das System erwartet und eine Funktion zum Ermitteln von LANG gibt es meines Wissens nicht. Kann man anscheinend nur über einen Shell-Aufruf rausfinden.
Den Landes- und Sprachteil bekommt man über die Locale-Klasse, sofern vorhanden; aber das Encoding verschweigt es.
mfg
Woodfighter
Tach,
ich als Servermensch frage mich: Welches Dateisystem bzw welche Tools haben damit noch ein Problem?
ja, jetzt kommen wir der Sache langsam näher. Das Problem, das ich sehe, liegt im Fehlen jeglicher Information, welche Zeichencodierung das Dateisystem bzw. dessen API verwendet.
äh nein, in der Windows-Datei-Api ist es als wchar_t* deklariert und unter POSIX-Systemen hängt die Interpretation tasächlich vom eingestellten Locale des Users ab, ein Pfadname ist hier ein C-„String“.
mfg
Woodfighter
Hi,
Das Problem, das ich sehe, liegt im Fehlen jeglicher Information, welche Zeichencodierung das Dateisystem bzw. dessen API verwendet.
äh nein, in der Windows-Datei-Api ist es als wchar_t* deklariert ...
so einfach ist es nicht, denn es gibt unter Windows sowohl die "modernen" Funktionen, die mit WCHAR arbeiten, also UCS-2 (eine Untermenge von UTF-16), daneben aber der Kompatibilität wegen auch noch die "alten" Funktionen, die eine Ein-Byte-Codierung verwenden. Letztere nutzt PHP, wie wir in einem länger zurückliegenden Thread lernen durften (AFAIR war es Linuchs, der in genau diese Problematik auf einem Windows-Host gelaufen war).
und unter POSIX-Systemen hängt die Interpretation tasächlich vom eingestellten Locale des Users ab, ein Pfadname ist hier ein C-„String“.
Eben, also eine Folge von Bytes ohne Angabe der Codierung.
So long,
Martin
Tach,
so einfach ist es nicht, denn es gibt unter Windows sowohl die "modernen" Funktionen, die mit WCHAR arbeiten, also UCS-2 (eine Untermenge von UTF-16), daneben aber der Kompatibilität wegen auch noch die "alten" Funktionen, die eine Ein-Byte-Codierung verwenden. Letztere nutzt PHP, wie wir in einem länger zurückliegenden Thread lernen durften (AFAIR war es Linuchs, der in genau diese Problematik auf einem Windows-Host gelaufen war).
uargh, kann ich bestätigen mit PHP 5.6.14 (allerdings sind die amd64-builds auch noch als experimentell gekennzeichet, ist ja auch erst 6 Jahre her, dass das die von MS bevorzugte Plattform ist).
und unter POSIX-Systemen hängt die Interpretation tasächlich vom eingestellten Locale des Users ab, ein Pfadname ist hier ein C-„String“.
Eben, also eine Folge von Bytes ohne Angabe der Codierung.
Ja, die Kodierung wird bei POSIX beim Lesen und Schreiben von den Systemvariablen gesetzt; Standard bei Linux- und BSD-Distributionen (soweit ich das sehe) ist hier UTF-8.
mfg
Woodfighter