json_encode und andere Encodings als UTF-8

K

KtmnjjpfjsFvzG

New member
Hi,

ich möchte eine HTML-Seite per JSON zurückgeben, allerdings mit mehreren zusätzlichen Infos, also z.B.

{info: 1, info2: 1000, info3: "xyz", htmlseite:"<html><head>...</head><body>...<body></html>"}

Diese HTML-Seite soll jedes valide HTML-Dokument sein können und wird später in einem <iframe> angezeigt.

Allerdings ist sie nicht immer UTF-8 encoded! Da es ja meistens einen <meta> Tag für die encoding gibt, kann ich auch nicht einfach die encoding auf utf-8 ändern, denn dann stimmem <meta> und die tatsächliche encoding nicht mehr überein.

Was mache ich? Wie kann ich andere encodings als UTF-8 per JSON übertragen?

Danke schonmal! :)

K.
 
Ja, da steht, dass man utf8_encode nutzen soll, was aber ja bei mir eben nicht möglich ist, da ich die Encoding nicht verändern möchte...
 
Ja, hmmm, leider weiß ich ja noch nichtmal, welche Encoding genutzt wird, und es gibt auch nicht nur 2 möglichkeiten (wie dort), sondern quasi unendlich. wenn im jahre 2020 irgendjemand eine neue encoding namens utf-999 erfindet, dann soll das ganze ja auch immer noch funktionieren, ohne dass ich extra eine utf-999-umsetzung einbaue (hoffe es ist in etwa klar, was ich damit meine...)

wenn ich auf json verzichte, ist das ganze ja gar kein problem, ich kann die seite einfach per echo ausgeben ohne mich um die encoding zu kümmern.

ich hatte eher an etwas wie rawurlencode() und decodeURIComponent() gedacht, aber leider klappt das nicht... :|
 
Also ich habe mir abgewöhnt, alles Eventualitäten zu berücksichtigen sondern orientiere mich an dem, was aktuell verfügbar ist. Und da würde ich sagen, UTF-8 ist im Moment die beste Wahl im Browser Geschäft. Wenn ein Webauftritt sein Encoding ändert ist das immer ein Projekt und nicht nur mit einem einfachen Schalter getan. Ich bin überzeugt, wenn du jetzt eine Lösung finden würdest, würde diese im Jahr 2020 trotzdem nicht mehr klappen :)
 
Ja, aber das Problem ist ja eigentlich auch ein anderes. Die Seiten sind einfach irgendwelche HTML-Dokumente, nicht aus dem Web geladen, sondern in etwa 10.000 bereits fertige, einfache .html-Dokumente. Welche Encoding diese haben, ist mir ->garnicht bekannt!<-

Hier: PHP: utf8_encode - Manual steht allerdings folgendes: "Konvertiert eine ISO-8859-1-Zeichenkette in UTF-8".
Wenn ich jetzt ein Dokument habe, das weder ISO-8859-1 noch UTF-8 ist, bringt mir das halt nichts.

Darüber hinaus gibt es das angesprochene Problem mit dem <meta charset> Tag, der ja Teil des Dokumentes ist. Wenn dort noch die alte encoding drinsteht, aber das Dokument eigentlich UTF-8 ist, kommt es ja auch zu darstellungsfehlern...

Also: Ich selbst nutze nie etwas anderes als UTF-8, aber umwandeln steht halt in diesem Fall nicht zur Debatte, leider. :(
 
Aber wenn dir das Encoding der Doks nicht bekannt ist kannst du das Problem nicht lösen. Denn normalerweise liest man ein Dokument ein und wandelt es dann zu allererst in das interne Format der Scriptingsprache. Bei Perl z.B. ist das eine Art UTF-8. Das heißt, ich lese das Dokument ein und hole es erstmal in das Perleigene Format "runter" mit
Code: 
decode("windows-1252",$input)
(wenn es z.B. ein Windows ANSI Dokument ist). Von jetzt an liegt das Dok intern im Rohformat vor und kann in jedes xbeliebige Format für die Ausgabe sauber konvertiert werden.
Wenn man das Dok Encoding nicht weiß muss man dieses Problem zuerst lösen, bevor man an die Ausgabeseite überhaupt denken kann. In Perl gibt es Module, die versuchen es zu erraten. Ansonsten muss man das von Hand klassifizieren oder eine Annahme treffen und mit den Fehlern leben.
 
Eben nicht - Meine Webanwendung ist nur der Übertragungsweg. Das HTML-Dokument und der Browser, in dem das iframe angezeigt wird, müssen das mit der Ausgabe unter sich abklären - da will ich mich garnicht einmischen. Der HTML-Code soll möglichst nicht verändert werden.

Ich möchte quasi eine beliebige Encoding "durch utf-8 tunneln".
 
Glaube nicht, dass das geht. Denn es sind ja keine Binärdateien zum durchreichen sondern es ist Quellcode den der Browser lesen und für den Benutzer im richtigen lesbaren encoding darstellen können muss. Dafür musst du dem Browser sagen, welches Encoding er bekommt und genau das ist bei JSON eben über UTF-8 einheitlich festgelegt.
Aber mal abwarten, was die anderen dazu sagen.
 
Der <meta> Tag sagt es dem Browser, der ist in der HTML-Datei vorhanden...

Also wie es wohl gehen würde:
- PHP: HTML-Dokument parsen und <meta> suchen, encoding als X speichern
- PHP: HTML-Dokument von X nach UTF-8 umwandeln per mb_convert_encoding
- Umgewandeltes Dokument und X übertragen
- JS: HTML-Dokument von UTF-8 nach X umwandeln (per ???? - es gibt kein mb_convert_encoding in JS)
- JS: HTML-Dokument ins <iframe> schreiben

Wie ich es aber viel lieber haben möchte:
- Nicht umgewandeltes Dokument übergeben
- JS: HTML-Dokument ins <iframe> schreiben

Ich halte das einfach für robuster und sinnvoller, ist doch irgendwie blöd, sowas hin- und herzuencoden...
 
Hast du denn den unteren Weg mit einem Dok mit außergewöhnlichem Encoding einfach mal getestet?
Ansonsten könnte man vielleicht ein zusätzliches Serverscript als Auslieferer verwenden. Man bestückt also das iframe nicht mit Code sondern mit einem Link zum Auslieferer und dieses Auslieferscript schickt das Dok einfach ganz unbehandelt quasi wie eine Binärdatei an den Browser. Ich würde diese Wege einfach mal testen.
 
Ja, das klappt problemlos, JSON ist das Problem... leider sind so halt immer 2 Requests nötig, da ja in JSON noch mehr Infos drinstehen, aber damit muss ich dann wohl klarkommen.
 
Also erst mal: JSON hat überhaupt kein encoding - es gibt nur ein Übertragungsencoding, das durch den Server im HTTP-Header festgelegt wird. Wenn man Zeichen außerhalb der "normalen" Zeichen haben will, muss man die mit \xHH oder \uHHHH (das H steht für eine hexadezimale Zahle) kodieren - so wie man das in JS hald auch sauber macht.

Dass json_encode nur mit UTF8 umgehen kann ist eine Unzulänglichkeit von PHP. Prinzipiell kann man mit JSON sogar Binärdaten übertragen.

Also wenn du eine andere Codierung hast, musst du dir dein JSON einfach per Hand zusammenbauen und alles, was außerhalb der "Printables" liegt, durch das obige Schema escapen.

PS: wenn du verschiedene Kodierungen in deiner DB speichern willst, kann das schnell mal zu Problemen führen... pass da einfach mal auf.
PPS: json_encode könnte für deinen Fall sogar eventuell mit utf8 falsch laufen, da der String in JS dann in UCS-2 vorliegt... k.A. was der Browser dann damit anfängt, wenn du das ins srcdoc (das ich, wie schon gesagt, nicht verwenden würde...) schreibst.
 
Korbinian, das will er ja alles nicht. Er möchte die Dateien über JSON 1:1 zum Browser senden und den Inhalt nicht anfassen. Dass das so nicht geht hatten wir ja schon festgestellt.
 
Äh... ich hab' doch beschrieben, wie er die Dateien so, wie sie sind, über JSON an den Browser senden kann... nach dem JSON.parse() liegt der String so vor, wie er gespeichert wurde (gut, nicht ganz, da es UCS-2 ist, aber das obere Byte ist immer leer)...

Z.B.
Code: 
{"data": "\xFC"}
Das ist ein "ü" in Latin-1...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben