Decode UTF-16 .env files on variable import

[levivannoort]

What does this PR do?

File.text() always decodes UTF-8, but .env files written on Windows are often UTF-16 -- PowerShell's > redirect defaults to it. Decoded as UTF-8, every character gains an interleaved NUL byte, so importing such a file stored keys with a NUL after every letter -- an invalid environment variable name that invalidated the Kubernetes build job manifest and failed every subsequent deployment for that resource (this is the origin of a production incident on cloud).

This adds readEnvFile() to $lib/helpers/envfile: it detects UTF-16 by BOM (FF FE / FE FF), or by the interleaved-NUL byte pattern when the BOM is missing, and decodes with the right TextDecoder. Both import modals (importVariablesModal, uploadVariablesModal) now use it instead of File.text() -- so a PowerShell-authored .env simply imports correctly instead of erroring on every key.

Test plan

src/lib/helpers/envfile.test.ts -- 7 cases: UTF-8 (with/without BOM), UTF-16LE/BE (with/without BOM), and UTF-8 containing a genuine stray NUL staying UTF-8. All passing; lint clean.

Related PRs and Issues

• Server-side guard refusing invalid keys at the endpoints and before build job submission: Refuse variable keys that are invalid env var names appwrite#13362

[appwrite]

Console (appwrite/console)

Project ID: 688b7bf400350cbd60e9

Sites (1)

Site	Status	Logs	Preview	QR
console-stage 688b7cf6003b1842c9dc	Ready	View Logs	Preview URL

Tip

HTTPS and SSL certificates are handled automatically for all your Sites

[greptile-apps]

Greptile Summary

Adds encoding-aware reading for uploaded .env files so the variable import flows can decode UTF-8 and UTF-16 input.

• Detects UTF-16LE and UTF-16BE from byte-order marks or an interleaved-NUL heuristic.
• Uses the shared decoder in both variable import modals.
• Adds tests for UTF-8, BOM-marked UTF-16, BOM-less ASCII UTF-16, and stray UTF-8 NUL bytes.

Confidence Score: 4/5

The PR does not appear safe to merge until BOM-less UTF-16 files with Unicode-heavy content are decoded correctly.

The previously reported failure remains: the file-wide 70% NUL threshold misses realistic BOM-less UTF-16 files containing substantial Unicode text, after which existing validation rejects the NUL-interleaved variable names.

Files Needing Attention: src/lib/helpers/envfile.ts, src/lib/helpers/envfile.test.ts

Important Files Changed

Filename	Overview
src/lib/helpers/envfile.ts	Adds UTF-16 detection and decoding, but the BOM-less heuristic still fails for files with sufficiently Unicode-heavy values or comments.
src/lib/helpers/envfile.test.ts	Covers the primary encoding variants but does not exercise BOM-less UTF-16 containing enough non-ASCII code units to cross the heuristic threshold.
src/lib/components/variables/importVariablesModal.svelte	Routes uploaded files through the new encoding-aware helper before existing parsing and validation.
src/routes/(console)/project-[region]-[project]/uploadVariablesModal.svelte	Applies the same encoding-aware read path to project-level variable uploads.

_{Reviews (2): Last reviewed commit: "test: build UTF-16 fixtures as ArrayBuff..." | Re-trigger Greptile}

[greptile-apps]

UTF-16 heuristic misses Unicode

When a BOM-less UTF-16 file contains at least 30% non-ASCII code units in its values or comments, the file-wide NUL ratio falls below this threshold and readEnvFile decodes it as UTF-8. This leaves interleaved NULs in ASCII keys, causing variable validation to reject the entire import.