Class McpBinary

java.lang.Object
com.mcpdbwizard.pub.McpBinary

public final class McpBinary extends Object
How a RAW crosses the Model Context Protocol when it is an INDEX-BY table element, in one place.

MCP has no binary type: a byte string crosses as base64 text, the same way a BLOB does everywhere else in the generated server. An index-by table cannot hold bytes either -- PlsqlIndexByTable2 stores every element as a String or a BigDecimal and has no third representation -- so a RAW rides its VARCHAR slot as hex, which is what the emitted anonymous block converts with HEXTORAW on the way in and RAWTOHEX on the way out.

Two text encodings of the same bytes, and the gap between them is the whole of this class. That is why RAW stayed gated for MCP after DATE and TIMESTAMP crossed: those two were a MASK disagreement, fixed by moving one character, and this is an ENCODING disagreement, which needs real conversion in both directions.

It lives here rather than in emitted source for the reason McpDates does: it can be unit-tested here and cannot be tested there. The generator writes one call per direction.

Base64 in, and what is tolerated

Whitespace is stripped, the URL-safe alphabet (- and _) is accepted alongside the standard one, and missing = padding is supplied. None of those three is a guess: no character means two different things across the two alphabets, and an unpadded string has only one possible completion. Anything that is still not base64 is REFUSED with a message naming the accepted form -- see McpDates on why a message that merely echoes the input is worse than useless when the caller is a model, which retries blind and turns one bad argument into a connection storm.

What CANNOT be detected, and is therefore documented instead of guessed at. A caller that sends hex rather than base64 is not refused: DEADBEEF is eight characters from the base64 alphabet and decodes cleanly to four completely different bytes. There is no signal to key on, so the tool description says base64 out loud rather than this method trying to be clever. Sniffing for hex would break every value that is legitimately both. Copyright 2003-2026 ATB Consultancy Services Ltd (formerly Orinda Software Ltd, Dublin, Ireland)

Since:
2.0.6
Author:
[email protected]
  • Method Details

    • toOracleRawText

      public static String toOracleRawText(String theBase64)
      A base64 tool argument to the hex an index-by table's HEXTORAW expects.
      Parameters:
      theBase64 - the caller's value, or null
      Returns:
      uppercase hex, or null for a null input
      Throws:
      IllegalArgumentException - if the value is not base64
    • fromOracleRawText

      public static String fromOracleRawText(String theHex)
      The hex an index-by table's RAWTOHEX produced, back to the base64 MCP crosses.

      Oracle always renders an even number of digits, so an odd length means the value did not come from RAWTOHEX and is reported rather than silently truncated -- dropping the last nibble would hand the caller bytes that are almost right, which is the failure mode this whole area exists to avoid.

      Parameters:
      theHex - the value read back from the collection, or null
      Returns:
      base64, or null for a null input
      Throws:
      IllegalArgumentException - if the value is not an even-length run of hex digits