[Evaluation] Fix UTF-8 encoding for red team JSONL files on Windows#45500
Merged
slister1001 merged 8 commits intoAzure:mainfrom Mar 10, 2026
Merged
[Evaluation] Fix UTF-8 encoding for red team JSONL files on Windows#45500slister1001 merged 8 commits intoAzure:mainfrom
slister1001 merged 8 commits intoAzure:mainfrom
Conversation
Add explicit encoding='utf-8' to all file open() calls in the PyRIT result processing path. Without this, Windows defaults to the system locale encoding (charmap/cp1252), causing UnicodeDecodeError when reading JSONL files containing non-ASCII characters from UnicodeConfusable strategy or CJK languages. Fixes: Tests 1.7 (UnicodeConfusable), 1.16 (Japanese/Chinese) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dab8c4e to
c6e7d30
Compare
Test CJK characters, Unicode confusables, and mixed scripts to prevent future regressions of the charmap encoding bug on Windows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
slister1001
added a commit
to slister1001/azure-sdk-for-python
that referenced
this pull request
Mar 4, 2026
Cherry-picked all 3 red team bug fixes for the bug bash: - Fix UTF-8 encoding for JSONL files on Windows (PR Azure#45500) - Fix model_config 404 for Foundry-style endpoints (PR Azure#45502) - Add early input validation to scan() (PR Azure#45501) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses Windows-specific UnicodeDecodeError failures when reading red team JSONL files that contain non-ASCII text by ensuring UTF-8 is explicitly used for JSONL file I/O in the PyRIT result processing flow.
Changes:
- Add
encoding="utf-8"to JSONL reads in the red team result processor. - Add
encoding="utf-8"to JSONL read/write operations in red team formatting utilities. - Add unit tests intended to cover Unicode JSONL round-trips; update version/changelog for the next release.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| sdk/evaluation/azure-ai-evaluation/azure/ai/evaluation/red_team/_result_processor.py | Reads JSONL data files using explicit UTF-8 to avoid Windows locale decode errors. |
| sdk/evaluation/azure-ai-evaluation/azure/ai/evaluation/red_team/_utils/formatting_utils.py | Uses explicit UTF-8 when reading existing JSONL and writing JSONL output files. |
| sdk/evaluation/azure-ai-evaluation/tests/unittests/test_redteam/test_formatting_utils.py | Adds tests intended to validate Unicode JSONL read/write behavior. |
| sdk/evaluation/azure-ai-evaluation/azure/ai/evaluation/_version.py | Bumps package version to 1.16.0. |
| sdk/evaluation/azure-ai-evaluation/CHANGELOG.md | Adds an Unreleased 1.16.0 entry describing the UTF-8 fix. |
nagkumar91
approved these changes
Mar 9, 2026
Member
nagkumar91
left a comment
There was a problem hiding this comment.
Core fix is correct — adding encoding="utf-8" to all 4 open() calls is the right approach for Windows compatibility.
Minor suggestions (non-blocking):
- The new tests do manual
open()round-trips but don't exercise the actual production functions (write_pyrit_outputs_to_file()/to_red_team_result()). Consider adding integration tests that call those functions with Unicode data to validate the complete fixed path. - Note: PR #45502 also bumps the version to 1.16.0, so whichever merges second will hit a conflict on
_version.pyandCHANGELOG.md.
…GELOG Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…/azure-sdk-for-python into fix/redteam-encoding
nagkumar91
approved these changes
Mar 10, 2026
aprilk-ms
pushed a commit
that referenced
this pull request
Mar 11, 2026
…45500) * Fix UTF-8 encoding for red team JSONL files on Windows Add explicit encoding='utf-8' to all file open() calls in the PyRIT result processing path. Without this, Windows defaults to the system locale encoding (charmap/cp1252), causing UnicodeDecodeError when reading JSONL files containing non-ASCII characters from UnicodeConfusable strategy or CJK languages. Fixes: Tests 1.7 (UnicodeConfusable), 1.16 (Japanese/Chinese) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add encoding regression tests for non-ASCII JSONL round-trip Test CJK characters, Unicode confusables, and mixed scripts to prevent future regressions of the charmap encoding bug on Windows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Format with black Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review comments: test production code paths, consolidate CHANGELOG Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Apply black formatting Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
singankit
pushed a commit
that referenced
this pull request
Mar 16, 2026
…45500) * Fix UTF-8 encoding for red team JSONL files on Windows Add explicit encoding='utf-8' to all file open() calls in the PyRIT result processing path. Without this, Windows defaults to the system locale encoding (charmap/cp1252), causing UnicodeDecodeError when reading JSONL files containing non-ASCII characters from UnicodeConfusable strategy or CJK languages. Fixes: Tests 1.7 (UnicodeConfusable), 1.16 (Japanese/Chinese) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add encoding regression tests for non-ASCII JSONL round-trip Test CJK characters, Unicode confusables, and mixed scripts to prevent future regressions of the charmap encoding bug on Windows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Format with black Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review comments: test production code paths, consolidate CHANGELOG Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Apply black formatting Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Add explicit encoding=utf-8 to all open() calls in the PyRIT result processing path for red team scans.
Why
On Windows, Python open() defaults to the system locale encoding (cp1252/charmap). When JSONL files contain non-ASCII characters (from UnicodeConfusable strategy or CJK language prompts), reading them back fails with UnicodeDecodeError. This causes 0 attack_details in final results.
What Changed
4 open() calls fixed across 2 files:
Testing
All 367 red team unit tests pass. Fixes bug bash tests 1.7 (UnicodeConfusable) and 1.16 (Japanese/Chinese).
Risk
None - the write side already produces UTF-8 content; this makes the read side match.