Project 1.4: EncodingHelperChar Implementation

Implement the core features of EncodingHelper, to create the foundation upon which you'll build a great application!

Implement all the methods defined in EncodingHelperChar.java to match the specifications given in the Javadoc comments. Run your test suite and make sure that your implementation passes. (It's also possible that you wrote some of your tests incorrectly, of course; the grader and I will be checking that ourselves, but you won't hear back from us before this phase of the project is due. So if you notice any errors in your tests, go ahead and fix them.)

As mentioned in the last phase, the EncodingHelperChar class should support all codepoints formally defined in Unicode, even those beyond the basic multilingual plane. You can consult the official UnicodeData.txt data file and/or the Unicode tables on Wikipedia to investigate this. Make sure that you test support throughout the Unicode space! If you think of new tests while you're working on this phase, go ahead and add them to your test class.

For the getCharacterName method, you'll need the file UnicodeData.txt. This file is small enough (just about 1MB) that it's fine to include it as part of your project and to store it in your Git repo, so please do that.

Further Specifications

• Illegal inputs to any method should result in an IllegalArgumentException being thrown. It's up to you what you want the exception's message to be, but you should use that specific exception type. For example:

  • The codepoint U+130F21 is illegal; Unicode only defines valid codepoints up to U+10FFFF. Any input that attempts to create or work with such a codepoint should throw an exception.
  • The codepoint U+2C1F7 is not illegal, even though it is not assigned a character in Unicode. Creating or working with this codepoint should never throw an exception.

• If a codepoint has a name defined in UnicodeData.txt, then getCharacterName() should return the name defined there. There are two special situations to consider:

  • If the specified name is “<control>”, then you should append the more specific name from the “comment field” near the end of that character's row. For example, U+0007 should be given the name <control> BELL.
  • If the codepoint is valid but not defined in the table, then it should be given the name “<unknown>” followed by the codepoint in hexadecimal. For example, U+3FFF should be given the name <unknown> U+3FFF. (For what it's worth, deeper investigation in online sources reveals that this codepoint corresponds to the Han character for “wine cups”. But that's more work than your program should do; for the names, rely only on UnicodeData.txt.)
• Do not change the specification or signature of any of the methods provided in the starter code. Also, do not define any additional member data — the Unicode codepoint is the single value that determines the meaning of an EncodingHelperChar object.
• However, if you wish you may define constants (as private static final <Whatever>) or helper methods in your class. Helper methods should be private, and therefore should not be tested directly by your JUnit tests; instead, you should be thoroughly testing the public methods that use your helpers.

You may not be familiar with working with bits and bytes directly in a program (in Java or otherwise). To help you along with that, I created a demo program with lots of comments that shows how to work with Java's byte type and pulling individual bits out of it. So go ahead and download BitDemo.java and compile it (just using javac on the command line; no need to put it in a project in IntelliJ). Then run it, and read through the source code as you examine the output.

A couple things to point out:

• When Java interprets bytes as numbers, it interprets them as signed 8-bit integers in two's complement. The value that you get from this interpretation has nothing to do with our project, and is a distraction that you should avoid in your code. When you want to express a byte using a literal, write the literal in hexadecimal (with the leading 0x) and cast it to a byte. Your program (and your test code) should probably not have any values written in it in decimal.
• When you want to display a byte (to the user, or for debugging purposes), use a helper function (like the one in the demo program) to convert it into a string that shows its value in hexadecimal, or maybe in binary if you feel that's helpful. Again, the decimal value that Java thinks a byte represents has nothing to do with our project, and should not be used for communication with users.
• Strings are for presentation to humans only. They are not an appropriate intermediate format for computation, especially not for operations on bits. Use bitwise operators instead.
• CS 202 and CS 208 both cover information that's relevant to this aspect of your project. I believe that the demo shows you everything that you need, but putting together the building blocks can still be a challenge. So please post to Piazza if you've got any questions.

Submit your program by committing (and pushing) it to your Bitbucket repository, tagged as phase3_final.

Remember to double-check on Bitbucket that your push worked, and also that the repo is shared with me and the graders!