MVWeb API: Encoding der Ergebnisse

[Programmer77]

Hallo!

In den letzten Tagen ist mir aufgefallen, dass die JSON-Ergebnisliste vom API nicht mehr UTF8-codiert ist, sondern latin1. Der HTTP-Header ist immer noch content-type: application/json; charset=utf-8. Trotzdem kommt z.B. ein “ö” als 0xF6 rüber, was zu latin1 passt.

Ist das ein Problem vom Upstream (ARD/ZDF in meinem Fall), oder wurde serverseitig etwas geändert?

Ist abzusehen, dass es demnächst wieder UTF-8 wird, oder lohnt es sich, meine Scripte umzustellen, um latin1 zu erwarten?

VG,
Mike

[pidoubleyou]

@Programmer77 wenn ich MVWeb nutze, kann ich auf den ersten Blick kein Problem erkennen. Hast du konkrete Beispiele?

[Programmer77]

Im Web sieht alles OK aus. Aber wenn ich über die API draufgehe, bekomme ich latin-1.

curl \
     -v \
     -XPOST https://mediathekviewweb.de/api/query \
     -H'Content-Type: text/plain' \
     -d'
{
   "queries" : [
      {"fields" : ["topic"], "query" : "Deadly Tropics"}
   ]
}'

Liefert eine Datei, die python erst mal nicht interpretieren kann:
'utf-8' codec can't decode byte 0xf6 in position 960: invalid start byte

An der Stelle soll ein “ö” sein. Was auf meine UTF8-Konsole so dargestellt wird.
"title":"H�llentrip mit Todesfolge (S03/E04)"
Also mit dem Unknown Code marker.

Mit iconv kann ich es korrekt von latin-1 nach utf-8 konvertieren. Es geht also zumindest bei dieser Anfrage nicht um einzelne Einträge der Ergebnisliste.

[Programmer77]

Ich hatte gerade noch die Idee, es mal “umgekehrt” zu versuchen. Wenn ich ein “ß” in die Anfrage reinpacke (also z. B. nach “Lindenstraße” suche), kommen Ergebnisse zurück. Also wird das “ß” richtig erkannt. Auch die Ergebnisse sind richtig.

Andererseits sind auch die Ergebnisse für “Shaun, das Schaf” falsch. Es liegt also auch nicht nur an einer Sendung.

[Programmer77]

Und jetzt habe ich noch einen Fall, wo die Ergebnisse gemischt sind.

curl \
     -XPOST https://mediathekviewweb.de/api/query \
     -H'Content-Type: text/plain' \
     -d'
{
   "queries" : [
      {"fields" : ["topic"], "query" : "Ein Fall für zwei"}
   ],
   "sortBy" : "timestamp", "sortOrder" : "asc",
   "future" : true,
   "offset" : 45, "size" : 5
}'

liefert latin-1, mit offset 46 aber utf-8.

Mit size 2 liefert offset 45 - 48 latin1, 49 und 50 UTF-8.

Einzeln (size 1) liefern offset 45 bis 49 latin1 und 50 UTF-8.

Es gibt also offenbar Einträge in der DB, die als UTF-8 ausgeliefert werden. Und wenn so einer dabei ist, werden die anderen konvertiert. Oder so irgenwie.

@pidoubleyou : Kannst Du das reproduzieren?

Mike

[digi_casi]

ich kann das problem bestaetigen.
bei mir kommt es immer, wenn ich alle movies auf one oder ard-alpha anfordere.
er meckert ueber den buchstaben 0xfc also ü.

[pidoubleyou]

ich kann es mit der API reproduzieren. Der Input aus dem Crawler sieht korrekt aus.

@bagbag kannst du dir das mal anschauen?

[bagbag]

Das kommt durch diesen Bug: https://github.com/nodejs/node/issues/54543

Habe natürlich genau mit der betroffnen Version zuletzt gebaut. Update ist deployed - sollte also wieder passen.

nikhilro created this issue in nodejs/node

closed UTF+8 encodings are broken #54543

[digi_casi]

@bagbag
bei mir taucht das problem nicht mehr auf. danke.

[Programmer77]

@bagbag
Ich kann auch bestätigen, dass jetzt wieder alles konsistent richtig ist. Mal wieder typisch Murphy, dass genau die Version im Build gelandet ist…

Danke für den schnellen Fix!

Mike