Du könntest die beiden verketten und hashen, aber nimm SHA, weil MD5 z.B. ist nicht kollisionssicher. Dann hast du eine Bytefolge aus der du deinen BarCode machen kannst.

Warennr. = T13-A *
U-Warennr= 7Y OÜG

Ergebnis = ?????

Wie sollen die Buchstaben in Zahlen gewandelt werden?

@Eierlein Nicht im interpretierten Format denken. Alles Bytes, also zahlen.

Wenn du aber doch mit Datenbank arbeitest, sollte deine Waren-Nummer doch mit der Unterwaren-Nummer in Relation stehen
und du hättest die eindeutige ID direkt zur Hand....

BitBrösel schrieb:

aber nimm SHA, weil MD5 z.B. ist nicht kollisionssicher

So wie du diesen Satz formuliert hast ließt es sich, als ob SHA im Gegensatz zu MD5 kollisionssicher ist. Ist es aber nicht. Nur um das nochmal klar zu stellen.

Wie kollisionssicher ist denn SHA, im Gegensatz zu MD5?
Und wenn man einfach String.GetHashCode() verwendet - welcher der beiden Algorithmen steckt da hinter - oder ists gar noch ein dritter?

@Zenker Ein Barcode ist nix anderes als ein Text mit einem Barcode-Font.
Du kannst also in einem Word-Dokument einen Text schreiben, diesen markieren und formatieren: "Arial", "Courier New", "Barcode123".
Überdenke das und formuliere Dein Problem noch einmal neu.

======
Wenn Dein Problem darin besteht, dass der Barcode-Zeichensatz nicht alle Zeichen abdeckt, wäre die Konvertierung Deines Textes zu einem Base64String eine mögliche Lösung.
Und:
Genügt es, dass die Verknüpfung eindeutig ist odere sollte sie nicht eineindeutig sein? Auch in diesem Falle wäre der Base64String Dein Kandidat.

ErfinderDesRades schrieb:

Wie kollisionssicher ist denn SHA

Ein Hash, der kürzer als der Eingabestring ist, ist theoretisch nie vollständig kollisionsresistent, auch nicht SHA, nur ist die Chance auf eine Kollision ziemlich gering.
Unter anderem deshalb ist ein Hash ja auch keine umkehrbare Verschlüsselung.
de.wikipedia.org/wiki/Kollisionsresistenz

tja, was KollisionsResistenz ist habich so ungefähr ja schon gewusst.
Meine Frage waraber: : Wie kollisionssicher sind Sha, Md5, String.GetHashCode() im Vergleich?
Da muss es doch eine Masseinheit für geben, wenn gesagt werden kann: "Dieses ist sicher, jenes nicht."

Und am Ende geht es um infinitisimal kleine GrößenOrdnungen, also die Wahrscheinlichkeit einer MD5-Kollision mag sein: 1:10^-100, und bei Sha isses 1:10^1000 - aber wen interessiert das denn dann noch?
Beides wird, solange die Menschheit noch existiert, niemals auftreten.

ErfinderDesRades schrieb:

Meine Frage waraber: : Wie kollisionssicher sind Sha, Md5, String.GetHashCode() im Vergleich?

Ich glaube das ist schwer zu sagen. SHA ist ja nur eine Gruppe und wenn du da entsprechend neuere nimmst, wird das schon passen. MD5 würde ich nicht nehmen. String.GetHashCode braucht man gar nicht erst betrachten, das ist ein int der hat ja nur 4 Bytes, da wirst du sicher Kollisionen bekommen. Außerdem darfst/solltest du diesen gar nicht abspeichere, da dieser nicht persistent ist und sich ändern kann:

​The GetHashCode method for an object must consistently return the same hash code as long as there is no modification to the object state that determines the return value of the object's Equals method. Note that this is true only for the current execution of an application, and that a different hash code can be returned if the application is run again.

Object.GetHashCode Method
Why is string.GetHashCode() different each time I run my program in .NET Core?

Hier mal die Tabelle mit den Größen aus Wikipedia:

SHA-3 mit mindestens 28 Byte wird vermutlich ziemlich sicher sein.

ErfinderDesRades schrieb:

Und am Ende geht es um infinitisimal kleine GrößenOrdnungen, also die Wahrscheinlichkeit einer MD5-Kollision mag sein: 1:10^-100, und bei Sha isses 1:10^1000 - aber wen interessiert das denn dann noch?
Beides wird, solange die Menschheit noch existiert, niemals auftreten.

Bei MD5 ist es schon aufgetreten und wenn du danach googelst, wirst du auch entsprechend Beispiele finden. Diese beiden Bilder haben z.B. den selben MD5:



Klar, bei den kürzeren Strings ist das schon unwahrscheinlicher, aber ich würde SHA-3 nehmen oder mir einen ganz anderen Ansatz überlegen.

Zenker schrieb:

Würde man beide Zeichenketten konkatenieren, ergäbe sich in der Datenbanktabelle ein eindeutiger Wert.

RodFromGermany schrieb:

Ein Barcode ist nix anderes als ein Text

Bluespide schrieb:

ich würde SHA-3 nehmen oder mir einen ganz anderen Ansatz überlegen

Jo, also String.GetHashCode scheidet aus, zumindest in .NetCore.
Dann kann man einen der anderen nehmen - warum nicht SHA - kostet auch nicht mehr als MD5.
Theoretisch ginge wohl auch MD5, weil es geht ja nicht um Abwehr von iwelchen Angriffen, sondern nur um eine hinreichend kollisionsArme Zahl zu erhalten.
Wobei ich garnet weiss, ob MD5, SHA überhaupt Zahlen ausgeben - ich lese was von Output 128 bit, oder 224, oder 256, oder 512 - Zahlen sind das auf keinen Fall.

Also gerne anderen Ansatz überlegen: Spricht etwas dagegen, die Strings tatsächlich aneinanderzuhängen und so dann auch in die Db zu speichern?
Mein Chef sagt, heutzutage kann man vonne Performance her in einer Datenbank TEXT ebensogut als Primärschlüssel hernehmen wie INT.