fix(staging): write LabelBox staging text files as UTF-8 - #4456
Open
Anai-Guo wants to merge 1 commit into
Open
Conversation
stage_for_label_box() opened each <external-id>.txt file in text mode with no explicit encoding, so element text was encoded with the platform's locale codec. Text outside that codec raises UnicodeEncodeError (cp1252 on Windows, ASCII under a POSIX/C locale in a container); where it does not raise, the file is written in the locale encoding while LabelBox reads it as UTF-8. Every other open() in unstructured/staging/ already passes an explicit encoding.
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.
Summary
stage_for_label_box()writes each element's text to<external-id>.txtin text mode with no explicit encoding, so the bytes are produced with the platform's locale codec:https://github.com/Unstructured-IO/unstructured/blob/main/unstructured/staging/label_box.py#L85
Two consequences:
cp1252on Windows, or ASCII when the process runs under aPOSIX/Clocale (common in containers). Any non-Latin-1 document (CJK, Greek, an em dash) aborts staging.Every other
open()inunstructured/staging/already passes an explicit encoding — the six inunstructured/staging/base.py(elements_from_json,elements_to_json,convert_to_csv/dataframe,elements_to_md, …) all take anencodingargument and forward it.label_box.pyis the only one that does not.Reproduction
On any interpreter whose
locale.getpreferredencoding(False)is not UTF-8 (here Windows /cp1252, Python 3.12):Fix
One line — pass
encoding="utf-8", matching the sibling serializers and what LabelBox expects on the other end.Tests
test_stage_for_label_box_writes_text_files_as_utf8stages an element containing an em dash, CJK and an accented character, then asserts both that the staged bytes decode as UTF-8 and that the text-modeopen()was given an explicitutf-8. The second assertion is what makes the test fail on a UTF-8 platform too, where the old code happens to produce the right bytes.1 failed, 13 passed(fails at the write oncp1252; fails on the encoding assertion under a UTF-8 locale)14 passedThe pre-existing
test_stage_for_label_boxread the staged file back with a bareopen()as well; that read is now explicit too, so the assertion does not depend on the runner's locale.ruff check/ruff format --checkclean on both files, andscripts/version-sync.sh -cpasses for the0.27.3bump.Not included
The remaining locale-dependent
open()calls in the package live underunstructured/metrics/(evaluation tooling reading prediction/ground-truth JSON and.txtfiles). They are the same class of defect but a separate surface — happy to send a follow-up if you want them covered.🤖 Generated with Claude Code