However, I do not think the current thread title fully represents the nature of the issue. In my view, the underlying problem is not specific to Japanese voiced sound marks, but rather Unicode filename normalization interoperability between macOS and Windows.
This issue still exists in current versions of macOS and Box Drive in 2026, and it causes interoperability problems when Box is used collaboratively between macOS and Windows.
I investigated the behavior and found that the issue can be reproduced as follows:
* Creating a file or folder in Finder on the macOS Desktop results in a decomposed (NFD) filename.
* Creating a file or folder in Finder inside Box Drive also results in an NFD filename.
* Creating the same filename from a Unix command-line tool in Terminal on the macOS Desktop preserves the NFC filename.
* Creating the same filename from Terminal directly inside Box Drive also preserves the NFC filename.
* Renaming an existing NFC filename in Finder changes the filename to NFD.
These results indicate that Box Drive itself is not converting NFC filenames to NFD. Rather, Finder generates decomposed filenames, and Box Drive uploads those filenames to Box without normalizing them.
Modern APFS does not normalize filenames when they are created; it can preserve either NFC or NFD filenames. Therefore, this is not simply an HFS+ filesystem issue. Finder still generates decomposed filenames, while many Unix-derived command-line tools preserve the supplied Unicode representation.
This creates a cross-platform interoperability problem in Box. macOS itself can generally handle canonically equivalent filenames transparently, but once an NFD filename created by Finder is uploaded to Box, the decomposed filename is exposed to Windows and other platforms.
This is not limited in principle to Japanese voiced and semi-voiced characters; Unicode normalization differences can affect other characters and languages as well.
Because Box is a cross-platform content management and collaboration service, I believe Box Drive for macOS is an appropriate layer at which to resolve this incompatibility.
I therefore request that Box Drive for macOS provide an option to normalize newly created or renamed file and folder names to Unicode NFC before sending their names to the Box service.
Ideally, this should apply when a new Box item name is created through Box Drive, including:
* new files and folders;
* renamed files and folders; and
* new items created by copying files or folders in Finder.
Existing Box items should not need to be renamed merely because their contents are edited.
This request was originally submitted in 2020, and the interoperability issue is still reproducible more than six years later. I would appreciate it if Box could reconsider adding NFC normalization support to Box Drive for macOS.
KIPR
I strongly support this request.
However, I do not think the current thread title fully represents the nature of the issue. In my view, the underlying problem is not specific to Japanese voiced sound marks, but rather Unicode filename normalization interoperability between macOS and Windows.
This issue still exists in current versions of macOS and Box Drive in 2026, and it causes interoperability problems when Box is used collaboratively between macOS and Windows.
I investigated the behavior and found that the issue can be reproduced as follows:
* Creating a file or folder in Finder on the macOS Desktop results in a decomposed (NFD) filename.
* Creating a file or folder in Finder inside Box Drive also results in an NFD filename.
* Creating the same filename from a Unix command-line tool in Terminal on the macOS Desktop preserves the NFC filename.
* Creating the same filename from Terminal directly inside Box Drive also preserves the NFC filename.
* Renaming an existing NFC filename in Finder changes the filename to NFD.
These results indicate that Box Drive itself is not converting NFC filenames to NFD. Rather, Finder generates decomposed filenames, and Box Drive uploads those filenames to Box without normalizing them.
Modern APFS does not normalize filenames when they are created; it can preserve either NFC or NFD filenames. Therefore, this is not simply an HFS+ filesystem issue. Finder still generates decomposed filenames, while many Unix-derived command-line tools preserve the supplied Unicode representation.
This creates a cross-platform interoperability problem in Box. macOS itself can generally handle canonically equivalent filenames transparently, but once an NFD filename created by Finder is uploaded to Box, the decomposed filename is exposed to Windows and other platforms.
For example, the Japanese katakana character:
ダ
may be uploaded as two Unicode code points:
U+30BF (タ) + U+3099 (゛; COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK)
instead of the NFC representation:
U+30C0 (ダ)
This is not limited in principle to Japanese voiced and semi-voiced characters; Unicode normalization differences can affect other characters and languages as well.
Because Box is a cross-platform content management and collaboration service, I believe Box Drive for macOS is an appropriate layer at which to resolve this incompatibility.
I therefore request that Box Drive for macOS provide an option to normalize newly created or renamed file and folder names to Unicode NFC before sending their names to the Box service.
Ideally, this should apply when a new Box item name is created through Box Drive, including:
* new files and folders;
* renamed files and folders; and
* new items created by copying files or folders in Finder.
Existing Box items should not need to be renamed merely because their contents are edited.
This request was originally submitted in 2020, and the interoperability issue is still reproducible more than six years later. I would appreciate it if Box could reconsider adding NFC normalization support to Box Drive for macOS.