Benutzer mit den meisten Antworten
Base64String

Frage
-
Hallo zusammen.
Mit folgender Methode kann ich einen String in einen Base64String umwandeln:
static public string EncodeTo64(string toEncode) { byte[] toEncodeAsBytes = System.Text.Encoding.ASCII.GetBytes(toEncode); string returnValue = System.Convert.ToBase64String(toEncodeAsBytes); return returnValue; }
Ich frage ich nun, ob das Resultat hier immer eindeutig ist, wenn die Eingabe eindeutig ist. Vor allem würde mich interessieren, ob die Eindeutigkeit auch gewährleistet ist, bei Case-Sensitivität? Konkret: Egal was ich reingebe (auch nur unterschieden durch Gross-/Kleinschreibung) ist die Ausgabe immer eindeutig oder nicht?
Danke für eure Hilfe.
Viele Grüsse, Thomas
Antworten
-
Hallo Thomas,
> Aber mit dem "Hex-Ansatz" kann ich das nun lösen.
Dein Hex-Ansatz ist praktikabel, man könnte das Ganze aber (wenn man keinen Einfluß auf die Collation des DB-Feldes hat) auch einfacher lösen, z.B.:
int hashCode = "Dein Input-String".GetHashCode();
> Vielen Dank.
Gern.Gruß
Marcel- Als Antwort vorgeschlagen Marcel RomaModerator Dienstag, 5. April 2011 13:09
- Als Antwort markiert Kehl Thomas Dienstag, 5. April 2011 14:14
-
Hoi Thomas,
> Ist denn der Hashcode sicher eindeutig?
Wenn Du mit sicher "zertifiziert" meinst, dann ist die Antwort "nein", es ist eine pure .NET-Implementation.
Was Deine Eingangsfrage angeht ("ob das Resultat hier immer eindeutig ist, wenn die Eingabe eindeutig ist"), so lautet die Antwort "ja". Zwei identische Strings sollten laut Dokumentation immer den gleichen Hashcode haben (was natürlich nicht den Umkehrschluss erlaubt, dass gleiche Hashcodes den gleichen Ausgangsstring haben). Der einzige Punkt auf den man achten muss, ist dass man dabei nicht GetHashCode() für .NET 1.0 /1.1 mit der gleichnamigen Version ab .NET 2.0 vergleichen kann, da sie divergierende Implementationen haben.Viele Grüsse
Marcel- Als Antwort markiert Kehl Thomas Dienstag, 5. April 2011 14:14
Alle Antworten
-
Hallo Thomas,
Ich frage ich nun, ob das Resultat hier immer eindeutig ist, wenn die Eingabe eindeutig ist. Vor allem würde mich interessieren, ob die Eindeutigkeit auch gewährleistet ist, bei Case-Sensitivität? Konkret: Egal was ich reingebe (auch nur unterschieden durch Gross-/Kleinschreibung) ist die Ausgabe immer eindeutig oder nicht?
so ganz versteh ich die Frage nicht. Wenn Du einen String Base64 codierst, erhältst Du beim decodieren deinen Originalstring. Da eine andere Eingabezeichenfolge auch einen anderen Base64 String ergibt, wäre das wohl auch eindeutig.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community -
Hallo Thomas,
Wenn Du System.Text.Encoding.ASCII verwendest, wirst Du u.U. deinen Originalstring nicht wieder dekodieren können (Codepage-Probleme + string ist UTF-16 kodiert). Zusätzlich: Dieselbe Zeichenfolge wird je nach Position in der Gesamtzeichenfolge und verwendetem Padding anders kodiert.
Base64 kann nicht als Ersatz für Hashing betrachtet werden.
http://en.wikipedia.org/wiki/Base64#Padding
Gruß
Marcel -
Hallo Marcel
Ich wandle den String nun folgendermassen "nach Hex":
public static string ToHex(this string asciiString) { return asciiString.Aggregate("", (current, c) => current + String.Format("{0:x2}", Convert.ToUInt32(c))); }
Das ursprüngliche Problem ist folgendermassen:
Ich habe einen String der eine UniqueId darstellt. Diesen speichere ich auf eine Datenbank. Nun ist es aber so, dass diese UniqueId Case-Sensitive ist. Meine Datenbank ist hingegen Case-Insensitiv. Nun möchte ich verhindern, dass ich eine Liste solcher Id's lesen muss (können mit der Zeit sehr viele sein) und diese dann auf dem Client nochmals durchgehen und vergleichen muss.
Aber mit dem "Hex-Ansatz" kann ich das nun lösen.
Vielen Dank.
Grüsse, Thomas
-
Hallo Thomas,
> Aber mit dem "Hex-Ansatz" kann ich das nun lösen.
Dein Hex-Ansatz ist praktikabel, man könnte das Ganze aber (wenn man keinen Einfluß auf die Collation des DB-Feldes hat) auch einfacher lösen, z.B.:
int hashCode = "Dein Input-String".GetHashCode();
> Vielen Dank.
Gern.Gruß
Marcel- Als Antwort vorgeschlagen Marcel RomaModerator Dienstag, 5. April 2011 13:09
- Als Antwort markiert Kehl Thomas Dienstag, 5. April 2011 14:14
-
Hoi Marcel
Das mit dem Hashcode würde mir besser gefallen - aber:
Ist denn der Hashcode sicher eindeutig? - Oder gehe ich da irgendwelche Kompromisse ein?
Der Hashcode ist eine int - da wird es irgendwo auch grenzen geben, oder?
Meine Strings, die ich "verhashen" würde, sind bis zu 500 Zeichen lang.Viele Grüsse, Thomas
-
Hoi Thomas,
> Ist denn der Hashcode sicher eindeutig?
Wenn Du mit sicher "zertifiziert" meinst, dann ist die Antwort "nein", es ist eine pure .NET-Implementation.
Was Deine Eingangsfrage angeht ("ob das Resultat hier immer eindeutig ist, wenn die Eingabe eindeutig ist"), so lautet die Antwort "ja". Zwei identische Strings sollten laut Dokumentation immer den gleichen Hashcode haben (was natürlich nicht den Umkehrschluss erlaubt, dass gleiche Hashcodes den gleichen Ausgangsstring haben). Der einzige Punkt auf den man achten muss, ist dass man dabei nicht GetHashCode() für .NET 1.0 /1.1 mit der gleichnamigen Version ab .NET 2.0 vergleichen kann, da sie divergierende Implementationen haben.Viele Grüsse
Marcel- Als Antwort markiert Kehl Thomas Dienstag, 5. April 2011 14:14
-
Hoi Marcel
Ich habe nun doch meine Lösung mit dem ToHex() verwendet, da ich sonst unter Umständen meine Daten nicht mehr finde, wenn ich den HashCode verwende, da dieser Plattformabhängig sowie vom .NET-Framework abhängig ist. D.h. wenn die Plattform von 32bit zu 64bit wechselt oder das .NET-Framework irgendwann aktualisiert wird, kann es sein, dass ich meine Items nicht mehr finde.
Grüsse, thomas
-
Hoi Thomas,
String.GetHashCode() ist plattform- und frameworkabhängig. Das ist der Fall auch bei anderen Klassen wie Random. Sobald man die Grenzen der Frameworkversion überschreitet, muss man bei vielen Funktionen, die nicht Microsoft-extern zertifiziert sind, damit rechnen, dass Eindeutigkeit bzw. Pseudo-Zufälligkeit nicht mehr garantiert werden. Wenn Du also Deine Anwendung sowohl für 32bit als auch für 64bit Systeme erstellen und zudem frameworkunabhängig bleiben möchtest, so ist Deine ToHex()-Lösung passender.
Wirf bitte einen Blick auch auf folgenden Link:BitConverter.ToString Methode (Byte[]):
http://msdn.microsoft.com/de-de/library/3a733s97.aspxViele Grüße
Marcel