Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Wieso werden Umlaute nach dem (De)Serialisieren von CSV-Dateien nicht richtig dargestellt (UTF-7)?
Duesmannr
myCSharp.de - Member



Dabei seit:
Beiträge: 127
Herkunft: Münster

Themenstarter:

Wieso werden Umlaute nach dem (De)Serialisieren von CSV-Dateien nicht richtig dargestellt (UTF-7)?

beantworten | zitieren | melden

Moin,

ich habe ein Problem mit der De-/serialisierung von deutschen Umlauten.


List<Country> countries1 = new List<Country>
{
    new Country
    {
        Name = "Ägypten"
    }
};

string json = JsonSerializer.Serialize(countries1);

List<Country> deserializedCountry = JsonSerializer.Deserialize<List<Country>>(json);

Funktioniert wunderbar. Ägypten steht wieder ganz normal drin.

Im Json selbst, steht dann der String:

[{"Id":"53b1b01c-2a33-48ee-9f21-c0a20f6f96bc","Name":"\u00C4gypten","ISOAlpha2":null,"ISOAlpha3":null,"States":null,"Sources":null}]

Weil der den Umlaut encoded. Das passt ja alles.

Wenn ich das ganze dann aber erweiter:


using StreamReader sr = new StreamReader("Countries.csv", Encoding.UTF8);
string line;
int skipLine = 2;
List<Country> countries = new List<Country>();

while ((line = sr.ReadLine()) != null)
{
    if (skipLine > 0)
    {
        skipLine--;
        continue;
    }

    string[] values = line.Split(";");

    countries.Add(new Country
    {
        Name = values[0],
        ISOAlpha2 = values[1],
        ISOAlpha3 = values[2]
     });
}

json = JsonSerializer.Serialize(countries);

deserializedCountry = JsonSerializer.Deserialize<List<Country>>(json);

Sind alle Länder der Welt round about 270 stk.
Hier im Json steht der String drin (Ausschnitt)
{"Id":"5e150fc7-a81e-41c1-a87f-d9fcc80be1de","Name":"\uFFFDgypten","ISOAlpha2":"EG","ISOAlpha3":"EGY","States":null,"Sources":null},

Hier encoded der das "Ä" anders.
Und wenn ich es dann wieder deserialisiere kommt das raus:
"?gypten".

Aber wie kann ich das umgehen? Bzw. was genau ist das Problem?

Google hat auch nicht geholfen, weder zu Json.NET (was hier verwendet wird) noch zu Newtonsoft.

Ziel ist im Endeffekt, mir eine Json Datei zu erstellen, die von einem anderen Programm eingelesen wird.

Edit:
Die csv Datei ist exportiert von xlsx via Excel.
Aber nachdem ich es gepostet habe, habe ich bemerkt, dass es am Encoding vom StreamReader liegt.
Aber müsste UTF-8 nicht korrekt sein?

Dann ist es gleich zu diesen Thema
Wo UTF-7 die Lösung ist.
Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von Duesmannr am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15703
Herkunft: BW

beantworten | zitieren | melden

Wie Du selbst mit dem Edit bemerkt hast, liegt es am Encoding.

Das Encoding bestimmst Du (oder eben die Anwendung) beim Schreiben.
Beim Lesen muss das selbe Encoding verwendet werden - immer.

Das ist ein typisches Problem beim Datenaustausch zwischen Anwendungen über Dateien.

Soweit ich weiß ist UTF-7 das default encoding für CSV Dateien via Excel.
Native Dateien wie xlsx etc sind UTF-8.

Bei CSV wird vermutlich aufgrund der nur spärlichen Möglichkeiten Sonderzeichen zu behandeln eben auf ein ASCII-nahes Encoding gesetzt; meine Vermutung.
private Nachricht | Beiträge des Benutzers
Platoon
myCSharp.de - Member



Dabei seit:
Beiträge: 46
Herkunft: NRW

beantworten | zitieren | melden

Zitat von Abt
Soweit ich weiß ist UTF-7 das default encoding für CSV Dateien via Excel.
Native Dateien wie xlsx etc sind UTF-8.

Excel generell zu erwähnen ist etwas irreführend finde ich.
Zitat von Abt
Bei CSV wird vermutlich aufgrund der nur spärlichen Möglichkeiten Sonderzeichen zu behandeln eben auf ein ASCII-nahes Encoding gesetzt; meine Vermutung.


CSV nutzt primär UTF-7 wobei das auch nicht in einer RFC festgeschrieben ist. Wobei das Format CSV auch oftmals nicht korrekt nach RFC 4180 angewendet wird. Da kommen dann Piper (|), Simikola (;), Doppelpunkte etc. zum Einsatz wobei per Definition es ja eigentlich ein Komma sein sollte.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Platoon am .
.....an unhandled exception is the first way to think about your pattern of programming....
.....nur weil ich nicht weiß was dort passiert, bedeutet es nicht, dass ich nicht weiß, wie man es lösen kann - aber das ist wahrscheinlich....
private Nachricht | Beiträge des Benutzers