Convert Properties to HEX

Why Convert Properties to HEX?

Converting Java Properties files to hexadecimal dump format reveals the exact byte-level content of configuration files, which is invaluable for debugging encoding issues, verifying file integrity, and performing forensic analysis. Properties files are deceptively simple -- their plain text appearance can hide encoding problems, invisible characters, and byte-order marks that cause subtle application failures.

One of the most common use cases is debugging character encoding issues. Java Properties files historically use ISO 8859-1 (Latin-1) encoding, with Unicode characters represented as \uXXXX escape sequences. When a properties file is saved with the wrong encoding (e.g., UTF-8 without BOM vs. Latin-1), the application may silently read corrupted values. A hex dump immediately reveals the actual byte sequences, making it trivial to identify encoding mismatches that would be invisible in a text editor.

Security auditing is another important application. Hex dumps can reveal hidden content in properties files, such as trailing whitespace that changes property values, invisible Unicode characters (zero-width spaces, right-to-left marks) that could be used for obfuscation, or carriage return/line feed inconsistencies that might cause different behavior across operating systems. These security-relevant details are only visible at the byte level.

For teams working with properties files in CI/CD pipelines, hex dumps provide a platform-independent way to verify file content. A hex comparison between two versions of a properties file shows exactly what changed at the byte level, including whitespace changes, encoding shifts, and line ending modifications that a standard text diff might not highlight.

Key Benefits of Converting Properties to HEX:

• Encoding Verification: Identify ISO 8859-1 vs UTF-8 encoding issues instantly
• Hidden Character Detection: Reveal invisible Unicode, BOM markers, and trailing whitespace
• File Integrity: Verify exact byte content for checksum and hash validation
• Cross-Platform Debugging: Detect line ending differences (CR/LF vs LF)
• Security Analysis: Expose obfuscated or injected content in config files
• Binary Comparison: Precise byte-level diff between properties file versions
• Forensic Investigation: Examine properties files involved in incidents

Practical Examples

Example 1: Detecting Encoding Issues

Input Properties file (config.properties):

# App Settings
app.name=Caf\u00E9 Manager
app.locale=fr_FR
app.currency=\u20AC

Output HEX dump (config.hex):

00000000  23 20 41 70 70 20 53 65  74 74 69 6e 67 73 0a 61  |# App Settings.a|
00000010  70 70 2e 6e 61 6d 65 3d  43 61 66 5c 75 30 30 45  |pp.name=Caf\u00E|
00000020  39 20 4d 61 6e 61 67 65  72 0a 61 70 70 2e 6c 6f  |9 Manager.app.lo|
00000030  63 61 6c 65 3d 66 72 5f  46 52 0a 61 70 70 2e 63  |cale=fr_FR.app.c|
00000040  75 72 72 65 6e 63 79 3d  5c 75 32 30 41 43 0a     |urrency=\u20AC.|

Note: \u00E9 = e-acute (Latin-1 byte: E9)
      \u20AC = Euro sign (UTF-8: E2 82 AC)
      0a = Unix line feed (LF)

Example 2: Verifying Line Endings and Whitespace

Input Properties file (deploy.properties):

deploy.host=prod-server.example.com
deploy.port=22
deploy.path=/var/www/app
deploy.user=deployer  

Output HEX dump revealing trailing spaces:

00000000  64 65 70 6c 6f 79 2e 68  6f 73 74 3d 70 72 6f 64  |deploy.host=prod|
00000010  2d 73 65 72 76 65 72 2e  65 78 61 6d 70 6c 65 2e  |-server.example.|
00000020  63 6f 6d 0a 64 65 70 6c  6f 79 2e 70 6f 72 74 3d  |com.deploy.port=|
00000030  32 32 0a 64 65 70 6c 6f  79 2e 70 61 74 68 3d 2f  |22.deploy.path=/|
00000040  76 61 72 2f 77 77 77 2f  61 70 70 0a 64 65 70 6c  |var/www/app.depl|
00000050  6f 79 2e 75 73 65 72 3d  64 65 70 6c 6f 79 65 72  |oy.user=deployer|
00000060  20 20 0a                                           |  .|

Warning: Bytes 60-61 are spaces (0x20) — trailing whitespace
         in deploy.user value ("deployer  " instead of "deployer")

Example 3: Inspecting BOM and Mixed Line Endings

Input Properties file (mixed.properties) with BOM:

spring.profiles.active=production
spring.datasource.url=jdbc:mysql://localhost/db
spring.datasource.password=secret123

Output HEX dump exposing BOM and CR/LF issues:

00000000  ef bb bf 73 70 72 69 6e  67 2e 70 72 6f 66 69 6c  |...spring.profil|
00000010  65 73 2e 61 63 74 69 76  65 3d 70 72 6f 64 75 63  |es.active=produc|
00000020  74 69 6f 6e 0d 0a 73 70  72 69 6e 67 2e 64 61 74  |tion..spring.dat|
00000030  61 73 6f 75 72 63 65 2e  75 72 6c 3d 6a 64 62 63  |asource.url=jdbc|
00000040  3a 6d 79 73 71 6c 3a 2f  2f 6c 6f 63 61 6c 68 6f  |:mysql://localho|
00000050  73 74 2f 64 62 0d 0a 73  70 72 69 6e 67 2e 64 61  |st/db..spring.da|

Issue 1: Bytes 00-02 (EF BB BF) = UTF-8 BOM
  Java Properties reader may treat "BOM+spring" as key name
Issue 2: Bytes 0D 0A = Windows CR+LF line endings
  May cause issues on Unix/Linux deployments

Frequently Asked Questions (FAQ)

Q: What is a hexadecimal dump?

A: A hexadecimal (hex) dump is a representation of data where each byte is shown as a two-digit hexadecimal number (00-FF). It typically includes three columns: the offset address (position in the file), the hex values of each byte, and an ASCII representation of printable characters. Non-printable bytes appear as dots in the ASCII column.

Q: Why would I need to see properties as hex?

A: The most common reason is debugging encoding issues. Java Properties files use ISO 8859-1 encoding by default, but editors often save them as UTF-8. This mismatch can cause characters like accented letters or currency symbols to display incorrectly. A hex dump reveals the actual bytes, making it easy to identify encoding problems that are invisible in text editors.

Q: Can hex dumps detect hidden characters in properties?

A: Yes. Hex dumps reveal all bytes including invisible characters: zero-width spaces (U+200B), byte-order marks (EF BB BF), right-to-left marks (U+200F), trailing whitespace, and null bytes. These hidden characters can cause subtle bugs where a property value looks correct in a text editor but fails at runtime due to invisible extra characters.

Q: How do I interpret line endings in the hex dump?

A: Line endings appear as: 0A (LF, Unix/macOS), 0D 0A (CR+LF, Windows), or rarely 0D alone (classic Mac). Properties files with mixed line endings can cause issues when deployed across different operating systems. The hex dump makes it trivial to verify consistent line endings throughout the file.

Q: What does BOM mean in a hex dump of a properties file?

A: BOM stands for Byte Order Mark (bytes EF BB BF in UTF-8). If present at the start of a properties file, the Java Properties loader may interpret it as part of the first key name, causing the first property to be unreadable. The hex dump clearly shows whether a BOM is present at offset 0x00.

Q: Can I use the hex output to compare two properties files?

A: Yes, hex dumps are excellent for binary comparison. You can diff two hex dump files to see exact byte-level changes between versions of a properties file. This catches changes that text diffs might miss, such as encoding changes, whitespace modifications, or invisible character additions.

Q: How are Unicode escape sequences shown in the hex dump?

A: Unicode escapes like \u00E9 appear as their literal ASCII bytes in the hex dump: 5C 75 30 30 45 39 (the characters \, u, 0, 0, E, 9). This confirms the escape is stored as text, not as the actual Unicode byte. If you see C3 A9 instead, the file contains the raw UTF-8 bytes for the character rather than the escape sequence.

Q: What tools can I use to view the hex output?

A: The output follows standard hex dump format compatible with tools like xxd (Linux/macOS), HxD (Windows), Hex Fiend (macOS), ImHex (cross-platform), and the VS Code Hex Editor extension. You can also use the xxd -r command to reverse a hex dump back to the original binary content for verification.