GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'd enjoy seeing a sed/awk/gawk something-or-other that could turn the original encoded message, into the decoded version.. Anyone?
Sasha
PS - I don't think it'd be TOOOO complicated, but I myself am rather "awkward" wrt awk.
Dhfess!
Come on I KNOW someone's working on that behind the scenes lol -- as speculated the Far-Side farmer carrying the axe through the chcken farm where one chicken has a really long neck: "Whooooo's it gonna be?"
Last edited by GrapefruiTgirl; 09-11-2009 at 05:58 PM.
You passed our idiot filter. What are your 3 favorite books? Please include at least one software engineering book- the others can be whatever- ie., physics, math, etc..
I must admit, at first I thought it was talking about some restaurant, looking for a cook, to prepare items from a small menu including eggs and alcoholic drinks
#include <stdio.h>
#include <string.h>
int main()
{
char data[] = "Doogsauumauipnt >)! Zov qatsfd!ovr!ieipt!fjlues >) Wiau brf zovr!tirfe!fbvprjtf uedhoidam copkt? Pmebsf jndlvdf bt!lfatt!ooe!spfuwbrf fnhioefrjnh copk-uhf ptiess!cbn!bf xhbtfvfr- j.f.- qhzsjct,!mbti,!euc/";
char *lineptr,*linestart,linedecoder;
int linelen;
linestart=data;
linelen = strlen(data);
linedecoder = -1;
for(lineptr = linestart;lineptr <= linestart + linelen;lineptr++)
{
if(*lineptr == 0x33 ) //if an exclamation point invert the logic
{
linedecoder = (linedecoder == -1)?0:-1;
lineptr++;
printf(" ");
}
if(*lineptr == 0x2d ) // if a dash print it and move on without changing the logic
{
printf("%c",*lineptr);
lineptr++;
}
if(*lineptr == 0x20) //if a space print it alone
{
printf(" ");
}
else // if not a space use the linedecoder value
{
printf("%c",*lineptr+linedecoder);
}
linedecoder = (linedecoder == -1)?0:-1;
}
printf("\n");
return 0x0;
}
OK. Here you go. This decodes it correctly with one exception.
It would seem that the "encryption" is not consistent - as is shown by how the i.e. is handled by my translation. The rules I deploy work fine except for the string "- j.f- ". I've fiddled with it but don't see a consistent way to make it work and decided that making a special rule for it was not appropriate.
I put the string in as data rather than fiddle with the spaces in it to bring it in on the command line.
What a way to waste an hour, mostly fiddling with that i.e. string.
Last edited by jiml8; 09-11-2009 at 07:11 PM.
Reason: slight code improvement
#include <stdio.h>
#include <string.h>
void main()
{
char data[] = "Doogsauumauipnt >)! Zov qatsfd!ovr!ieipt!fjlues >) Wiau brf zovr!tirfe!fbvprjtf uedhoidam copkt? Pmebsf jndlvdf bt!lfatt!ooe!spfuwbrf fnhioefrjnh copk-uhf ptiess!cbn!bf xhbtfvfr- j.f.- qhzsjct,!mbti,!euc/";
char *lineptr,*linestart,linedecoder;
int linelen;
linestart=data;
linelen = strlen(data);
linedecoder = -1;
for(lineptr = linestart;lineptr <= linestart + linelen;lineptr++)
{
if(*lineptr == 0x33 ) //if an exclamation point invert the logic
{
linedecoder = (linedecoder == -1)?0:-1;
lineptr++;
printf(" ");
}
if(*lineptr == 0x2d) // if a dash print it and move on without changing the logic
{
printf("%c",*lineptr);
lineptr++;
}
printf("%c",*lineptr+linedecoder);
linedecoder = (linedecoder == -1)?0:-1;
}
printf("\n");
return 0;
}
OK. Here you go. This decodes it correctly with one exception.
It would seem that the "encryption" is not consistent - as is shown by how the i.e. is handled by my translation. The rules I deploy work fine except for the string "- j.f- ". I've fiddled with it but don't see a consistent way to make it work and decided that making a special rule for it was not appropriate.
I put the string in as data rather than fiddle with the spaces in it to bring it in on the command line.
What a way to waste an hour, mostly fiddling with that i.e. string.
Holy crow Jim, nice work
When I decoded this initially, I only did it by eye; no computer involved; so I didn't really look closely at whether the algo will/would work consistently on a one-char-after-the-next basis.
If you include spaces, dashes, and periods, as characters just like letters, then the algo works consistently through that section of the encrypted data. However, a typo on behalf of the original author (such as) like an extra or missing space, would throw off the algo.
but the "j.f." itself translates cleanly.
Regardless, I say again, very nice work!
Sasha
PS - I wish I knew C even half as well as you evidently do
Last edited by GrapefruiTgirl; 09-11-2009 at 07:07 PM.
You shouldn't need to do inversion anywhere. I think the problem at the end is actually caused by the original poster dropping a space after the copk- (which you see in the post containing the entire text.
You shouldn't need to do inversion anywhere. I think the problem at the end is actually caused by the original poster dropping a space after the copk- (which you see in the post containing the entire text.
You shouldn't need to do inversion anywhere. I think the problem at the end is actually caused by the original poster dropping a space after the copk- (which you see in the post containing the entire text.
Yeah, I think you are right. Assuming that data error and changing it makes things a lot simpler. The i.e. is now handled properly. There is one other rule though; you don't subtract from a blank (0x20) because if you do you wind up changing it to a 0x19 which doesn' print.
With that assumed data error, my C program becomes a lot shorter: (I also changed the print from the character by character that I was doing to changing the string in place then printing at the end, like estabroo's perl example, so we have a direct perl/C comparison.
My original code had a rather embarrassing error in it. the ascii for exclamation point is 0x21, or decimal 33. What I was testing for when looking for 0x33 was the character 3. *Sigh*. So, serendipitiously my code worked because it was NOT flipping logic at any point...because there was no 3 in the text.
Actually, with the recognition that we subtract one from the ascii of every other character, unless it is a space, I can remove the decision logic about what value to subtract and instead of testing every char, I just test every other char, just as estabroo does in his perl. I also changed main to type void so I don't need to return anything. This simplifies the code a bit more:
When I decoded this initially, I only did it by eye; no computer involved; so I didn't really look closely at whether the algo will/would work consistently on a one-char-after-the-next basis.
I also did it by eye, once I saw what to do. But that engages the brain's pattern matching mechanisms and you automatically throw out things that don't work. Doing it by computer is harder because computers are completely literal.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.