Encoding and line endings are separate dimensions even when one status bar shows both. To convert text encoding safely, record the change from Shift_JIS to UTF-8 separately from any LF-to-CRLF request. Content equality and delimiter-byte verification need different acceptance rows.
One command sequence, two independent outcomes
The controlled run opened the Shift_JIS specimen, previewed and applied UTF-8 and CRLF settings, then wrote the decoded content as UTF-8. After the workspace closed, independent inspection reported UTF-8 with LF. The prose survived, but the requested CRLF persistence was not demonstrated by this final artifact. Reporting both facts is more useful than calling the whole operation successful.
If a Windows-side tool requires CRLF, “no garbled text” is not enough. Conversely, correct CRLF bytes do not excuse incorrect decoding. Keep the source Shift_JIS file, a verified UTF-8 content copy, and a third duplicate used specifically for newline conversion. That arrangement provides a return point for either failure.
Accept only when reopened encoding, delimiter bytes, character count, and selected lines all match the stated target. This run supports the UTF-8/LF result; it must not be presented as evidence that CRLF was persisted. The distinction prevents a setting response from being mistaken for a saved-file observation.
Write the requirement as two independent fields
Encoding and newline style are orthogonal. A file may be valid UTF-8 while retaining CRLF, or it may use LF while still being Shift_JIS. The job card should therefore contain four explicit values: input encoding, input newline, output encoding, and output newline. A content comparison that normalizes delimiters answers a different question from a byte-level newline count, so keep both when the recipient specifies the physical format.
Identify the source before changing the tab
The persistent evidence set stores the same passage as UTF-8, Shift_JIS, and UTF-16LE. Rune identified those formats and reported decoded lengths of 288, 288, and 289 characters. The Shift_JIS artifact was selected as the conversion source, and its digest fixed the input revision. This prevents a later UTF-8 sample from being mistaken for the original merely because its visible prose looks the same.
Treat tab settings as a plan, not the final artifact
The working tab was changed to UTF-8 and LF through separate operations. Those responses describe the intended save configuration. A physical output was then written from the correctly decoded text, the workspace was closed, and the disk file was inspected independently. It reopened as UTF-8 with LF, retained the same decoded text, and produced digest 63d05d439bc02581056282209d78d988a2af17007dc905e9d2d801ef0923f893.
Diagnose disagreement by axis
If the copy reopens as UTF-8 with CRLF, the encoding pass succeeded and only the newline route needs correction. If it reopens as Shift_JIS with LF, the newline is right but the byte encoding is not. Do not retype prose or repeat both transformations automatically. Return to the unchanged source, repair the failed axis, save under a new name, and run the same independent inspection again.
Preserve line content while changing delimiters
Line-ending conversion should leave the ordered text of each line intact. Compare a normalized line array to prove that claim, then count actual delimiter bytes to prove the physical format. A status bar label alone cannot establish the second result. This separation also catches a final missing newline without confusing it with a lost sentence.
Keep UI-only warnings in their proper category
Product documentation describes red highlighting and an automatic-save pause for encoding conflicts. The CLI evidence did not render that screen, so those behaviors are not presented as observed here. The measured proof is the input matrix, explicit tab operations, physical write, closed-workspace reread, matching decoded text, and saved-file digest.
The sign-off card should list UTF-8, LF, equality after normalized comparison, and the exact output hash. Only when all four agree has the conversion survived its save path. That result is stronger than a successful command because it describes the file that will actually be submitted.
Byte counting needs one additional precaution: the LF byte inside each CRLF pair must not be counted as an independent LF delimiter. Count CRLF pairs first, then count remaining lone LF and lone CR according to an explicit rule. Also declare whether a final terminator is required. A three-line file can contain two separators or three delimiters depending on that convention, and both may display as three lines.
When a recipient reports a mismatch, ask which axis failed. A parser error at byte zero may indicate a BOM or encoding issue; a version-control diff that marks every line changed is more likely a newline mismatch. Return to the fixed input hash, regenerate only the failed representation, and preserve the content comparison. This diagnostic order prevents an innocent newline correction from becoming a second prose edit.
For automation, archive the inspection output beside the submitted file instead of copying values into an untraceable note. The record should point to the input digest, the exact output digest, the intended pair UTF-8/LF, the decoded equality result, and delimiter counts. With those fields, another operator can reproduce the judgment even if the original tab session is no longer open.
An acceptance test should also reopen the file through the same path the recipient will use. A temporary buffer, export preview, or copied console string may normalize newlines invisibly. Inspecting the final named artifact closes that gap and makes the UTF-8/LF statement about delivery rather than intention.
A completed text encoding conversion must prove both UTF-8 and LF in the physical delivery file.