CSC 101 / CPE 101:
Fundamentals of Computer Science 1

1. Prompt for and read an encryption key.
2. Build the cipher[] tool.
3. Prompt for and read an input String to be encrypted.
4. Encrypt the String you received.
5. Display the encoded message.
6. Offer to loop for more.

1. Prompt for and read an encryption key. This is size of the offset.
   
   
   • This value should be an integer.

     You should handle gracefully any input that is not an integer. (That is, you don't yet know enough to stop from printing the error line that will be printed to the screen, but you should be able to recognize when a non-integer result is entered and keep prompting for input that is acceptable.)

   • What offset values are acceptable?
     
     
     • It is strongly recommended that you do permit an actual offset of 0 (zero).

       While not practical for encryption and decryption, since it doesn't change the message, it is very useful during development! Test your program first using that: While a correct result with an offset of 0 does not guarantee that your program will work for other keys (do test those too), any errors with no offset should be easy to spot (easier than with encrypted text) and may even help you to narrow down the places you have to look to locate and correct your error(s). Note that the starter-code provided assigns the variable called offset to hold the value zero, but does not use it in any calculations: the actual offset of zero mentioned here is one that is fully exercised throughout the program.

     • It is recommended that your program do all its operations with positive offset values. If you need to do some debugging it should be easier this way.
       
       
       • You may still accept negative offset values from the user. Just convert them to the equivalent positive offset yourself. If you are given an alphabet whose size is NUM_CHARS and a cipher OFFSET that is negative, you can combine those values to get the equivalent positive shift. Here are some examples if NUM_CHARS is 26:
         • and OFFSET = -1, that's the same as a shift of 26 - 1 = +25;
         • similarly if OFFSET = -2, that's the same a shift of 26 - 2 = +24;
         • and if OFFSET = -15, it's the same as a shift of 26 - 15 = +11.
       
       
       • If you want to practice working with negative offsets, once you have positive ones working correctly, you may do so. If so, be aware of the behavior of the remainder operator with negative numbers: in the expression a % b, the result should always have the same sign as a. That is, if a is negative, the result will be negative. (Note that this is not the same rule as is applied in a / b, and that the rule that sets this up was actually embedded in an early quiz question.)
     
     
     • How will you handle the situation of | OFFSET | > NUM_CHARS?

       Remember, the offset comes from user input but the alphabet to be accommodated is set by the programmer. Here are the obvious choices you should consider:

       • If you choose to limit the maximum amount of offset you will handle, your prompt should indicate that. But it's your choice if you do this initially, or only when you re-prompt someone who has entered a value outside the range.
       • Alternatively, if you accept a shift of any magnitude, then your program should handle all possible values gracefully. (For example, if NUM_CHARS is still 26, then what is a reasonable thing to do if a user requests an offset of 27? of 52? of -28? Do you handle that the same as an offset of 2147483648? -2147483648? Why or why not?)
       • You might think that the former (the simple limit) is easier, and it probably is. But you'll need to think through most of the algorithm for the latter option anyway (e.g., for the part of the program where you fill cipher[ ] ), so why not try to extend that concept here? (Specifically, permitting the user to input absolutely any integer-sized offset is not required to get a simple check-off for the lab, but it is strongly recommended for practice prior to future quizzes and exams.)

       If you agree to accept an offset that is larger in magnitude than the number of characters in your alphabet, then you should convert it to something inside that range before you use it anywhere else. That is, if you are converting 26 different letters, your cipher[ ] array will have indices from 0 to 25, and you should do all your own computations with numbers in the range from -25 to + 25. Hint: What one useful arithmetic operator can you use to convert any integer value input by the program's user into an integer limited to that range?

2. Generate a character array of length NUM_CHARS to hold the ciphered equivalent of each character in the user input (which you'll gather in a moment...).

   That is, if the array is called cipher[ ], then: cipher[0] should hold the ciphered equivalent of an 'a'; cipher[1] should hold the ciphered equivalent of 'b'; and so on. Make sure you understand why that is the most appropriate way to do this. In addition:

   • Do not try to fill this in manually. You are required to write an algorithm to do it. Think about how to use the "index" and SHIFT to compute the ciphered letter.
   • Do use the character at the start of your standard alphabet in your computations.
   • Do not use the Unicode equivalent of the character at the start of your alphabet in your computations. Use the literal itself (i.e., 'a'). This is better style: it makes your program easier for other human beings to read and maintain.
   • Remember that, if you do math on a character value, the result will be a number. If you need it to be a character, then cast the number back into the character type.


3. Prompt for and read an input String to be encrypted.
   
   
   • By now, you should have already downloaded the instructor's StartCaesar.java file to get you started. If you haven't done so yet, get it now. Make sure you understand how it works.
     
     
     • This is a program that reads a message from its input into a long string and writes it back out again.
     • It handles certain input more gracefully than does the Keyboard class alone. It just keeps accepting input until you actually send a "null" command (Control-Z on DOS or Control-D on Unix, after pressing the return key).
     • Why does any of that matter? Well, for simple text input in lab, it doesn't really matter all that much. You can skip the bullets indented underneath this item if you're already feeling overwhelmed, but if you're curious, here are quick notes on why it is recommended that you use that.
       
       
       • In real life, if one is encrypting text, one is likely to want to encode more than just a few words. In fact, you might even want to read input from a file, rather than type in lots of text (and re-type it, if you make mistakes), and return output to another file (that you can save and transmit in encoded form). This moving of program data from or to a file is known as redirection.
       
       
       • One of the interesting aspects of Java is that a program's input and output are just special files attached to the console. If you want, you can set standard input (and standard output) to read from (or write to) other files using input (or output) redirection. In both the DOS and Unix shells, you can use the less-than (<) character to tell the program to read from the named file rather than the keyboard, and the greater-than (>) character to tell it to write to a named file rather than the keyboard. For example:

         %java Caesar < infile > outfile

         would run the Caesar class, taking its input from the file named "infile" and writing its output to the file named "outfile".

         (On a Mac, where you don't have command lines, you do this in the tool called JBindery that you run instead of the DOS/Unix java command. Redirection of input and output are fairly obvious: they are menu-buttons in the main JBindery window. In settings where one wants to use other command-line arguments, they can be entered in JBindery's Optional Parameters window.)

       • If you still don't get it, first get the program to work as described in this lab, safely save a copy of it, and then do some experiments. Get yourself another copy of your instructor's preliminary version of StartCaesar.java, and play around with it to see what happens if you remove and replace various bits from the given code... But do realize that this lab expects you to start with StartCaesar as given, inserting your additional code without otherwise modifying what was given: so any playing around with the given code is for your own additional enlightenment.
     
     
     • Notice that the given file already contains a declaration for the character translation array, cipher[ ], indexed from 0 through 25. You really should use it, but make sure you understand the examples above illustrating what it does.


4. Encrypt the String you received, according to the following rules:
   
   
   • Non-letters are simply passed along as-is.
     To do that you may either:
     • write your own test for letter in either lower or upper case, and pass along anything that fails that test, or
     • use the Character.isLetter(char c) method.
   
   
   • Letters in lower case are returned as ciphers in lower case.
     You may use either:
     • your own test for a lower case character, or
     • the Character.isLowerCase(char c) method.
   
   
   • Letters in upper case are returned as ciphers in upper case.
     You may use either:
     • your own approach to identify an upper case character, or
     • the Character.isUpperCase(char c) method.

     It is recommended (and the design is set up so) that you do the conversion for upper case letters as follows:

     • change the upper case letter to lower case,
     • apply to it the same technique you used for letters in lower case,
     • and finally change it back to upper case before returning it.
   
   
   • Feel free to look up the Character class in your book to see if you can identify any other methods that may be useful to you.


5. Display an output String that is the input String encrypted by the offset key.
   
   
   • Once you have completed all the steps above, then the loop in the given program (i.e., StartCaesar.java) should already output, instead of the original text, the text as it is being encoded.


6. When the encryption of a given String has been completed, ask the players if they want to encode another one, and repeat the process if they type y (as either y or Y). Otherwise, exit gracefully, acknowledging that the program run has completed. Be aware, however, that this step does not require any work with arrays, and arrays are what you should be practicing with this lab, so it's far more important that you do the rest of the tasks than that you complete this one.