Проблема с обработкой длины пути

Question

Я создаю библиотеку, которая будет использоваться для манипулирования файлами, как в Linux, так и в Windows.Так что мне нужно обрабатывать пути, основные требования - чтобы мои функции получали строки в формате UTF8.Но это вызывает некоторые проблемы, одна из которых я использую MAX_PATH в Windows и PATH_MAX в Linux, чтобы представлять статические переменные пути.В случае символов ASCII проблем не будет, но когда путь содержит символы Юникода, длина пути будет в два раза короче, если символ Юникод требует 2 байта на символ, в 3 раза короче, если символ Юникод требует 3 байта на символ и т. Д.,Так есть ли хорошее решение для этой проблемы?

Заранее спасибо!

ps извините за мой английский.

Answer 1

По крайней мере, в Linux ваше беспокойство кажется неуместным. Linux (и POSIX в целом) трактуют пути как непрозрачный блок байтов, оканчивающийся на «\ 0». Это не касается того, как эти байты переводятся в символы. То есть PATH_MAX указывает максимальную длину имени пути в байтах, а не в символах.

Таким образом, если имена путей содержат> = 0 многобайтовых символов UTF-8, то это просто означает, что максимальная длина пути в символах равна <= PATH_MAX. </p>

Answer 2

Это полностью зависит от того, что вам нужно.

Если вы хотите, чтобы число MAX_PATH байтов , вы просто определяете буфер как char name[MAX_PATH].Если вам нужно MAX_PATH количество символов , вы определяете буфер как char name[MAX_PATH * 4], так как UTF-8 кодирует каждый символ Unicode как переменное число от 1 до 4 октетов.

Одним словом, как указывает Джаннеб, MAX_PATH (or PATH_MAX) указывает количество нижележащих байтов вместо символов.

Answer 3

UTF-8 - это формат многобайтовой кодировки в диапазоне от 1 до 4 байтов на символ.Поскольку вы хотите статически определить максимальное значение пути, вам может потребоваться определить максимальный путь как n*4 (где n - длина пути в символах ASCII, которые вы хотите определить) для размещения символов в кодировке UTF-8.

Answer 4

Разве Microsoft не использует ни UCS-2, ни UTF-16 для своих путей, и поэтому MAX_PATH имеет длину, которая отражает 16-битные единицы кода , даже не правильные символы?

Я знаю, что Apple использует UTF-16, и что каждый компонент в имени пути может содержать до 256 UTF-16 кодовых единиц , а не символов, и что он нормализовался к чему-то, приближающемуся к NFD в течение длительного времени тому назад.

Я подозреваю, что вам придется сначала при необходимости нормализовать, например, NFD для Apple, затем кодировать во внутренний формат вашей родной файловой системы, а затем проверить длину.

Когда вы делаете это сравнение, важно помнить, что Unix использует 8-битные кодовые единицы, Microsoft и Apple используют 16-битные кодовые блоки, и что никто, кажется, даже не удосуживается использовать абстрактные символы. Они могли бы сделать это, если бы использовали UTF-32, но никто не тратит так много места в файловой системе. Жаль, что.