Сообщение Re[16]: Убунта от 19.12.2019 18:57
Изменено 19.12.2019 19:04 netch80
Re[16]: Убунта
Здравствуйте, Sinclair, Вы писали:
N>>Это абсолютно ничего не говорит без контекста, в каком применяются подобные решения.
N>>Например, "большая тройка" в описанном понимании означает задачи, близкие к таким, как финансы, базы данных людей и т.п. — и мы (кажется) не имеем ни одного языка, в котором был бы регистр букв и при этом он был бы значим для различения имён. Отсюда и тяга к подобным настройкам.
S>Скорее всего да.
OK.
N>>С другой стороны, если у тебя поле, которое не имеет такой специфики, вероятно, что для него подобные настройки уже будут неадекватны. Например, возьми URL чего-то на ютубе. Ты поменяешь регистр одной буквы после v= — и оно уже не работает. Там скорее можно заменить g на %67, чем на G. Поменяешь v= на V= — всё, не открывает. Могли сделать идентификаторы и названия параметров регистронезависимыми? Могли.
S>Тогда мы не смогли бы кодировать бинарные параметры в base64.
Если бы это было критично, кодировали бы в base32, base36, base40 (знаменитый вариант которого зовётся RADIX-50) и так далее, в зависимости от требований по уникальности вида символов и разрешения дополнительных знаков в наборе.
N>>Например, классическая IETFʼовая грамматизьма, включая центральные стандарты вроде RFC 822, 2616, 3261, игнорирует регистр везде, где может.
S>Она проектировалась быть человеко-читаемой.
А получилось "слегка" наоборот. Полная читаемость всё равно не достижима — из-за ряда хохм типа: quoted string по умолчанию CS, а токены — CI; теги типа CI, а по факту есть масса участников, что их считают CS; грамматика такая, что сбивает логику — например, в записи типа "en;q=0.9,ru;q=0.8" запятая, в нарушение привычной логики, приоритетнее точки с запятой; хохмы типа URI params vs. address params (в SIP); и прочая и прочая.
И на самом деле терминология в принципе неправильная: игнорирование регистра не даёт человеко-читаемость. Читать, сравнивать на известные последовательности символов, писать их — не мешает. CI даёт человеко-озвучиваемость. А насколько она вообще важна в подобных случаях?
N>>Главное в этой проблеме — что то, что выглядит по-разному, должно по умолчанию и восприниматься по-разному, и наоборот.
N>>И регистр в этом одна частная проблема. Например, есть À, À, А̀, Ὰ — ты видишь в своём браузере разницу?
S>Я — да, вижу.
N>>А драйвер FS воспримет их одинаково или по-разному?
S>Смотря какой драйвер. И смотря как он настроен.
Да по-моему сейчас нет таких, которые бы умели это понимать толком.
N>>А их различать важнее, чем A против a, они вообще совпадут у большинства.
S>Ага, это тоже элемент collation — будет ли он accent-sensitive.
При чём тут accent (in)sensitivity? У меня из 4 в примере было 2 латинских A, одна кириллическая и одна греческая. Accent insensitivity помогло бы разве что первые два сравнять, которые composed и decomposed.
N>>Это абсолютно ничего не говорит без контекста, в каком применяются подобные решения.
N>>Например, "большая тройка" в описанном понимании означает задачи, близкие к таким, как финансы, базы данных людей и т.п. — и мы (кажется) не имеем ни одного языка, в котором был бы регистр букв и при этом он был бы значим для различения имён. Отсюда и тяга к подобным настройкам.
S>Скорее всего да.
OK.
N>>С другой стороны, если у тебя поле, которое не имеет такой специфики, вероятно, что для него подобные настройки уже будут неадекватны. Например, возьми URL чего-то на ютубе. Ты поменяешь регистр одной буквы после v= — и оно уже не работает. Там скорее можно заменить g на %67, чем на G. Поменяешь v= на V= — всё, не открывает. Могли сделать идентификаторы и названия параметров регистронезависимыми? Могли.
S>Тогда мы не смогли бы кодировать бинарные параметры в base64.
Если бы это было критично, кодировали бы в base32, base36, base40 (знаменитый вариант которого зовётся RADIX-50) и так далее, в зависимости от требований по уникальности вида символов и разрешения дополнительных знаков в наборе.
N>>Например, классическая IETFʼовая грамматизьма, включая центральные стандарты вроде RFC 822, 2616, 3261, игнорирует регистр везде, где может.
S>Она проектировалась быть человеко-читаемой.
А получилось "слегка" наоборот. Полная читаемость всё равно не достижима — из-за ряда хохм типа: quoted string по умолчанию CS, а токены — CI; теги типа CI, а по факту есть масса участников, что их считают CS; грамматика такая, что сбивает логику — например, в записи типа "en;q=0.9,ru;q=0.8" запятая, в нарушение привычной логики, приоритетнее точки с запятой; хохмы типа URI params vs. address params (в SIP); и прочая и прочая.
И на самом деле терминология в принципе неправильная: игнорирование регистра не даёт человеко-читаемость. Читать, сравнивать на известные последовательности символов, писать их — не мешает. CI даёт человеко-озвучиваемость. А насколько она вообще важна в подобных случаях?
N>>Главное в этой проблеме — что то, что выглядит по-разному, должно по умолчанию и восприниматься по-разному, и наоборот.
N>>И регистр в этом одна частная проблема. Например, есть À, À, А̀, Ὰ — ты видишь в своём браузере разницу?
S>Я — да, вижу.
N>>А драйвер FS воспримет их одинаково или по-разному?
S>Смотря какой драйвер. И смотря как он настроен.
Да по-моему сейчас нет таких, которые бы умели это понимать толком.
N>>А их различать важнее, чем A против a, они вообще совпадут у большинства.
S>Ага, это тоже элемент collation — будет ли он accent-sensitive.
При чём тут accent (in)sensitivity? У меня из 4 в примере было 2 латинских A, одна кириллическая и одна греческая. Accent insensitivity помогло бы разве что первые два сравнять, которые composed и decomposed.
Re[16]: Убунта
Здравствуйте, Sinclair, Вы писали:
N>>Это абсолютно ничего не говорит без контекста, в каком применяются подобные решения.
N>>Например, "большая тройка" в описанном понимании означает задачи, близкие к таким, как финансы, базы данных людей и т.п. — и мы (кажется) не имеем ни одного языка, в котором был бы регистр букв и при этом он был бы значим для различения имён. Отсюда и тяга к подобным настройкам.
S>Скорее всего да.
OK.
N>>С другой стороны, если у тебя поле, которое не имеет такой специфики, вероятно, что для него подобные настройки уже будут неадекватны. Например, возьми URL чего-то на ютубе. Ты поменяешь регистр одной буквы после v= — и оно уже не работает. Там скорее можно заменить g на %67, чем на G. Поменяешь v= на V= — всё, не открывает. Могли сделать идентификаторы и названия параметров регистронезависимыми? Могли.
S>Тогда мы не смогли бы кодировать бинарные параметры в base64.
Если бы это было критично, кодировали бы в base32, base36, base40 (знаменитый вариант которого зовётся RADIX-50) и так далее, в зависимости от требований по уникальности вида символов и разрешения дополнительных знаков в наборе.
N>>Например, классическая IETFʼовая грамматизьма, включая центральные стандарты вроде RFC 822, 2616, 3261, игнорирует регистр везде, где может.
S>Она проектировалась быть человеко-читаемой.
А получилось "слегка" наоборот. Полная читаемость всё равно не достижима — из-за ряда хохм типа: quoted string по умолчанию CS, а токены — CI; теги типа CI, а по факту есть масса участников, что их считают CS; грамматика такая, что сбивает логику — например, в записи типа "en;q=0.9,ru;q=0.8" запятая, в нарушение привычной логики, приоритетнее точки с запятой; хохмы типа URI params vs. address params (в SIP); и прочая и прочая.
И на самом деле терминология в принципе неправильная: игнорирование регистра не даёт человеко-читаемость. Читать, сравнивать на известные последовательности символов, писать их — не мешает. CI даёт человеко-озвучиваемость. А насколько она вообще важна в подобных случаях?
N>>Главное в этой проблеме — что то, что выглядит по-разному, должно по умолчанию и восприниматься по-разному, и наоборот.
N>>И регистр в этом одна частная проблема. Например, есть À, À, А̀, Ὰ — ты видишь в своём браузере разницу?
S>Я — да, вижу.
А сформулировать разницу по этому виду не на уровне "ой, тут штрих левее", а в описаниях причины такой разницы — сможешь?
А если будет без штрихов? AВ АΒ ΑB
N>>А драйвер FS воспримет их одинаково или по-разному?
S>Смотря какой драйвер. И смотря как он настроен.
Да по-моему сейчас нет таких, которые бы умели это понимать толком.
N>>А их различать важнее, чем A против a, они вообще совпадут у большинства.
S>Ага, это тоже элемент collation — будет ли он accent-sensitive.
При чём тут accent (in)sensitivity? У меня из 4 в примере было 2 латинских A, одна кириллическая и одна греческая. Accent insensitivity помогло бы разве что первые два сравнять, которые composed и decomposed.
N>>Это абсолютно ничего не говорит без контекста, в каком применяются подобные решения.
N>>Например, "большая тройка" в описанном понимании означает задачи, близкие к таким, как финансы, базы данных людей и т.п. — и мы (кажется) не имеем ни одного языка, в котором был бы регистр букв и при этом он был бы значим для различения имён. Отсюда и тяга к подобным настройкам.
S>Скорее всего да.
OK.
N>>С другой стороны, если у тебя поле, которое не имеет такой специфики, вероятно, что для него подобные настройки уже будут неадекватны. Например, возьми URL чего-то на ютубе. Ты поменяешь регистр одной буквы после v= — и оно уже не работает. Там скорее можно заменить g на %67, чем на G. Поменяешь v= на V= — всё, не открывает. Могли сделать идентификаторы и названия параметров регистронезависимыми? Могли.
S>Тогда мы не смогли бы кодировать бинарные параметры в base64.
Если бы это было критично, кодировали бы в base32, base36, base40 (знаменитый вариант которого зовётся RADIX-50) и так далее, в зависимости от требований по уникальности вида символов и разрешения дополнительных знаков в наборе.
N>>Например, классическая IETFʼовая грамматизьма, включая центральные стандарты вроде RFC 822, 2616, 3261, игнорирует регистр везде, где может.
S>Она проектировалась быть человеко-читаемой.
А получилось "слегка" наоборот. Полная читаемость всё равно не достижима — из-за ряда хохм типа: quoted string по умолчанию CS, а токены — CI; теги типа CI, а по факту есть масса участников, что их считают CS; грамматика такая, что сбивает логику — например, в записи типа "en;q=0.9,ru;q=0.8" запятая, в нарушение привычной логики, приоритетнее точки с запятой; хохмы типа URI params vs. address params (в SIP); и прочая и прочая.
И на самом деле терминология в принципе неправильная: игнорирование регистра не даёт человеко-читаемость. Читать, сравнивать на известные последовательности символов, писать их — не мешает. CI даёт человеко-озвучиваемость. А насколько она вообще важна в подобных случаях?
N>>Главное в этой проблеме — что то, что выглядит по-разному, должно по умолчанию и восприниматься по-разному, и наоборот.
N>>И регистр в этом одна частная проблема. Например, есть À, À, А̀, Ὰ — ты видишь в своём браузере разницу?
S>Я — да, вижу.
А сформулировать разницу по этому виду не на уровне "ой, тут штрих левее", а в описаниях причины такой разницы — сможешь?
А если будет без штрихов? AВ АΒ ΑB
N>>А драйвер FS воспримет их одинаково или по-разному?
S>Смотря какой драйвер. И смотря как он настроен.
Да по-моему сейчас нет таких, которые бы умели это понимать толком.
N>>А их различать важнее, чем A против a, они вообще совпадут у большинства.
S>Ага, это тоже элемент collation — будет ли он accent-sensitive.
При чём тут accent (in)sensitivity? У меня из 4 в примере было 2 латинских A, одна кириллическая и одна греческая. Accent insensitivity помогло бы разве что первые два сравнять, которые composed и decomposed.