Hallo Leute,
ich bin auf der Suche nach einem Quellcode für einen Rot-n Algorithmus
ausgelegt für die Asciizeichen im Bereich 33 bis 126.
Meine bisherige Lösung implementiert lediglich Rot47. Aktuell mache ich
damit eine Text unlesbar. Nun würde ich jedoch gerne die Funktion
dahingehend erweitern, dass wenn an einer bestimmten Stelle eine Zahl
zwischen 1 und 47 auftaucht, der Text um die besagte Zahl verschoben
wird.
Aktuelle programmiere ich in Visual Basic aber wenn ihr zufällig nen
passenden Codesnippet rumfliegen habt würde ich mich sehr über den Code
freuen, unabhängig von der Sprache (jedenfalls was die geläufigsten
angeht ;)).
Schönen Sonntag noch,
J.L.
Du meinst sich die "rotate by n" oder Caesar-Verschlüsselung.
Du addierst einfach n auf deinen Asciiwert und beim Überschreiten der
Bereichsgrenzen fügst du eine Sonderbehandlung ein. Dafür kannst du den
Modulo-Operator nutzen.
Notiere dir mal die Rahmenbedingungen auf einen Zettel und du wirst
schnell zu einer Lösung gelangen.
Grüsse
Dein Bereich liegt zwischen 33 und 126 bzw. '!' und '~'.
Bei der Verschlüsselung wird der Wert > 126, dass musst du behandeln.
Bei der Entschlüsselung wird der Wert < 33, dass musst Du ebenfalls
behandeln.
Warum verwendest Du '&'? Ist dieses den kein logischer Operator? Den
Zusammenhang verstehe ich hier nicht.
Grüsse
Markus M. schrieb:> Warum verwendest Du '&'? Ist dieses den kein logischer Operator? Den> Zusammenhang verstehe ich hier nicht.
Das ist in Basic der Zeichenketten-Verkettungsoperator.
Wenn ich mich recht entsinne, darf in Visual Basic die Mid()-Funktion
als Mid-Anweisung auch als l-value stehen, sodass man direkt zuweisen
kann.
Die Frage zu dem &-Opertaor wurde ja bereits erklärt daher
habe ich jetzt mal versucht den Code anzupassen aber es will noch nicht.
Ich möchte im Bereich von 1 bis 47 verschieben, daher komme ich
zwischen 'p' über die '~' möglicherweise über die grenzen und
sicherstellen das er beim Verschlüsseln ein Zeichen >32 daraus macht.
Mein Code sieht jetzt wie folgt aus.
1
Public Function encode(strInput As String, n As Integer)
Ist doch klar, dass es Chaos gibt Du gibt die Grenzen mit 80 und 126
vor. Gehst aber davon aus, das dein "Alphabet" bei 32 beginnt.
Was kommt heraus, wenn Du 32 durch 80 ersetzt oder äquivalent 80 durch
32?
Ausserdem sollte der Inputwert immer innerhalb der Grenzen liegen. Das
brauchst Du nicht zu prüfen. Denn umgekehrten Fall musst Du prüfen.
Range: 33 bis 126
if: (input + n) > 126 -> (input + n + 33 ) - 125 - 1
Grüsse
Dann kommt auch nur Blödsinn raus. Alles was nicht in den Grenzen ist
(ausgehend davon das auch nur auch nur Zeichen verschlüsselt werden die
in dem Bereich 33-126 liegen) wird ja mit dem ELSE-Zweig abgefangen und
um n erhöht.
Johannes Lake schrieb:> asciidec = (asciidec Mod 126) + 32
Das 'Mod' kannst du hier auch durch ein '-' ersetzen, also
1
asciidec = asciidec - 126 + 32
oder gleich
1
asciidec = asciidec - 94
> If (asciidec < (126 - n)) Then> asciidec = asciidec - 32> asciidec = asciidec + 126> asciidec = asciidec - n> Else> asciidec = asciidec - n> End If
Statt (126 - n) müsste in der obersten Zeile (33 + n) stehen.
Oder mach's einfach genauso wie bei encode, nur andersherum:
1
asciidec = asciidec - n
2
If asciidec < 33 Then
3
asciidec = asciidec + 94
4
End If
Gleiche oder sehr ähnliche Code-Abschnitte sind meist schlecht, weil
aufwendiger zu lesen und weniger wartungsfreundlich. Besser und noch
einfacher geht es so:
1
Public Function decode(strInput As String, n As Integer)
> Das 'Mod' kannst du hier auch durch ein '-' ersetzen, also
Bei Verwendung von Modulo sind beliebige n bei der Verschlüsselung
gültig. Z.B. Auch n = 555. Wieder eine Abfrage gespart. ;-)
Funktionssicherheit erhöht!
@ Johannes
Wenn Du jetzt noch die Zahlen durch sprechende Konstanten ersetzt, wird
es nochmal ein Stück sauberer.
Grüsse
Markus M. schrieb:> Dann etwas präziser: für n > 0
Also doch eine Abfrage ;-)
Nee, du hast schon recht. Mod ist sicherer als nur eine Subtraktion, nur
eben noch nicht völlig sicher.
Gerade bei Integer-Divisionen und Modulo-Operationen muss man bei
negativen Operanden höllisch aufpassen, um keine Überraschungen zu
erleben. Zudem werden negative Operanden in verschiedenen Programmier-
sprachen unterschiedlich behandelt, leider meist so, wie man es nicht
erwartet ;-).
Nicht einmal innerhalb von Microsoft kann man sich auf eine einheitliche
Definition der Modulo-Funktion einigen, deswegen liefert das Visual-
Basic-Mod andere Ergebnisse als das Excel-Mod. Das ist für die Anwender
schwer nachvollziehbar, da VBS ja ein Bestandteil von Excel ist:
http://support.microsoft.com/kb/141178