OneDriveのファイル名の重複チェック: BMP(基本多言語面)に収まらない文字・収まる文字

TL;DR

• Microsoft OneDriveは、ファイルの重複を判定する際、UNICODEのBMP(基本多言語面)に収まらない文字を無視する。
• Microsoft OneDriveは、BMPに収まる文字であっても、一部の文字を無視する。
• 上記で無視される文字の範囲は明確ではない。

はじめに - OneDriveでファイル名に使える文字

まず、Microsoft OneDrive(以下OneDrive)でファイル名・フォルダ名(以下まとめてファイル名)に使える文字列についてはMicrosoftの下記ドキュメントにまとまっています。

OneDrive と SharePoint の制限事項と制約事項

このドキュメントにより、

1. ファイルシステムで使う特殊な文字(" * : < > ? / \ |)はファイル名に使えない
2. .lock、CON等、Windowsのシステムで使う特殊な名称はファイル名に使えない

ことが分かります。
ではそれ以外に使える文字の範囲はどうなっているのでしょうか。

ドキュメントには特に記載はないですが、Windows+NTFSの環境と同様、UNICODEに入っている文字であれば、何でも使えるようです。
UNICODEのBMP(基本多言語面¹)に収まらない文字でも、ファイル名に使ったからといってエラーが出ることはありません。

例えば

• 「😭😭.txt」は問題なくファイル名に使えます²。(「😭」のコードポイントはBMPに収まらないU+1F62D。)
• 「葛󠄀飾.txt」も問題なくファイル名に使えます。(「葛󠄀」のコードポイントは異体字セレクタ³のついたU+845B U+E0100。)
• 「𩸶の焼き方.txt」も問題なくファイル名に使えます。(「𩸶」のコードポイントはBMPに収まらないU+29E36。)

問題の所在 - 不思議な共存不可現象

ところが、異なるファイル名のファイルであっても、ファイル名が「似ている」場合、OneDrive上の同一フォルダに両方のファイルを保存しようとした際にエラーが生じることがあります。

例えば、以下の画像の様に、ファイル名が違うのに「似た名前のファイルまたはフォルダーはすでに存在するため、・・・をアップロードできませんでした。」とのエラーが生じます⁴。(この例を論点①で扱います)

【図1: 「😫😫.txt」が存在するフォルダに「😭😭.txt」を保存しようとする。】

また、以下の画像の様に、絵文字が関連する場合だけでなく、「hoge㉚.txt」と「hoge㉛.txt」でも同じエラーが生じます。(この例を論点②で扱います。)

【図2: 「hoge㉚.txt」が存在するフォルダに「hoge㉛.txt」を保存しようとする。】

以下、2つのファイルを同じフォルダに保存できることを共存可、保存できないことを共存不可と呼びます。

論点① OneDriveは、BMPに収まらない文字をファイルの重複判定にあたっては無視する

OneDriveは、ファイルの重複を判定する際、絵文字や「𩸶」、異体字セレクタ等のBMPに収まらない文字を無視するようです。

これは以下の挙動から推測できます。

1. 「😭😭.txt」と「𩸶.txt」が共存不可。

⇛文字数が違うにもかかわらず同一名称のファイルと判定されるということは、「😭」(U+1F62D)と「𩸶」(U+29E36)がいずれも存在しないものとして比較していると推測できます。

2. 「𩸶の焼き方.txt」と「の焼き方.txt」が共存不可。

⇛ 「𩸶」(U+29E36)の有無だけが異なるファイル名が同一視されるということは、「𩸶」の文字が存在しないものとして比較していると推測できます。

これによって生じる問題を以下、敷衍します。

異体字の扱い - 異体字セレクタ(IVS)は無視される

異体字セレクタ(IVS, Ideographic Variation Sequence)は、UNICODEのコードポイントU+E0100〜U+E01EFに配置されており、いずれもBMPに収まらない文字です。

このため、OneDriveがファイル名の重複を判定する際には異体字セレクタは無視され、異体字セレクタの有無だけが異なるファイルは共存不可です。

【図3: 「葛󠄀飾.txt」が存在するフォルダに「葛飾.txt」を保存しようとする】

ポイントは、異体字セレクタ自体が認識されないわけではないということです。
異体字セレクタを用いたファイル名のファイルは問題なく保存できますし、保存しようとしてエラーが生じるのは、(異体字セレクタを使っていないファイル名(「葛飾」)であっても)後から保存した方のファイルです。

少なくともWindows 11 + NTFSの環境では、異体字セレクタの有無だけが異なるファイル名のファイルは共存できるので、WindowsからOneDriveにファイルを移動・コピーする際に上記の共存不可に遭遇する可能性があります。

【図4: Windows上では「葛󠄀飾.txt」と「葛飾.txt」は共存可】

絵文字の扱い - BMPに収まる絵文字と収まらない絵文字

先に述べたとおり、OneDriveではファイル名に絵文字も使えるのですが、BMPに収まらない文字を使った絵文字については以下のような共存不可が生じます。

共存不可の例

手元で試して観測できた共存不可の例は以下です。

1. "😭😭.txt"と"😫😫.txt"
2. "😭😭.txt"と"🦁🦁.txt"
3. "✌️✌️.txt"と"✌🏾✌🏾.txt"

共存可の例

手元で試して観測できた共存可の例は以下です。

4. "😭😭.txt"と"❤️❤️.txt"
5. "😭😭.txt"と"✌️✌️.txt"
6. "❤️❤️.txt"と"✌️✌️.txt"

絵文字についての考察

以上の例で触れたそれぞれの絵文字のコードポイントを確認すると以下のとおりです。
😭(U+1F62D)
😫(U+1F62B)
🦁(U+1F981)
✌️(U+270C)
✌🏾(U+270C U+1F3FC)
❤️(U+2764)

まず、3.の "✌️✌️.txt"と"✌🏾✌🏾.txt"が共存不可なことについては、後者では肌色を指定するU+1F3FCが用いられており、これがBMPに収まらないため無視され、結果として同一のファイル名だと判定されたと推測できます。

また、1.の"😭😭.txt"と"😫😫.txt"、2.の "😭😭.txt"と"🦁🦁.txt"が共存不可なことについては、いずれの文字もコードポイントがU+1xxxxとBMPに収まらない文字であることから、ファイル名の重複チェックにあたって無視されたと推測できます。(すなわち、3ファイルとも「.txt」という名称とみなされていると思われます。)

これに対し、6.の"❤️❤️.txt"と"✌️✌️.txt"は、どちらの文字もU+27xxとBMPに収まるコードポイントですので、正常に重複チェックが行われ、共存可なのだと推測できます。

すなわち、絵文字はBMPに収まる文字かどうかで扱いが異なり、不思議な挙動が生じた場合には(普段は意識しない) 絵文字のコードポイントを調べる必要があります⁵。

論点② OneDriveは、BMPに収まる文字でも、ファイルの重複判定にあたって一部の文字を無視する

以上の論点①で触れたBMPに収まらない文字については、①Windowsが採用しているUTF-16ではサロゲートペアという特殊な表現方法でないと表せない⁶、②MySQLでも設定を間違えるとおかしな挙動になる⁷等、歴史的経緯から問題を抱えがちなポイントとして認識されているかと思います。

これに対し、上記 【図2】 の"hoge㉚.txt"と"hoge㉛.txt"はいずれもBMPに収まる文字であるにもかかわらず、同じ問題が生じています。

㉚のコードポイントは U+325A、㉛のコードポイントは U+325Bで、どちらもU+FFFF以下のBMPに収まる文字です。

【図2(再掲): 「hoge㉚.txt」が存在するフォルダに「hoge㉛.txt」を保存しようとする。】

ここでも同様に試すと、

"hoge㉚.txt"と"hoge㉛.txt"が共存不可
"hoge㉚.txt"と"hoge.txt"が共存不可

という挙動が観測されたため(特に、2点目)、「㉚」や「㉛」の文字は、ファイルの重複判定にあたって無視されていると推測できます。

影響範囲の検討

ところが不思議なことに、「①」と「②」は 共存可なのです。

【図5: 「①」と「②」は 共存可】

①のコードポイントは U+2460、②のコードポイントは U+2461で、どちらもU+FFFF以下のBMPに収まる文字で、㉚や㉛とは少し離れたコードポイントです。

では何がこの挙動の違いを生んでいるのでしょうか。
以下で述べる方法で実験してみましたが、答えは明確ではなく、 一部の記号はOneDriveに保存する際は要注意 、とぐらいしか結論できませんでした。

実験方法

OneDriveのExplorer統合機能がアップロードに失敗しているかを簡単に取得する方法が見当たらないため⁸、以下の手順で実験しました。

1. 実験用フォルダに "_.txt" というファイルを用意する。
2. 同ファイルに "_[U+2000].txt" ～ "_[U+33FF].txt" まで、「アンダーバー＋連番のコードポイント1文字」のファイルを作成する(都合5120個のはず⁹)。
3. アップロードが終わるのを待ち、OneDriveのWebUIから、実験用フォルダの中身をまとめてダウンロードする。
4. ダウンロードしたzipファイルで欠けているファイルが"_.txt"と共存不可のファイルと分かる。

上記2.は以下のpowershellのワンライナーで簡単に作れました。

(0x2000..0x33FF)|%{Set-Content -LiteralPath "_$([char]$_).txt" -value "hoge"

そのあと、3.でダウンロードしたzipファイルと元のフォルダの中身のdiffを取ると、2922ファイルが共存不可のファイルでした。
⇛ 下記のとおり、正確に検証できていないようなので再検討します。

考察

正直、共存不可の基準はなんとも分かりづらいです。
例えば、丸数字は「①」～「⑳」 (U+2460～U+2473) は共存可でしたが、「㉑」(U+3251) より大きい数字のものは共存不可でした。
ところが、「㉑」のすぐ近くにある来る「㋕」(U+32D5) は共存可でした。

実験結果については、OneDriveのWebUIからは作成できるファイル名でもアップロードされていない場合があり、正確に検証できていなさそうです。

1. 平たく言うとUNICODEのコードポイントがU+0000～U+FFFFの範囲の文字。 ↩

2. ただしWin11でもExplorerはカラー絵文字に対応していないので見づらいかもしれません。ブラウザやWindowsTerminalからみる分にはちゃんとカラー絵文字で見えます。 ↩

3. (詳細は略) ↩

4. 下の方ポップアップにある「両方残す」を押下するとファイルがリネームされて保存されます。 ↩

5. 少なくとも私はこの記事を執筆するまで、"✌️"もBMPに収まらないと思っていました。 ↩

6. 逆に言えばWindowsのExplorer等はこのサロゲートペアに対応してくれています。 ↩

7. 🍣🍺問題(寿司ビール問題)。https://qiita.com/kamohicokamo/items/3cc05f63a90148525caf ↩

8. ログファイルの解析も考えましたが簡単ではなさそうでした。https://forensics.wiki/microsoft_onedrive/ あたりが参考になりそうですが…。 ↩

9. 実際は4973ファイルしか作成されませんでした。一部の制御文字はWindowsがファイル名にいれることを拒んでいるのでしょうか。 ↩