Open karliss opened 2 years ago
@karliss Rizin supports all important modern encodings:
There might be some API adjustments required but nothing particularly big for this feature. Unless, by "custom encoding," you meant completely custom, non-standard one.
Yes I was partially thinking about completely custom ones. The PR I was thinking about was done by a beginner so things weren't going very smoothly. Although with regards to this issue it's not strictly required.
rizin potentially only supporting "important modern encodings" was what I was referring in second paragraph of additional context. Qt also supports all "important modern ecodings". Potentially more than rizin, https://doc.qt.io/qt-6/qtextcodec.html . And if Qt provides more stuff with easeir to use interface it might not be worth using the rizin functions for that. But that needs to be properly evaluated once someone starts working on this issue.
Qt also supports all "important modern encodings." Potentially more than rizin
I agree. The thing is, if we provide some core feature in Cutter, it should be in Rizin as well, it's the core framework, after all. Thus, if some important encoding is missing in Rizin - it's a bug in Rizin, and ideally should be resolved by improving it, making it available both in Cutter and Rizin, from command line, visual modes, and as library APIs.
Is your feature request related to a problem? Please describe.
Currently the hexwidget text column isn't very helpful for non ASCII text. Even for English text, many programming environments use a variation of utf16 like 2byte encoding. There are also various historical executable formats which might be using platform specific 8 bit encodings.
Describe the solution you'd like
Option to select what text encoding gets used for the hexwidget text column.
Describe alternatives you've considered
Additional context
I remember that at some point there was at least attempt at adding something like that to r(2|z). Not sure if it was ever finished. If it was it would be good to support any any custom encodings defined within rizin.
If the rizin text encoding feature isn't finished it will probably more convenient to do the decoding using functionality provided by Qt.
Dealing with non 8 bit text encodings might be tricky. How to choose starting point? Address aligned? Some kind of heuristics? I guess something like UTF8 in most cases would quickly converge to correct offsets.