HaxeFoundation / HaxeFoundation/haxe
php codegen when using double byte chatecters in object string
- Dominant language
- Haxe
- Stars
- 6.9k
- Forks
- 715
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 11
Description
I am using this haxe code
```haxe
function main() {
Sys.println("אבגדהו");
var list={
"אבגדהו":"abcd",
"אבדהו":"abcd",
}
trace(list);
}
```
In the first print, the Hebrew characters are copied directly to the resulting php file.
However for the object keys, they are trying to get escaped, but the algorithm is not good.
א
in utf8 is D7 90
this is 215 144 in decimal
PHP would interpret backslash escape as octal, but the Haxe generator inserts the decimal values instead.
The result is that the characters render as gibberish.
It would need any of the follwing
1. leave the original text (php supports inline utf8)
2. use octal values
3. escape with haxedecimal escaping
I tried to navigate the php7 gen file, but was unsuccesfull in finding the cause.
In control charecters less then ASCII 32, the generator is using haxedecimal escaping such as \x0A which is good.
generates the follwing php
```php
"abcd",
"\215\144\215\145\215\147\215\148\215\149" => "abcd",
]);
#TestPhp.hx:7: characters 5-10
(Log::$trace)($list, new HxAnon([
"fileName" => "TestPhp.hx",
"lineNumber" => 7,
"className" => "_TestPhp.TestPhp_Fields_",
"methodName" => "main",
]));
}
}
Boot::registerClass(TestPhp_Fields_::class, '_TestPhp.TestPhp_Fields_');
```
Contributor guide
Research direction
Reproduce the shown Haxe-to-PHP output and inspect the php7 generator's escaping path for object keys, contrasting it with the handling of inline UTF-8 strings and control characters. Done means Hebrew object keys produce valid PHP text without gibberish while existing control-character escaping remains correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 40/100