Skip to content

Support non-UTF-8 encoded CSV files #20473

Open

Description

@Rafferty97

Is your feature request related to a problem or challenge?

Currently, Datafusion doesn't appear to support reading CSV files that use a non-UTF-8 encoding scheme, such as the common ISO-8859-1 or others.

While CSV may be a terrible data format, it's also ubiquitous in the wild and many of them use alternative character encodings. It would be useful if there was an option to read CSV files that use an encoding other than UTF-8.

Describe the solution you'd like

Add an option to CsvOptions or elsewhere to specify the encoding used by the input file, defaulting to UTF-8. Datafusion could then use encoding_rs internally to decode chunks of incoming data.

Describe alternatives you've considered

An alternative to depending on encoding_rs directly would be to expose an option that allowed users to provide their own decoding logic, which they would then likely delegate to encoding_rs. This might be desirable if the added dependency is deemed to heavy (though it could easily be put behind a feature flag).

Additional context

No response

Activity

  1. Rafferty97 commented on Feb 22, 2026

    @Rafferty97
    ContributorAuthor

    I have made a start on this work here: https://github.com/Rafferty97/datafusion/tree/non-utf8-csv

    I'm not sure about my approach to feature flagging, or how to best add unit tests.

  2. Rafferty97 commented on Feb 23, 2026

    @Rafferty97
    ContributorAuthor

    On second thought, I suspect this might be better implemented in arrow-csv itself, so I'm going to experiment with that option now.

  3. Rafferty97 commented on Feb 24, 2026

    @Rafferty97
    ContributorAuthor

    I have opened a PR to incorporate this functionality into arrow-csv: apache/arrow-rs#9468

  4. Rafferty97 commented on Mar 1, 2026

    @Rafferty97
    ContributorAuthor

    I have closed my PR in arrow-csv based on feedback from reviewers, as they would prefer that consumes of library perform their own decoding rather than extending its API. I will open a PR for this one soon.

  5. Rafferty97 commented on Mar 1, 2026

    @Rafferty97
    ContributorAuthor

    take

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions