Adalennis opened a new issue, #9032:
URL: https://github.com/apache/hop/issues/9032

   ### Apache Hop version?
   
   2.20.0-SNAPSHOT
   
   ### Java version?
   
   Java 21
   
   ### Operating system
   
   macOS
   
   ### What happened?
   
   With an encoding whose Java charset writes a byte order mark (`UTF-16`, 
`x-UTF-16LE-BOM`),
   Text File Output writes a BOM before every value, separator and line break, 
not once at
   the start of the file. Readers skip the first one and keep the others as 
`U+FEFF`
   characters inside the data: a value `V001` is read back as `V001\uFEFF`.
   
   Steps to reproduce: a Data Grid with 3 rows into a Text File Output (no 
header,
   separator `;`, Encoding `x-UTF-16LE-BOM`). With one String field the file 
has 6 BOMs
   instead of 1; with two fields it has 12, one before every value, separator 
and
   line break:
   
       fffe 5600 3000 3000 3100 fffe 3b00 fffe 4d00 ...   BOM V001 BOM ; BOM 
Maria ...
   
   `UTF-16` gives the same result (big-endian BOMs); `UTF-16LE` gives none, so 
there is no
   way to write a UTF-16 file with a single leading BOM, which some receiving 
systems expect.
   
   Cause: `TextFileOutput` encodes each value on its own with 
`String.getBytes(encoding)`
   (lines 577, 592 and 643 on main), and the separator, enclosure and newline 
once each with
   `getBytes(encoding)` in `init` (lines 1100–1106), which are then written 
again and again.
   Java's UTF-16 charsets add a BOM to every `getBytes` result.
   
   Expected: one BOM at the start of the file, and the values encoded without 
one.
   
   ### Issue Priority
   
   Priority: 3
   
   ### Issue Component
   
   Component: Hop Gui


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to