Project 1.5: EncodingHelper Application

This is the final phase of the EncodingHelper assignment. The goal is to create a bug-free, easy-to-use command-line developer utility, building on your existing back-end development.

For this assignment, you will complete an implementation of the EncodingHelper application, as described below.

The EncodingHelperChar class from last time will be a big help, but you will now need to add facilities for parsing the command line arguments and, for some operations, converting strings (not just single characters) into various forms.

You must create at least one new class, EncodingHelper, that contains your main method. You may choose to write all the front-end functionality in this class, or to separate things out into separate classes as you see fit. Your work will be evaluated both on the bug-free behavior of your program, and also on the style and design of your methods.

For example, you might want to write a method that converts a character string into an array or list of EncodingHelper objects. As you design the methods you need, keep in mind the ideas articulated in Steve McConnell's “High-Quality Routines”.

Also, for each non-trivial method you add to your project, you should add at least one unit test method.

Your program should never crash or produce exceptions. Certain internal features of the program produce exceptions, but these should trigger helpful, user-friendly error messages in the program, not arcane stack traces.

Your program must support the baseline features described below, using exactly the command-line syntax given. In addition, your team must implement at least one additional feature, chosen from the list near the bottom of this page.

• Given only a string as its input, EncodingHelper prints out a summary of its Unicode contents.

  $ java EncodingHelper être
  String: être
  Code points: U+00EA U+0074 U+0072 U+0065 
  UTF-8: \xC3\xAA\x74\x72\x65
  

• If the string contains only a single character, then it should include the name of the character in the summary.

  $ java EncodingHelper é
  Character: é
  Code point: U+00E9
  Name: LATIN SMALL LETTER E WITH ACUTE
  UTF-8: \xC3\xA9
  

• The user can specify a particular output type.

  $ java EncodingHelper --output utf8 être
  \xC3\xAA\x74\x72\x65
  

• Short argument names are also supported.

  $ java EncodingHelper -o utf8 être
  \xC3\xAA\x74\x72\x65
  

• The user can specify a particular input type too.

  $ java EncodingHelper --input codepoint U+00E9
  Character: é
  Code point: U+00E9
  Name: LATIN SMALL LETTER E WITH ACUTE
  UTF8: \xC3\xA9
  

• The user can specify both input and output types, specifying them in an arbitrary order and with short or long names for either.

  $ java EncodingHelper --input utf8 --output codepoint '\xC3\xAA'
  U+00EA
  $ java EncodingHelper -i utf8 -o codepoint '\xC3\xAA'
  U+00EA
  $ java EncodingHelper --output codepoint -i utf8  '\xC3\xAA'
  U+00EA
  

  Note that for most terminal programs, if you want to use special characters like the backslash \ in arguments, and have them passed on correctly to the program you're calling, then you need to enclose the command-line argument in single-quotation marks (i.e. apostrophes).

• Conversion works in all directions.

  $ java EncodingHelper -i utf8 -o string '\xC3\xAA\x74\x72\x65'
  être
  

• Every input type supports multi-character input, including codepoints. Multiple codepoints can be passed in either as multiple arguments, or as a single space-separated argument.

  $ java EncodingHelper -i codepoint -o utf8 U+00EA U+0074 U+0072 U+0065
  \xC3\xAA\x74\x72\x65
  $ java EncodingHelper -i codepoint -o utf8 "U+00EA U+0074 U+0072 U+0065"
  \xC3\xAA\x74\x72\x65
  

• If no arguments are given, then EncodingHelper prints out a helpful usage message.

java EncodingHelper [-i type] [-o type] <data>

There are four different input/output types; defaults are marked in green:

To be clear, the default input type is string, the default output type is summary, and the summary type is not valid for input.

--input should be treated as a synonym for -i, and --output should be treated as a synonym for -o.

Note that your utility should run correctly when called from the command line; you should not rely on your user running this program from IntelliJ!

In addition to the features described above, you must implement at least one extra feature:

• Infer the input type by default. (That is, instead of assuming the input is a string, infer from its contents whether to treat it as a string, a sequence of codepoints, or a sequence of bytes.)
• Allow more flexible input formatting for codepoints and bytes. (That is, behave the same when the user gives you a codepoint in the form U+00EA, \u00EA, 00EA, u00EA, etc. Behave the same when the user gives you a byte sequence in the form \xC3\xA9, C3A9, xC3xA9, etc.)
• Support an additional input type, name, that lets the user provide a partial character name, interactively provides them with multiple options until they have narrowed it down to just one, and then tells them the summary.
• Support an additional output type, lang, that infers the larger category that the input belongs to, and reports it. The lang output should be reported as part of the summary too.
• Your own choice of feature. If you choose to do something different than the above, your readme file (see below) must justify your choice.

Create a plaintext file called readme.txt in the root directory of your repository (not inside IntelliJ's src directory). In that file, state the names of both people in the pair, and also give a brief description (with explicit usage examples) of the additional feature that you implemented.

Like source-code files, plaintext files should have lines no longer than 80 characters, and should not have tab characters in them.

Submit your program (including the readme file) by committing (and pushing) it to your Bitbucket repository, tagged as phase4_final. Remember to double-check on Bitbucket that your push worked.

Have fun!