If someone cares, here is the workaround I've implemented.
Read /etc/exports on root volume thru file-read-file API.
Remove entries starting with #.
I assume the file match the currently load rules. In the worst case some path might not exist anymore. Armless for me.
Analyse each path to check if it's UTF-8 encoded or not (obviously, UTF-8 volumes need UTF-8 encoded export path to work, and non-UTF-8 volumes need non-UTF-8 export path).
Keep the information in an array or hash.
If no such non-UTF-8 path has been found, don't do anything specia. You can call nfs-exportfs-rules-list-2.
Sure, if someone has manually exported a non-UTF-8 path, You've lost !
If there is some non-UTF-8 path.
Activate the "NA_PRINT_DONT_PARSE" debug option.
Duplicate STDOUT to some other file descriptor (to avoid debug output).
Call nfs-exportfs-rules-list-2 but don't care about the exit code because of course it will not be OK !
Restore standard STDOUT (if you need it later).
Get the XML raw output from $session->{xml}
DON'T blindly convert the whole XML data to UTF-8 with encode perl function. Because if you do that and have some path with true UTF-8 chars (for other volumes), as they use prefix bytes they will be converted again. So you'll fix a problem but create another one.
For each non-UTF-8 path detected previously, do a search/replace work in the XML data to replace those path with their UTF-8 version.
Now the XML data is really UTF-8 compliant, we can do manually what invoke should have done at the very end:
$inv = $session->parse_xml($XML, '<nfs-exportfs-list-rules-2></nfs-exportfs-list-rules-2>');
This solution applies for calling nfs-exportfs-list-rules-2 with no option to get all the information in one shot.
It's also possible to call it for each exported path as an arg, and then determine easily if the workaround is needed or not for each path.
But I see no benefit for it if you need all the information.
It works for me. but I don't expect it to be bulletproof...
