Welche charset-Angabe im Header ist richtig?

[hotti]

hi,

s. Thema, im Response-Body steht ein Name=Value Paar:

animal=Gr%C3%BCner%20B%C3%A4r

was aufgrund des Percent-Encoding nur ASCII-Zeichen enthält. Ein Header
  Content-Type: text/plain; charset=US-ASCII

würde dazu passen. Nachdem die Prozentkodierung wieder rückgängig gemacht wurde, stellt sich jedoch heraus, dass die resultierenden Zeichen UTF-8 sind.

Was nun?

Hotti

[dedlfix]

Tach!

im Response-Body steht ein Name=Value Paar:
  animal=Gr%C3%BCner%20B%C3%A4r
was aufgrund des Percent-Encoding nur ASCII-Zeichen enthält. Ein Header
  Content-Type: text/plain; charset=US-ASCII
würde dazu passen. Nachdem die Prozentkodierung wieder rückgängig gemacht wurde, stellt sich jedoch heraus, dass die resultierenden Zeichen UTF-8 sind.

Wann passiert die Rückgängigmachung? Wenn du ein neues Dokument erzeugst, dann muss die Angabe zum Inhalt passen. Wenn der verarbeitende Prozess das Dokument hingegen korrekt lesen konnte und anschließend irgendwas mit den Daten anstellt, ist das sein Problem und nicht mehr das der Quelle. Die Quelle muss und kann nicht wissen, was mit den Daten passiert. Sie muss nur für sich selbst sprechen.

dedlfix.

[hotti]

ni,

im Response-Body steht ein Name=Value Paar:
  animal=Gr%C3%BCner%20B%C3%A4r
was aufgrund des Percent-Encoding nur ASCII-Zeichen enthält. Ein Header
  Content-Type: text/plain; charset=US-ASCII
würde dazu passen. Nachdem die Prozentkodierung wieder rückgängig gemacht wurde, stellt sich jedoch heraus, dass die resultierenden Zeichen UTF-8 sind.

Wann passiert die Rückgängigmachung? Wenn du ein neues Dokument erzeugst, dann muss die Angabe zum Inhalt passen. Wenn der verarbeitende Prozess das Dokument hingegen korrekt lesen konnte und anschließend irgendwas mit den Daten anstellt, ist das sein Problem und nicht mehr das der Quelle. Die Quelle muss und kann nicht wissen, was mit den Daten passiert. Sie muss nur für sich selbst sprechen.

Ja, das denke ich auch, HTTP ist Layer 4, das ist nicht die Darstellungsschicht, korrekt wäre daher charset=US-ASCII.

Andererseits ist bei solchen proprietären Schnittstellen der Content-Type eher uninteressant, weil die Verarbeitung des Message-Body ebenfalls proprietär ist. Dieses Thema ist mir beim Entwickeln eines UserAgent für PayPal untergekommen, die bieten als Alternative zu SOAP einen Webservice an, der mit genau solchen Name=Value Wertepaaren funktioniert, die URL-encodet sind (percent encoding) und damit nur ASCII-Zeichen enthalten.

Der Webservice von PayPal sendet dazu einen
  Content-Type: text/plain; charset=UTF-8

Nur malso nebenbei ;)

Hotti

[Tim Tepaße]

Andererseits ist bei solchen proprietären Schnittstellen der Content-Type eher uninteressant, weil die Verarbeitung des Message-Body ebenfalls proprietär ist.

Prozentkodiertes im Message-Body ist ja nicht ganz so proprietär, sondern aus dem Absenden von HTML-Formularen via POST bekannt. Hixie hat versucht in seiner Megaspezifikation den zugehörigen Quasi-Media-Typ application/x-www-form-urlencoded zu spezifizieren, mit all seinen historisch begründeten Warzen. Das wäre dann eine Möglichkeit. Bei der – wieder historisch begründet – dann der charset-Parameter entfällt bzw. ignoriert wird.

Könnte man nutzen. Oder Paypal wechselt einfach auf was vernünftiges und damit meine ich nicht SOAP. ;)