Umlaute und Sonderzeichen in Unicode-Entities konvertieren.

[Arne Drews]

Hi,


Ich bediene eine Schnittstelle der Post CH und übermittle die Daten per JSON, wie es die Schnittstelle erfordert.
Meine Anfragen wurden ständig mit Fehlern beantwortet. Der Grund ist der, dass bspw. Umlaute nicht als Unicode-Entities angegeben sind.

Mein String ist Unicode bzw. UTF8, was ich jeweils wie folgt angewendet habe:
[highlight=csharp]
// Unicode
byte[] b = Encoding.Default.GetBytes( this.JSON );
byte[] bu = Encoding.Convert( Encoding.Default, Encoding.Unicode, b );
this.JSON = Encoding.Unicode.GetString( bu );

// UTF8
byte[] b = Encoding.Default.GetBytes( this.JSON );
byte[] bu = Encoding.Convert( Encoding.Default, Encoding.UTF8, b );
this.JSON = Encoding.UTF8.GetString( bu );
[/highlight]
Dennoch bekomme ich weiterhin den gleichen Fehler von der Schnittstelle.
Wenn ich aber ü bspw. gegen \u00fc ersetze funktioniert es einwandfrei.

Um die Schnittstelle nun nutzen zu können, würde mich interessieren, ob es eine Möglichkeit gibt, die Entity-Ersetzungen vom System übernehmen zu lassen, anstatt dies mit Replace() umzusetzen?

Danke

[defo]

Ich kann Dir zu C# nichts sagen.
Aber ich finde so eine Konvertierung macht überhaupt nur Sinn, wenn das "Kernencoding" nicht UTF8 oder Unicode ist. Denn beide würden ja Umlaute usw. ohne weiteres abbilden.
Wenn Du also eine wie auch immer von der Post CH geforderte JSON Datei abgibst, müsste diese evtl. ein Non Unicode Encoding verlangen (vlt irgendeine single Byte Kodierung), die dank der bekannten Unzulänglichkeiten dann gezwungenermaßen für Sonderzeichen die Unicode Entities "verlangt".
Dieses "schräge Encoding" entsteht vielleicht automatisch, wenn Du die Encoding Funktionen in C# mit einem entsprechenden - vielleicht sogar in den Specs der Post CH angegebenen (und eigentlich unzuänglichen) Encoding abfragst.

Klingt irgendwie nach Murks, sorry, mehr fällt mir dazu nicht ein.

[Ralf Jansen]

Du zeigst irgendeine Konvertierung. Das zu irgendeinem Zeitpunkt für JSON etwas systemabhängiges wie Encoding.Default verwendet wird ist extrem unwahrscheinlich.
Was steckt also genau in this.JSON? Wo kommt es her und wie ist es da hingekommen? Da es offensichtlich ein .Net string ist wie sind da falsch kodierte Daten rein gekommen?
Jeder Json Serializer würde automatisch utf-8 verwenden. Da muss man schon ziemlichen Aufwand betreiben um da was anderes hinzubekommen.

Wenn Du also eine wie auch immer von der Post CH geforderte JSON Datei abgibst, müsste diese evtl. ein Non Unicode Encoding verlangen

Per Definition/Standard ist JSON immer Unicode. Und persönlich würde ich sogar sagen das alles was nicht utf-8 konform ist auch nicht wirklich JSON ist.

[defo]

Per Definition/Standard ist JSON immer Unicode. Und persönlich würde ich sogar sagen das alles was nicht utf-8 konform ist auch nicht wirklich JSON ist.

Ja, ich habe etwas rumfantasiert. Der Punkt ist am Ende, dass ggF. die Annahme der Post CH irgendwie krank implementiert ist, zu Fuß unter Wahrung des Formats. Aber es kann natürlich genau so umgekehrt sein, bei der Erstellung bzw. Encoding der "Quelltexte".

[Arne Drews]

Hallo,

Entschuldigt, dass ich mich erst jetzt zurück melde, ich habe erstmal zwei andere Prijekte abgeschlossen und widme mich nun diesem Problem erst wieder.

Vielen Dank für euren Austausch, ich gehe auch davon aus, dass es eher an der Übertragung liegt.
System seitig, also lokal halte ich alles auf UTF-8. Grundsätzlich ist auch JSON per Definition Unicode, das ist soweit korrekt.

Hier mal das grundsätzliche Script:
[highlight=csharp]
System.Net.HttpWebRequest xhr = (System.Net.HttpWebRequest)System.Net.WebRequest.C reate( oObj.getWebServiceEndpoint() );
xhr.Headers.Add( "Authorization", "Basic " + oObj.getAuthCredentials() );
xhr.ContentType = "application/json; charset=UTF-8";
xhr.TransferEncoding = "UTF-8"; // <-- ohne das gibt es einen 401er, mit einen 500er
xhr.SendChunked = true; // <-- erforderlich bei Verwendung von HttpWebRequest.TransferEncoding
xhr.Method = "POST";

using ( StreamWriter sw = new StreamWriter(xhr.GetRequestStream()) ) {

string sJson = oObj.getJSONData();
File.AppendAllText( @"C:\...\postch.httprequest.log", sJson );

sw.Write( oObj.getJSONData() );
sw.Flush();

}

System.Net.HttpWebResponse rsp = (System.Net.HttpWebResponse)xhr.GetResponse();

using ( StreamReader sr = new StreamReader(rsp.GetResponseStream()) ) {

string rspText = sr.ReadToEnd();
MessageBox.Show( rspText );

File.AppendAllText( @"C:\...\postch.httprequest.log", rspText );

}
[/highlight]
Wenn ich die Daten, die hier für den Request vorbereitet werden 1:1 in einem Testing Tool verwende, geht der Request einwandfrei durch.
Die 401 und 500 Meldungen sagen in diesem Fall nicht das aus, wofür sie stehen.
401 wird responsed, wenn das Encoding nicht stimmt und 500 haben wir noch nicht herausgefunden.

Mache ich grundsätzlich beim Request evtl. irgendwas verkehrt?

Danke für eure Tipps!
Gruß Arne

[Ralf Jansen]

[highlight=csharp]
xhr.TransferEncoding = "UTF-8"; // <-- ohne das gibt es einen 401er, mit einen 500er
[/highlight]

TransferEncoding bezieht sich auf was anderes als Zeichensatz Encoding. Da geht es mehr um die zu nutzende Komprimierung bei der Übertragung.

401 wird responsed, wenn das Encoding nicht stimmt

401 heißt es ist ein unautorisierter Call. Euer Authorisierungsheader ist also voraussichtlich nicht korrekt.

und 500 haben wir noch nicht herausgefunden.

500 ist ein interner Server Fehler. Wenn ihr aber irgendeinen beliebigen string (hier ist utf-8 ein beliebiger falscher string) als Transfer Encoding in den Header packt reagiert der Server möglicherweise so.

Wenn die Doku zur Schnittstelle nicht eine spezielles Encoding vorschreibt (chunked, gzip oder sowas) dann lasst das weg.