fireweasel

Vorweg noch was zum (Ursprungs-)Thema: Die schon erwähnte "intl"-Erweiterung besitzt in den neueren Versionen eine Klasse Transliterator, mit der man bspw. deutsche Umlaute nach ASCII wandeln kann. Wenn ich die Anleitung richtig verstanden habe, kann sie sowohl mit "decomposed" als auch mit "precomposed" Zeichen umgehen. Dummerweise macht sie aus 'ä' nur ein 'a' und kein 'ae'. Auch hat die Konvertierung 'Any-ASCII' bei mir nicht funktioniert (es lies sich kein Transliterator-Objekt damit erzeugen), 'Latin-ASCII' dagegen schon.

Sieht so aus. Man muss aber aufpassen, diese kombinierenden Zeichen nur mitzuzählen, wenn sie auf Buchstaben folgen. Folgen sie auf ein Non-Breaking-Space (\x{a0}), dann stellen sie sich lediglich selbst dar. Ansonsten scheinen sie quasi "Nicht-Zeichen" zu sein.

Pffft. Der Erbsenzähler in mir sagt: Ja. Immer, wenn Unicode-kodierte Texte aus fremden Quellen kommen, für die du nicht garantieren kannst, dass ...
* alle "precomposable" Buchstaben "precomposed" sind oder
* nur Buchstaben enthalten sind, die "precomposable" sind.

... oder (einfacher) wenn dieser PCRE anschlägt:
In der Praxis werden es, wie immer, (fast) alle ignorieren.

Andererseits ist das hier ein "Feature"[0] der Dateisystem-Unterstützung von PHP. Da diese unter Windows gar nicht Unicode-fähig ist und unter Unix-(POSIX?)-APIs anscheinend einfach die Pfadnamen weiterleitet, anstatt sie zu vereinheitlichen, darf man sich auf der Anwendungsebene damit herumschlagen.

--
[0] Fehler darf man ja nicht sagen, das ist alles "by design" ...

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

Mister Ad

nikosch

Ich kann das nicht nachvollziehen. Ein Umlaut ist ein echter Buchstabe, keine besondere Betonung oder so. Unicode wurde dafür geschaffen, alle Zeichen Problemlos abbilden zu können, selbst Ligaturen und Mediävalziffern werden als eigener Unicode geführt. Umlaute aus zwei Zeichen zu kombinieren ist absolut inkonsequent. Jedenfalls für die deutsche Sprache.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

fireweasel

Nein (deutsche) Umlaute sind gewöhnliche lateinische Buchstaben, versehen mit einem speziellen Zeichen ("Diärese" e.t.c.). Sprachhistorisch sind sie aus Ligaturen, also Kombinationen aus mehreren Buchstaben, entstanden, das 'ä' bspw. aus der ae-Ligatur. Das sie als "gewöhnliche" Buchstaben betrachtet werden, liegt daran, dass man sich als Muttersprachler daran gewöhnt hat.
Im asiatischen Raum, stellen deutsche Umlaute und ß regelmäßig eine "besondere Zeichengattung" dar, wie man an kreativ gestalteten Bedienungsanleitung immer wieder sehen kann.

Aber wir sollten bei der technische Komponente bleiben ...

Wenn man Kombinationen aus lateinischen Buchstaben und diese modifizierende Zeichen zulässt, kann man mehr Zeichen aufnehmen, als wenn man für jede gewünschte Kombination einen extra Codepoint reserviert.

Mir scheint dass sie den Anspruch "alle Zeichen aufzunehmen" irgendwann aufgegeben und durch das Motto ersetzt: "Wir schauen, bis sich genügend Leute finden, die wollen, dass eine Gruppe von Zeichen aufgenommen werden soll" (siehe Smileys, Emoji usw.). Zugegeben, es ist auch schwer, eine allgemein akzeptierte Definition von "Zeichen" zu erschaffen. Mir fallen da bspw. gerade Verkehrszeichen ein ...

Was unsinnig ist, weil Ligaturen kein Problem der Zeichenkodierung sondern eines der Zeichendarstellung sind. Gleiches gilt für Medieval-Ziffern: Entweder hat ein Font solche Ziffern oder nicht. Etwas anderes wären bspw. die römischen Zahlzeichen.

Erstmal ist das die vorgeschriebene Marschrichtung für die Aufnahme weiterer Zeichen. Das ist verständlich, weil man nicht für alle beliebigen Kombinationen Platz frei halten will oder haben wird. Außerdem macht jedes neue Zeichen mit diakritischem Anbau die Suche und Sortierung komplexer (Die Tabellen für die "Collation-Sequences" werden noch größer).

Was die Inkonsequenz betrifft, bin ich deiner Meinung. Aber wenn man sich Überarbeitung für Überarbeitung des Unicode-"Standards" ansieht, ist da konsequente Inkonsequenz das erste, an was man sich gewöhnen muss. Menschliche Schrift(sprache) in Regeln zu pressen zu wollen ist halt kompliziert.

Ehrlich gesagt, sind mir deutsche Befindlichkeiten dabei egal. Die waren in ASCII nicht gewahrt und bei den 8-Bit-Zeichensätzen hatten die Deutsch(sprachig)en halt Glück, dass mindestens einer dabei war, der ihren Ansprüchen genügte und auch noch so Sachen wie Groß-Kleinschreibung mit einem Bitflipping erledigt war. Das waren halt die glücklichen 1980-er (und frühen 1990-er) Jahre ...

Dass ein Zeichen mehr als ein Byte sein kann, haben wir gelernt, da sollte es nicht schwerfallen auch zu akzeptieren, dass ein Zeichen aus mehr als einen Codepoint zusammengesetzt sein kann.

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

dazlious

Ich habe leider heute keinen Mac da, aber ich werde es am Montag testen und mich dann melden, ob es funktioniert hat oder aber wo es noch hakt

Kannst du mir noch sagen, wo du die Kodierung gefunden hast (A\314\210, usw)?

Brauch nämlich noch ein ß

Vielen lieben Dank schon mal für die Antwort, kann morgen kaum abwarten

elise

Das Eszett hat nichts mit diesem Format zutun.
Entweder du nimmst die utf8-encode-Zeile raus und benutzt einfach 'ß', oder eben vorher einen utf8-encode über 'ß'.

__________________
OSL♥

dazlious

Es hat einwandfrei funktioniert. Vielen lieben Dank!

ß hat er so angenommen.

Endlich ist auch das Problem gelöst!