code: public static String stringDefaultValue(String bytes) {
      try {
        return new String(bytes.getBytes("ISO-8859-1"), "UTF-8");
      } catch (UnsupportedEncodingException e) {
        // This should never happen since all JVMs are required to implement
        // both of the above character sets.
        throw new IllegalStateException(
            "Java VM does not support a standard character set.", e);
      }
    }
docs: Helper called by generated code to construct default values for string
  fields.
  <p>
  The protocol compiler does not actually contain a UTF-8 decoder -- it
  just pushes UTF-8-encoded text around without touching it.  The one place
  where this presents a problem is when generating Java string literals.
  Unicode characters in the string literal would normally need to be encoded
  using a Unicode escape sequence, which would require decoding them.
  To get around this, protoc instead embeds the UTF-8 bytes into the
  generated code and leaves it to the runtime library to decode them.
  <p>
  It gets worse, though.  If protoc just generated a byte array, like:
  new byte[] {0x12, 0x34, 0x56, 0x78}
  Java actually generates *code* which allocates an array and then fills
  in each value.  This is much less efficient than just embedding the bytes
  directly into the bytecode.  To get around this, we need another
  work-around.  String literals are embedded directly, so protoc actually
  generates a string literal corresponding to the bytes.  The easiest way
  to do this is to use the ISO-8859-1 character set, which corresponds to
  the first 256 characters of the Unicode range.  Protoc can then use
  good old CEscape to generate the string.
  <p>
  So we have a string literal which represents a set of bytes which
  represents another string.  This function -- stringDefaultValue --
  converts from the generated string to the string we actually want.  The
  generated code calls this automatically.