私の場合、最近irrKlangライブラリを選択しました。これにより、あまり多くの作業を行わずにオーディオファイルを操作できます。次に、ファイルパスのUnicode文字がライブラリでサポートされていないという問題が発生しました。それはそれを間違って読むか（間違って読んだとしても、それでもファイルを見つけることができると思っていたでしょう）、または単にそれを無視して、無効なファイルパスを残します。
これに対する解決策をサポートフォーラムで検索しましたが、私が得たのは「ユニコード？ええと、アスキーだけを使用しないのはなぜですか？」だけでした。ユニコードに対するある種の態度は珍しいことではないと思います。
UnicodeをサポートしていないライブラリにUnicode文字列を確実に渡すために使用できるいくつかの手法は何ですか？
簡単に言えば、バイト配列を使用してそれらを通過し、もう一方の端でユニコード配列として解釈し直すことができますが、ユニコードを実行しない場合は、ユニコードを実行しません。
ユニコード文字列を解釈できないライブラリに渡すことには意味がありません。
特定のことを行う必要がある場合（HFS +などのUnicodeパスを持つファイルシステムでloadコマンドを使用するなど）、実行しないでください。むしろ、システムが提供するファイルAPIを使用し、データを非協調ライブラリコンストラクターにプッシュします。
このUnicodeファイルパスビジネスで深刻な問題が発生している場合は、アドレスとビットストリームの受け渡しがうまく機能しないため、簡単な解決策は独自の関数を作成することです。
obj_ptr* loadObjFromUnicodePath(path)
{
//create tmp ASCII named symlink to file at arg(path).
//call load API of irrKlang on symlink.
//delete tmp symlink, return object.
}