dummy-decoy
commented
2 years ago Thanks for your remark.
Almost any language from western europe, except english uses extended ascii.
This software is specifically limited to this subset for 3 reasons:
- ascii(0) to ascii(31) are non-printable, except 3 keys which are hardcoded in the application, namely backspace (ascii(8)), tab (ascii(9)) and enter (ascii(10)). ascii(127) is non printable too (this one i guess i could map it properly)
- the flipper zero (which remains the target machine) at the moment does absolutely NOT support characters outside ascii(0) ascii(127). it is the way the badusb application has been designed. there may be plans to extend that range later, but it will require a more thoughtful work, see next point.
- ascii(128) to ascii(255) are not standardized and vary across countries. an "é" is not mapped to the same key depending on the system settings. before the advent of unicode, that part was called a code page. we could specifically require a known code page, but it would not work well on some middle eastern computer natively using another codepage. keep in mind that for extended ascii to work, we need support from the hid emulator inside flipper zero, but we also need to support it in the way we read the script .txt file. we could also specifically ask for script encoded in utf-8, but we would then have to support a far greater range of characters, which would require a complete rework of the badusb emulation part.
so, it is possible to support more ascii, but that's for later. let's already see how those mapping work with the current state of the device.
(for more information about extended ascii and the problems around supporting it, please have a look at https://en.wikipedia.org/wiki/Extended_ASCII )
This program is limited to "ascii(32) and ascii(126)"
In spanish we use some extended ASCCI