Benutzer mit den meisten Antworten
DataTable von ANSI konvertieren

Frage
-
Mein Problem genau,
Ich habe einen String der in ANSI Kodiert ist, wenn ich die in Mein Programm einlese kommt nur Müll heraus, ich möchte ihn "umkodieren", (ich habe schon ein Beispiel zu diesem Thema vom Internet gemacht gemacht )
Die Encoding class, which return objects that represent the standard character encodings available in the .NET Framework (ASCII, UTF-7, UTF-8, UTF-16, and UTF-32)." id="mt22">Standardzeichencodierungen in Dotnet sind ASCII, UTF-7, UTF-8, UTF-16 und UTF-32.Quelle
Nun Möchte ich den String von ANSI in eine der dortigen Kodierungen Umcodieren. Dazu verwende ich folgende MEthode:
string ConvertAnsiToUTF32(string convert) { // Create two different encodings. Encoding ANSI = Encoding.GetEncoding(1252); Encoding UTF = Encoding.UTF32; byte[] ansiBytes = ANSI.GetBytes(convert); byte [] UTFBytes = Encoding.Convert(ANSI, UTF, ansiBytes); char [] UTFChars = new char[UTF.GetCharCount(UTFBytes, 0, UTFBytes.Length)]; UTF.GetChars(UTFBytes, 0, UTFBytes.Length, UTFChars, 0); string result = new string(UTFChars); return result; }
Hat jemand ein Beispiel mit Ansi oder eine andere Klasse Als ENCODING
Bitte klärt mich über falsche Fachbegriffe auf Beste Grüße Florian Reiter
- Bearbeitet Florian.Reiter Donnerstag, 26. Juli 2012 11:15
Antworten
-
Hallo Florian,
grundsätzlich gilt: In .NET sind alle Zeichenketten (wie der String-Datentyp) in Unicode.
Mehr siehe Zeichencodierung in .NET Framework
Konvertieren muss man nur, wenn die Daten extern überträgt,
also z. B. in einer Datei ablegen will oder aus einer Datei mit anderer Kodierung lesen muss.Dann verwendet man die Byte-Folge, die Encoding.GetBytes liefert -
dies darf man dann aber nicht mehr als einen String verwenden.
Beim umgekehrten Weg, wenn man Daten in einem anderen Zeichensatz erhält,
liest man die Daten als Byte-Array ein und konvertiert mit dem entsprechenden Encoding
in einen String (womit es wieder Unicode ist).Klassen wie StringReader und StringWriter tun das bereits automatisch,
Und wenn man dort Encoding.Default verwendet, so ist das ANSI (entsprechend der lokalen Einstellung).Falls das nicht ausreicht um Dein Problem zu lösen:
Wo kommen die Daten für Deine Zeichenkette her?Gruß Elmar
- Bearbeitet Elmar BoyeEditor Donnerstag, 26. Juli 2012 10:39
- Als Antwort markiert Robert BreitenhoferModerator Montag, 27. August 2012 13:17
-
Hallo Florian,
entweder passt das ganze von vorne herein oder Du hast relativ schlechte Karten.
Denn die Konvertierung findet in solchen Fällen bereits durch den Treiber statt,
der die Daten als Unicodezeichenfolge bereitstellt (oder es zumindest versucht).Grundsätzlich erkennt Visual Foxpro die Zeichensätze anhand es Dateiheaders,
siehe Understanding Code Pages in Visual FoxProPasst der Inhalt jedoch nicht, so kommt Zeichensalat heraus - etwas was
bei Dbase Dateien häufiger passiert, vor allem wenn sie mit Hilfsprogrämmchen erzeugt wurden.
Ältere Formate verwenden oft noch OEM Zeichensätze (437/850), oft zu erkennen an unkenntlichen Umlauten.Zudem sollte es auch möglich sein, eine alternative Codepage beim Treiber anzugeben,
leider scheint es zum Treiber keine (vernünftige) Dokumentation zu geben.Was man noch machen könnte wäre die Datei binär einzulesen, das Dbase Dateiformat
ist abseits der Indexdateien, die man dafür nicht braucht, relativ schlicht gestrickt.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Montag, 27. August 2012 13:17
Alle Antworten
-
Hallo Florian,
grundsätzlich gilt: In .NET sind alle Zeichenketten (wie der String-Datentyp) in Unicode.
Mehr siehe Zeichencodierung in .NET Framework
Konvertieren muss man nur, wenn die Daten extern überträgt,
also z. B. in einer Datei ablegen will oder aus einer Datei mit anderer Kodierung lesen muss.Dann verwendet man die Byte-Folge, die Encoding.GetBytes liefert -
dies darf man dann aber nicht mehr als einen String verwenden.
Beim umgekehrten Weg, wenn man Daten in einem anderen Zeichensatz erhält,
liest man die Daten als Byte-Array ein und konvertiert mit dem entsprechenden Encoding
in einen String (womit es wieder Unicode ist).Klassen wie StringReader und StringWriter tun das bereits automatisch,
Und wenn man dort Encoding.Default verwendet, so ist das ANSI (entsprechend der lokalen Einstellung).Falls das nicht ausreicht um Dein Problem zu lösen:
Wo kommen die Daten für Deine Zeichenkette her?Gruß Elmar
- Bearbeitet Elmar BoyeEditor Donnerstag, 26. Juli 2012 10:39
- Als Antwort markiert Robert BreitenhoferModerator Montag, 27. August 2012 13:17
-
Die Methode zum Importieren der Tabele
/// <summary> /// DBF to DataTable /// </summary> /// <param name="Filename">Pfad der Datatable</param> /// <returns>Datatabele</returns> public static DataTable DbfToTableOleDb(string Filename) { string fn = Path.GetFileName(Filename); string path = Filename.Substring(0, Filename.Length - fn.Length); string ext = Path.GetExtension(Filename); string dbfName = fn.Substring(0, fn.Length - ext.Length); OleDbConnection conn = new OleDbConnection(); //conn.ConnectionString = @"Provider=vfpoledb;Data Source=" + path + ";Extended Properties=dBase IV"; conn.ConnectionString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + path + ";Extended Properties=dBase IV"; conn.Open(); OleDbCommand cmd = new OleDbCommand("SELECT * FROM [" + dbfName + "]", conn); DataTable dt = new DataTable(); dt.Load(cmd.ExecuteReader()); conn.Close(); return dt; }
So Rufe die Convertiermethode aufthis.tblTable1 = DbfToTableOleDb(txtText1.Text);
lblStatus.Text += ConvertAnsiToUTF32(Convert.ToString(this.tblTable1.Rows[4][3]));
Bezüglich dem Encoding Default Wenn ich Encoding.Default Schreibe funktionierts auch nict.
Encoding ANSI = Encoding.Default; //.GetEncoding(1252);
Bitte klärt mich über falsche Fachbegriffe auf Beste Grüße Florian Reiter
- Bearbeitet Florian.Reiter Donnerstag, 26. Juli 2012 11:13
-
Hallo Florian,
probiere es doch mal mit der statischen Methode GetString(byte[] bytearray), die die Encoding-Klasse anbietet. Also in deinem Fall den ANSI-String in ein ByteArray unwandeln (machst du ja schon, wenn ich das richtig gelesen habe) und dann mit der GetString-Methode in dein gewünschtes Format konvertieren. Beispielhaft könnte das so aussehen:
byte[] ansiBytes = ANSI.GetBytes(convert); string utf32String = System.Text.Encoding.UTF32.GetString(ansiBytes);
Gruß,
Steve.
-
Hallo Florian,
entweder passt das ganze von vorne herein oder Du hast relativ schlechte Karten.
Denn die Konvertierung findet in solchen Fällen bereits durch den Treiber statt,
der die Daten als Unicodezeichenfolge bereitstellt (oder es zumindest versucht).Grundsätzlich erkennt Visual Foxpro die Zeichensätze anhand es Dateiheaders,
siehe Understanding Code Pages in Visual FoxProPasst der Inhalt jedoch nicht, so kommt Zeichensalat heraus - etwas was
bei Dbase Dateien häufiger passiert, vor allem wenn sie mit Hilfsprogrämmchen erzeugt wurden.
Ältere Formate verwenden oft noch OEM Zeichensätze (437/850), oft zu erkennen an unkenntlichen Umlauten.Zudem sollte es auch möglich sein, eine alternative Codepage beim Treiber anzugeben,
leider scheint es zum Treiber keine (vernünftige) Dokumentation zu geben.Was man noch machen könnte wäre die Datei binär einzulesen, das Dbase Dateiformat
ist abseits der Indexdateien, die man dafür nicht braucht, relativ schlicht gestrickt.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Montag, 27. August 2012 13:17
-
Hallo Florian.Reiter,
Ich gehe davon aus, dass die Antworten Dir weitergeholfen haben.
Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.Grüße,
RobertRobert Breitenhofer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Was soll ein utf-32 String sein? Da müsste der string ja ein DWORD-Array sein. Ein string im Memory ist normalerweise ein word-Array um eben in utf-16 codieren zu können. Unicode Codepoints jenseits der BMP werden dann als surrogate-pair encodiert. Entscheidend ist beim re-encodieren von ANSI nach utf-16, welche Codepage für Zeichen > 127 angewandt werden soll, dementsprechend entstehen bei unterschiedlichen Codepages auch unterschiedliche Codepoints. Man muss also die Codepage des ANSI Files schon wissen, sonst sind dann nur die ASCII Zeichen richtig.
Peter