Faith & Code | Reflections by Errong

How to Safely Truncate a String by Byte Length in Java (UTF-8 Solution) In Java backend development, it’s common to enforce size limits on strings, such as: Database column byte limits API payload size constraints Logging or message size restrictions A typical approach is: value.substring(0, n); However, this is not safe when dealing with UTF-8 encoding . The Core Problem: Characters ≠ Bytes In UTF-8 encoding: ASCII characters → 1 byte Chinese characters → 3 bytes Emoji → 4 bytes For example: "hello" → 5 bytes "你好" → 6 bytes "😊" → 4 bytes This means: Truncating by character count does NOT guarantee byte size limits --- Does Java Provide a Built-in Solution? No — Java does not provide a direct method to safely truncate a string by byte length. While Java offers low-level APIs such as: CharsetEncoder ByteBuffer String.getBytes() They are not designed for simple, safe truncation and requ...

Fix “Value Too Long for Column” Error: UTF-8 String Truncation by Bytes in Java If you've ever encountered the "value too long for column" database error, especially in a Java backend, the root cause may not be obvious. In this post, we’ll walk through a real production issue caused by UTF-8 encoding , explain why string length is not equal to byte length , and show how to correctly truncate strings by bytes without breaking multibyte characters. The Production Issue We hit a production error during a database insert: value too long for column Database column limit: 50 bytes Input string length: 53 characters Code already truncated to 50 characters At first glance, everything looked correct—but the insert still failed. Root Cause: UTF-8 Encoding The issue comes down to this: 50 characters does NOT equal 50 bytes in UTF-8 In UTF-8 encoding: ASCII characters → 1 byte Chinese characters → 3 bytes Emoji → 4 bytes This mean...

A Lesson Learned: Slow DELETE Caused by Missing FK Indexes Recently, I was working on a data purge task. The logic itself was simple: delete old records based on certain conditions. I had done similar work before, so I did not expect any major issues. However, this time the DELETE operation got stuck . No errors were reported, but the SQL just kept running without making progress. What Happened? With help from our DBA, we started investigating the issue at the database level. After some analysis, we identified the root cause: Several foreign key (FK) columns were missing supporting indexes. Because of this, every DELETE on a parent table forced Oracle to perform full table scans on related child tables to validate referential integrity. As data volume increased, the performance impact became severe. The Fix After adding indexes on the missing foreign key columns (across related tables), the results were immediate: DELETE operations completed much faster ...