Soll man utf8_encode nicht verwenden!
Genau. Wenn du sicher weißt, dass deine Quellkodierung ISO-8859-1 ist, dann kannst du utf8_encode (gemäß seiner API-Dokumentation) verwenden. Aber selbst wenn das der Fall ist, finde ich den Namen so irreführend und nichtssagend, dass ich lieber iconv verwenden würde.
Wie sieht es mit rawurlencode aus?
tl;dr: Die Funktion kannst du mit beliebigen Eingabedaten (als beliebige Bytes) verwenden. Zur Dekodierung bitte rawurldecode benutzen.
Längere Erklärung/Findungsweg:
Das ist eine gute Frage! rawurlencode sieht mir eigentlich nach einer Funktion aus, die eine Quellekodierung als Argument nehmen müsste -- oder eben implizit eins verwendet. Auf der PHP Dokuseite zu rawurlencode sehe ich allerdings keine Rede von irgendeiner Kodierung. Aber es steht geschrieben, dass die Funktion nach
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax (RFC3986) handelt.
Auszüge:
RFC 3986 hat gesagt.:
1.2.1. Transcription
[...]
In local or regional contexts and with improving technology, users
might benefit from being able to use a wider range of characters;
such use is not defined by this specification. Percent-encoded
octets (Section 2.1) may be used within a URI to represent characters
outside the range of the US-ASCII coded character set if this
2.5. Identifying Data
[...]
When a new URI scheme defines a component that represents textual
data consisting of characters from the Universal Character Set [UCS],
the data should first be encoded as octets according to the UTF-8
character encoding [STD63]; then only those octets that do not
correspond to characters in the unreserved set should be percent-
encoded. For example, the character A would be represented as "A",
the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
as "%C3%80", and the character KATAKANA LETTER A would be represented
as "%E3%82%A2".
Ich könnte mir also vorstellen, dass rawurlencode einfach naiv den String byteweise durchgeht und -- soweit der Character von RFC 3986 abgdeckt ist -- prozentkodiert -- oder soweit von RFC 3986 unbehandelt -- als "percent-encoded octets" kodiert.
Dementsprechend müsste rawurlencode mit jeder Quellkodierung zurecht kommen, solange Daten in dieser Quellkodierung byteweise aufsplittbar sind. Dass Daten byteweise gespeichert sind, ist jedoch Standard auf normalen PCs und Server und sogar auf vielen Mikrocontrollern. Da musst du wahrscheinlich schon echt Geräte aus den 60er (?) ausgraben, um andere Speicherformen zu finden.
Theoretisch könntest du rawurlencode also auch rohe Bytes einer Binärdatei zukommen lassen, etwa von einer .exe-Datei.
Wichtig ist nur, dass wenn du die Daten wieder zurückmöchtest, dass du dann rawurldecode aufrufst, damit die Kodierung rückgängig gemacht wird.
Meine Vermutung, dass rawurlencode und rawurldecode beide byteweise arbeiten, deckt sich auch mit einem Kommentar von
PHP: rawurldecode - Manual:
jakub 2014-01-24 07:59 hat gesagt.:
Be aware that rawurldecode does not warn you in any way if the output is nonvalid UTF-8.
For example if the input passed to the function is just "%C5", then since C is 1100 in binary, and UTF-8 characters starting with 110 should be followed by another character, the result of rawurldecode will be just a single byte (with value \xC5) which is not a correct UTF-8.
Theoretisch müsste man also nach Aufruf von rawurldecode noch prüfen, ob die Bytes in der erwarteten Kodierung überhaupt valide sind.
Fazit: rawurlencode nimmt rohe Bytes entgegen und gibt ASCII aus. rawurldecode nimmt ASCII entgegen und gibt rohe Bytes aus.
