JNI: NewStringUTF (modified UTF-8) mangles astral-plane chars — emoji alphabet text is corrupted in transit
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- internationalization, mobile
Direzione di ricerca
Start in jni_bridge.cpp: run a search for NewStringUTF and GetStringUTFChars, and check the output callback near line 189 first. The fix is to build engine-to-Kotlin strings from UTF-16 with NewString and to handle the Kotlin-to-engine direction the same way. Done when an emoji from the engine arrives intact in Kotlin, and a round-trip test with an astral-plane character passes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Follow-up from the #71 review loop (review M3, pre-existing).
jni_bridge.cpp uses env->NewStringUTF(...) for engine→Kotlin strings (e.g. output callback text at jni_bridge.cpp:189 and friends). JNI's NewStringUTF expects modified UTF-8 (CESU-8): 4-byte UTF-8 sequences — every astral-plane codepoint, i.e. most emoji — are invalid and get mangled. Since c003214 the app ships an Emoji alphabet, so astral chars are a live output path: the engine emits correct UTF-8, the Kotlin side receives garbage.
(The UTF-16-level coalescing contract added in #71 is correct at the Kotlin layer — ImeOutputCoalescerTest pins it — but the runtime path through JNI corrupts the string before Kotlin sees it.)
Fix pattern: decode UTF-8 → UTF-16 manually (or via String::fromUTF8 helpers) and construct with env->NewString(utf16, len). Audit every NewStringUTF in jni_bridge.cpp; also check the reverse direction (GetStringUTFChars — same modified-UTF-8 caveat) for Kotlin→engine strings (training import, seedBuffer).
Split out of #71 to keep that PR scoped to the batching fix.
- Lingua principale
- Kotlin
- Stelle
- 2
- Fork
- 0
- Merge medio
- 4h 45m
- PR unite (30g)
- 7
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dasher-project/Dasher-Android
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
-
UX: IME needs editing tools (backspace, cursor movement) — 'I go back and forth with SwiftKey'Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 42/100
-
bug
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
dasher-project/Dasher-Android#34 · 1 commento ·
Tutte le issue di dasher-project/Dasher-Android
Issue simili
-
[Bug] Web Player: Misalignment in lyrics toolbar with format dropdown ('Auto') and download iconAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
kushagrasinghx/BitChord#1269 ·
I maintainer di solito rispondono entro 1 giorno
-
[📚] migrating-to-v27: Android fails on Expo SDK 58 (Kotlin 2.2) — document the BoM 34.19.0 overrideAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
invertase/react-native-firebase#9418 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
react/react-native#59693 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Keep a caller-supplied `screen` entity instead of attaching the tracker’s current screenForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100