CSV import does not strip UTF-8 BOM, breaking first column header recognition

Problem Statement

The Content Import tool does not strip the UTF-8 Byte Order Mark (BOM) from uploaded CSV files. When a BOM is present, the first column header is not recognized correctly, so the import silently mismaps or fails to match that column — with no error surfaced to the user.

This is a common round-trip: a customer exports content from dotCMS as CSV, opens/edits it in Excel, and re-saves as "CSV UTF-8 (Comma delimited)" — which Excel writes with a BOM (EF BB BF). Re-importing that file then breaks on the first column.

Impacts any customer using the CSV import/export round-trip via Excel. Silent failure — costs support time to diagnose because no error is shown.

Steps to Reproduce

1. Export (or create) a CSV whose first row is the header row.
2. Save the file as "CSV UTF-8 (Comma delimited)" in Excel (this prepends a UTF-8 BOM, bytes EF BB BF).
3. Import the file via the Content Import tool.
4. See that the first column header is not recognized — the BOM is treated as part of the first header token, so that column fails to map.

Acceptance Criteria

• The CSV import parser detects and strips a leading UTF-8 BOM before parsing the header row.
• The first column header is recognized correctly when the uploaded file contains a BOM.
• BOM handling is consistent (ideally UTF-8/UTF-16) so re-imported Excel "CSV UTF-8" files work without manual editing.

dotCMS Version

Evergreen

Severity

Medium - Some functionality impacted

Links

• Freshdesk ticket #36020

Start at the Content Import tool's CSV import parser and trace how the header row is read. Add coverage for a leading UTF-8 BOM, then verify that the first column maps correctly and that the existing import behavior remains intact; consider the stated UTF-16 consistency requirement if the parser supports it.