Hjælp til løsning af ligning

Der er mange loesninger.

Men:

a = c - b

må være en løsning.

Og bare for lige at komme med en mere detaljeret forklaring:

Træk (b % 255) fra c (hvis dette er negativt, så læg 255 til). Det giver dig a % 255.

Eks.:
b = 1016, c = 42

b % 255 = 251
c - (b % 255) = -209 => 46

Du kan se det er rigtigt ved at indsætte a i din ligning:
c = (46 + 1016) % 255
c = 1062 % 255
c = 42

Grundet modulus operatoren kan du ikke vide hvad det nøjagtige værdi var - da a % x = a+x % x (eller sagt på en anden måde, a % x = a+n*x, hvor n er et heltal). (selvfølgelig med mindre du ved at a er indenfor et lille nok interval)

Hvad står %-tegnet for ?
Ligningen er:
c = a%255 + b%255
a%255 = c - b%255
Hvis % står for *% (gange procent) så
a = C/2,55 + b
Hvis % er divisionstegn så:
a = c/255 + b

% er modulus, dvs. divisionsrest. Det er mest i programmeringsmæssig sammenhæng man bruger %, hvilket kommer af at det er det opeartoren hedder i eks. C.

I matematisk sammenhæng ville man normalt skrive "mod".

Hmm... Okay, jeg bliver helt forvirret nu. Jeg forklarer lige yderligere:

Jeg anvender denne ligning (eller disse ligninger) i en krypteringsmotor under udvikling. Krypteringsalgoritmen er:
result += (subject[i] + addition + codex[i % (codex.length() - 1)]) % 255; // VC++

Se, det skulle jeg gerne have regnet godt nok ud - så vidt jeg kan forudse, danner algoritmen koder, der kun kan brydes med brute force. Jeg har før arbejdet med et lignende projekt, jeg fik til at virke - men nu ved jeg ikke, hvor jeg gjorte af kildekoden. Derfor står jeg nu med et problem: Hvordan omvender jeg koden? For at forenkle den:
result = c
subject[i] = a
addition + codex[i % (codex.length() - 1)] = b
Derfor: c = (a + b) % 255

Hvordan pokker får jeg omvendt den algoritme?! Jeg er forvirret!

PS: Da a er en værdi af typen byte (0-255) og udtryk for en char (enkelt karakter), er a=2 lige så godt som a=257.

Char er begrænset til 0-255 (hvilket er 256 værdier, ikke 255), og derfor får du ikke en entydig værdi hvor c = 0 ((a+b) & 0xFF kunne være både 0 og 255). Dermed kan du opnå et unikt resultat ved at bruge % 256 (= & 0xFF - det bør din compiler dog optimere til i den situation) i stedet. Når den ændring er fortaget, så er den nøjagtige fremgangsmåde beskrevet tidligere (fordi dit interval ikke er større end X værdier, hvor X er det du skriver efter %, så kan man bestemme værdien entydigt).

Jeg vil i øvrigt lige minde om Unicode, hvis det her program har blot den mindste relevans udenfor et meget lukket miljø (det er min holdning at man skal have en exceptionel god grund for ikke at bruge Unicode nu om dage). Der skal du huske at de tegn man arbejder med, TCHAR i Windows, fylder 16 bit, så du skal i så fald måske have konverteret dit subject til en anden datatype til krypteringen/dekrypteringen.

den simpleste formel vil nok være

a = (c - b + 256) % 256

hvis det er unsigned char.

char i C/C++ er desværre (!) default -128..127 ikke 0..255

unicode behøver ikke være et problem selvom man processer bytes - noget encoded i 2 bytes
bliver bare krypteret og dekrypteret som 2 separate bytes

Det er korrekt at det ikke behøver være et problem - jeg gør bare opmærksom på at man lige skal huske at der skal en konvertering ind til/fra TCHAR ud fra de bytes man har.

Okay!
result += (subject[i] - addition - codex[i % (codex.length() - 1)]) % 256;
Dvs. a = (c - b) % 256, hvilket jeg har prøvet 100 gange før - det viser sig imidlertid, at compileren ikke rebuildede hele projektet, men i stedet debuggede sidste kompilering - hvorfor?
Nå, nu har jeg i hvert fald fået det til at fungere. Så kan jeg komme videre til næste problemstilling: Hvilken konvertering snakker I helt præcist om mht. Unicode. Jeg vil anvende krypteringsalgoritmen således:
1) Læs rå tekst fra fil
2) Omdan tekst via algoritme
3) Gem omdannet tekst til ny fil
Har 8/16-bitkonflikten så noget at sige?

Hvis du læser chars, krypterer chars, dekrypterer chars og skriver chars så har du ikke
noget problem.

Skønt. Må jeg få nogle svar? :)

.

pidgeot?

Værsgo :)

Sårn!