File names with emoji not shown over SMB connections
Posted: 25 Jan 2021 21:51
Hello, I think I came across a charset bug in VLC for iOS. As explained on https://wiki.videolan.org/Report_bugs/, I'm posting here before adding this to the tracker, in case anyone wants to confirm it first.
I found that when accessing a SMB share, any files containing an emoji is simply not shown in the list. It's still playable just, except the file name will not show up in the player view either.
I have these files in a subdirectory of a SMB share:
(For the record: this is a random selection of videos marked as creative commons on YouTube)
Yet VLC shows this when accessed via SMB:
Notice how the files that contain an actual emoji are completely skipped, whereas the file with a "standard" Unicode heart (♥) is shown correctly.
For reference, here are the code points of these specific characters:
[*] GROWING HEART - U+1F497
[*] CLAPPER BOARD - U+1F3AC
[*] BLACK HEART SUIT - U+2665
In other tests, I have confirmed that anything in the emoji block (U+1F600..U+1F64F) triggers the bug, while other Unicode characters seem safe.
For the sake of completeness, accessing the same server and directory via FTP results in garbled UTF-8 characters (regardless of the "Text encoding for FTP Connection" settings; I tried both ISO-8859-1 and UTF-8), but doesn't completely choke on parsing like it does via SMB:
Using VLC for iOS version 3.2.113 (375), based on 3.0.11.1 Vetinari, on iOS 14.3 on an iPhone 11.
The SMB server is on a QNAP NAS and reports these attributes:
Please let me know if I should add this to the bug tracker, or if there's any other test I should perform.
I found that when accessing a SMB share, any files containing an emoji is simply not shown in the list. It's still playable just, except the file name will not show up in the player view either.
I have these files in a subdirectory of a SMB share:
Code: Select all
ytsejam:/Volumes/home/vlc-test jollino$ ls
'Riffs' - Royalty Free Progressive Rock by Alexander Nakarada-bKixED0MCWM.mkv
Dragon Models 1_72 Saturn V Rocket Complete Build-YejTdQMZ6GM.mkv
Friendly Capabara - Cute Compilation-YfPYtaPCCWA.mkv
Funny & FAT Animals 🎬 What If Animals Were Round-tyx7UL-Uolw.mkv
Progressive Rock _ Art Rock Mix-pkGUQOOGVZU.webm
WAKE UP WITH ME & RED LIP MAKEUP ROUTINE _ MsRosieBea-iLVS2JhX7xw.mkv
💗Cute And Funny Pets _ Try Not To Laugh To These Pets Compilation #7💗 Cutest Lands-EgZu9kTFA_k.webm
♥♥ Kilimanjaro Safaris at Walt Disney World's Animal Kingdom (in HD)-gpdwDVfKJF0.mkvYet VLC shows this when accessed via SMB:
Notice how the files that contain an actual emoji are completely skipped, whereas the file with a "standard" Unicode heart (♥) is shown correctly.
For reference, here are the code points of these specific characters:
[*] GROWING HEART - U+1F497
[*] CLAPPER BOARD - U+1F3AC
[*] BLACK HEART SUIT - U+2665
In other tests, I have confirmed that anything in the emoji block (U+1F600..U+1F64F) triggers the bug, while other Unicode characters seem safe.
For the sake of completeness, accessing the same server and directory via FTP results in garbled UTF-8 characters (regardless of the "Text encoding for FTP Connection" settings; I tried both ISO-8859-1 and UTF-8), but doesn't completely choke on parsing like it does via SMB:
Using VLC for iOS version 3.2.113 (375), based on 3.0.11.1 Vetinari, on iOS 14.3 on an iPhone 11.
The SMB server is on a QNAP NAS and reports these attributes:
Code: Select all
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
home
SERVER_NAME ...
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.02
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
FILE_LEASING_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE