Repository navigation
UTF Characters for relative path #27534
Description
Activity
- changed the title
[-]UTF Character for relative path[/-][+]UTF Characters for relative path[/+]on May 2, 2019 The problem here is that
path.relativecomputes everything using the lowercase versions of the paths but returns the result using the original case.
"İ"has one char code while"İ".toLowerCase()has two.There's an easy fix for this case:
console.log(path.win32.relative('c:\\a\\İ', 'c:\\a\\İ\\test.txt')); // est.txt
diff --git a/lib/path.js b/lib/path.js index 2301a6ebb8..e76513f0f3 100644 --- a/lib/path.js +++ b/lib/path.js @@ -499,7 +499,7 @@ const win32 = { if (to.charCodeAt(toStart + i) === CHAR_BACKWARD_SLASH) { // We get here if `from` is the exact base path for `to`. // For example: from='C:\\foo\\bar'; to='C:\\foo\\bar\\baz' - return toOrig.slice(toStart + i + 1); + return toOrig.slice(toStart + i + 1 - from.length + fromOrig.length); } if (i === 2) { // We get here if `from` is the device root.
console.log(path.win32.relative('c:\\a\\İ', 'c:\\a\\İ\\test.txt')); // test.txt
However this case is trickier:
console.log(path.win32.relative('c:\\İ\\a\\İ', 'c:\\İ\\b\\İ\\test.txt')); // ..\..b\İ\test.txt
Reacted by BorisThis should be easy to fix: instead of using the lower cased variation it's possible to use the upper case one. These two ways do not work identical and the upper case variation does not show the negative sides as the lower case. I am compiling right now to see if that works as expected.
> console.log(path.win32.relative('c:\\a\\İ', 'c:\\a\\İ\\test.txt')); test.txt > console.log(path.win32.relative('c:\\İ\\a\\İ', 'c:\\İ\\b\\İ\\test.txt')); ..\..\b\İ\test.txtSorry ^. That's not the example I meant. Isn't there the same risk with
toUpperCasebut with other characters?@targos
ßis converted toSSwhen usingtoUpperCase, so it has a similar problem like the initial issue. Unicode is pretty ugly and we have problems with Turkish, German and likely more. There is thetoLocaleLowerCase()function and it should work for all cases.@mathiasbynens PTAL.
I'm afraid the behavior of
toLocaleLowerCase()depends on the user's locale.@targos yes, that's correct. As far as I know a device name may also contain unicode characters and if that's the case also
path.win32.resolve()would fail (and likely more).I have to think about this a bit closer when I find to do so. We probably also have issues even without changing the casing since we expect characters to always have a length of 1. This is mostly not an issue, since we almost always just check for slashes and take everything in-between but we expect the device root to always be of length 2.
- added a commit that references this issue
on May 12, 2019 - added a commit that references this issue
on Jul 7, 2020 This is still an issue that can lead to bugs in August 2021. Any news?
Version: 10.15.3
Platform: Windows 64bit
Subsystem: "path" module
Expected result:
test.txtActual result:
est.txt