Schlagwort: C#

(De-)Kompression mit C# 👍 👎

Zwar ist Speicher heutzutage üblicherweise keine Mangelware mehr, dennoch kann sich die Komprimierung großer Datenmengen, beispielsweise zur Übertragung, lohnen. C# bietet dazu einige Möglichkeiten, so unter anderem zur Arbeit mit ZIP-Archiven. Zu diesen möchte ich jedoch in einem separaten Beitrag kommen und stattdessen zeigen, wie sich mit der DeflateStream-Klasse beliebige Daten(-ströme) (de-)komprimieren lassen:
(De-)Komprimierung von Rohdaten
01020304050607080910111213141516171819202122232425
  // Daten komprimierenpublic static byte[] Compress(byte[] data) {    using(MemoryStream inStream = new MemoryStream(data)) {        using(MemoryStream outStream = new MemoryStream()) {            using(DeflateStream deflate = new DeflateStream(outStream, CompressionMode.Compress)) {                inStream.CopyTo(deflate);            }
return outStream.ToArray(); } }}
// Daten dekomprimierenpublic static byte[] Decompress(byte[] data) { using(MemoryStream inStream = new MemoryStream(data)) { using(MemoryStream outStream = new MemoryStream()) { using(DeflateStream deflate = new DeflateStream(inStream, CompressionMode.Decompress)) { deflate.CopyTo(outStream); }
return outStream.ToArray(); } }}
Um beispielsweise komplette Dateien effizient zu (de-)komprimieren, kann wie folgt vorgegangen werden:
(De-)Komprimierung von Dateien
010203040506070809101112131415161718192021
  // Datei komprimierenpublic static void CompressFile(string inputPath, string outputPath) {    using(FileStream inStream = File.OpenRead(inputPath)) {        using(FileStream outStream = File.OpenWrite(outputPath)) {            using(DeflateStream deflate = new DeflateStream(outStream, CompressionMode.Compress)) {                inStream.CopyTo(deflate);            }        }    }}
// Datei dekomprimierenpublic static void DecompressFile(string inputPath, string outputPath) { using(FileStream inStream = File.OpenRead(inputPath)) { using(FileStream outStream = File.OpenWrite(outputPath)) { using(DeflateStream deflate = new DeflateStream(inStream, CompressionMode.Decompress)) { deflate.CopyTo(outStream); } } }}
Sofern zusätzlich verschlüsselt werden soll, worauf ich in einem separaten Beitrag näher eingehen möchte, ist eine sinnvolle Reihenfolge zu beachten. Diese trägt zwar, abgesehen von kleineren Umständen bei unberechtigten Entschlüsselungsversuchen, nicht wesentlich zur Sicherheit an sich bei – wohl aber zur erzielbaren Kompression.

Die (verlustfreie) Datenkompression basiert hauptsächlich auf Redundanzreduktion. Es werden also Muster der Eingabe erkannt und kompakter kodiert. Derartige Muster sollten nach einer ordnungsgemäßen Verschlüsselung jedoch nicht auftreten, d. h. die Ausgabe wirkt ohne Schlüssel weitestgehend zufällig. Verschlüsselte Daten lassen sich entsprechend schlecht komprimieren und so lässt sich sogar recht einfach prüfen, ob eine Verschlüsselung grobe Fehler aufweist – nämlich genau dann, wenn eine signifikante Kompression des Chiffrats möglich ist.

Konkret bedeutet dies also für die Praxis üblicherweise, zuerst zu komprimieren und danach zu verschlüsseln.

Schaltjahr ermitteln 👍 👎

Viele Beispiele ermitteln ein Schaltjahr über eine Prüfung darauf, ob das fragliche Jahr durch vier teilbar ist. Diese einfache Prüfung, die bereits im julianischen Kalender Anwendung findet, ist jedoch nur eine von drei Regeln des gregorianischen Kalenders. Für eine vollständige Prüfung müssen folgende drei Bedingungen überprüft werden:
  • Ist das Jahr durch 4 teilbar, ist es potentiell ein Schaltjahr. (2016 ist ein Schaltjahr)
  • Ist das Jahr durch 100 teilbar, ist es grundsätzlich kein Schaltjahr. (2100 ist kein Schaltjahr)
  • Ist das Jahr durch 400 teilbar, ist es generell ein Schaltjahr. (2000 ist ein Schaltjahr)
Dies lässt sich in C# nun beispielsweise wie folgt als statische Methode umsetzen:
Schaltjahr-Prüfung implementieren und verwenden
01020304050607
public static bool IsLeapYear(int year) {    return (((year % 2 == 0) && (year % 100 != 0)) || (year % 400 == 0));}
bool isLeapYear = IsLeapYear(2016); // trueisLeapYear = IsLeapYear(2100); // falseisLeapYear = IsLeapYear(2000); // true
Besonders spannend ist diese Methode jedoch nicht, das .NET-Framework bietet mit DateTime.IsLeapYear(…) nämlich bereits eine entsprechende Implementierung an. Es gilt jedoch den Hinweis der Dokumentation zu beachten, dass die Prüfung dabei immer im Rahmen des gregorianischen Kalenders erfolgt, was für manche – beispielsweise historische – Anwendungen unpässlich sein kann. Das Framework bietet im Namensraum System.Globalization jedoch weitere Kalender-Implementierungen an, welche jeweils eine entsprechende Umsetzung der IsLeapYear(…)-Methode zur Verfügung stellen.

.NET-Guidelines für Programmbibliotheken 👍 👎

Da es in Projekten im Allgemeinen des Öfteren zur Frage kommt, wie Member benannt und strukturiert werden sollen und ich erst vor Kurzem im Büro darauf hingewiesen habe, möchte ich auch an dieser Stelle einmal auf die Framework Design Guidelines von Microsoft hinweisen, welche einen Leitfaden zur Implementierung darstellen.

Wichtig zu verstehen ist dabei, dass sich diese Richtlinien nur auf die öffentliche Schnittstelle (also insbesondere Member mit public- oder protected-Modifizierer) beziehen und grundsätzlich keine Aussagen zu internen (private-Modifizierer) Membern treffen. Es bietet sich jedoch durchaus an, auch hier konform zu gehen. Die Einleitung weist auch explizit darauf hin, dass ein – gut begründetes – Abweichen von diesem Regelwerk legitim ist.

Im MSDN findet sich im Übrigen auch eine Übersicht der Warnungen bei der Analyse von verwaltetem Code.

UNIX-Zeitstempel und C# 👍 👎

In einem älteren Beitrag zum Thema Erweiterungsmethoden in C# hatte ich eine kleine Methode zur Arbeit mit UNIX-Zeitstempeln als Beispiel verwendet. Dieser Beitrag wird auch heute noch relativ häufig aufgerufen, weswegen ich zu diesem konkreten Beispiel anmerken möchte, dass das .NET-Framework seit Version 4.6 Funktionalität zur Arbeit mit entsprechenden Zeitstempeln auf der DateTimeOffset-Struktur bereithält:
Die Verwendung gestaltet sich wie üblich sehr einfach:
Konvertierung von UNIX-Zeitstempeln
010203040506070809
  // UNIX-Zeitstempel für aktuelles Datum und aktuelle Uhrzeit ermittelnlong unixTimestamp = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
// bestimmtes Datum um 0:00 Uhr verwendenunixTimestamp = (new DateTimeOffset(new DateTime(1988, 1, 29))).ToUnixTimeSeconds();

// DateTime-Objekt lokaler Zeit aus UNIX-Zeitstempel erzeugenDateTime dateTime = DateTimeOffset.FromUnixTimeSeconds(unixTimestamp).LocalDateTime;
Eigene Implementierungen sollten für die aktuelle Praxis daher nicht mehr nötig sein.

Aufzählungswert per Zeichenkette ermitteln 👍 👎

Vor sehr langer Zeit habe ich bereits einen Artikel zu Enumerationen in C# geschrieben, an welchen ich indirekt anknüpfen möchte. Oftmals steht man im Bereich der Softwareentwicklung vor dem Problem der Interoperabilität, da mehrere – bisweilen äußerst unterschiedliche – Systeme zusammenarbeiten müssen.

Ein klassischer Fall im Bereich der Webentwicklung ist die Zusammenarbeit aus Anwendung und Datenbank, beispielsweise hier im Blog zwischen der Programmiersprache C# mit ASP.NET MVC-Framework und MySQL-Datenbank. Etwas konkreter soll es darum gehen, C#-Aufzählungstypen zusammen mit MySQL-ENUMs zu verwenden, welche grundsätzlich erst einmal als bloße Zeichenketten zu behandeln sind. Für das folgende Beispiel nehmen wir an, dass eine Tabelle user existiert, die eine Spalte state vom Typ ENUM('ACTIVE','INACTIVE','LOCKED') enthält.

Unter Verwendung des ADO.NET Entity Framework würde beim Database First-Ansatz eine entsprechende Klasse user mit der Eigenschaft state vom Typ string erzeugt. Da es sich um eine partielle Klasse handelt, erweitern wir diese um eine neue Eigenschaft State. Diese soll anschließend die automatische Konvertierung für state übernehmen und ermöglicht uns im Programmcode einen typsicheren Zugriff auf den Status des Benutzers:
Aufzählungstyp UserState anlegen
0102030405
public enum UserState {    Active,    Inactive,    Locked}
Erweiterung der Klasse user
010203040506070809
public partial class user {    public UserState State {        get {            return (UserState) Enum.Parse(typeof(UserState), this.state, true);        }        set {            this.state = value.ToString().ToUpper();        }    }
Die Verwendung gestaltet sich nun – mit beiden Eigenschaften – wie gewohnt komfortabel:
Verwendung
0102030405060708091011121314151617
user dbUser = new user() {    State = UserState.Active};  // üblicherweise aus Datenbank ermittelt

string state = dbUser.state; // "ACTIVE"UserState userState = dbUser.State; // Active
dbUser.State = UserState.Inactive;

state = dbUser.state; // "INACTIVE"userState = dbUser.State; // Inactive
dbUser.state = "LOCKED";

state = dbUser.state; // "LOCKED"userState = dbUser.State; // Locked
Weitere Informationen zu den Enum.Parse-Methoden finden sich wie üblich im MSDN. Es lohnt sich außerdem ein Blick auf die Enum.TryParse(…)-Methoden mit generischem Typ-Parameter.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche