напряжение создается только током. при прохождении через сопротивление. это примерно перовое занятие по физике электричества. это эдс не создается током. разные по сути величины.
в классической? а вы разницу между падением напряжения на участке цепи и эдс понимаете? так вот, ваш наклон и напор - это эдс. а U в формуле выше - это падение напряжения на участке цепи при протекании тока. и это падение напряжения как раз создает именно ток. E = U1 + U2 + ... + UN. Или E = IR1 + IR2 + IR3.
что не-а. переносы делаются под устройство вывода, а не формат хранения. хотите фиксированного формата - приводите к юникоду с фиксированной длиной - это не сложно. или к любимому ограниченному аски с головняком кодовых страниц. только зачем. это все уже давным-давно можно сделать и напрямую с utf-8 или utf-16.
переносы определяются шириной отрисовки символов, а не длиной предствления символа в файле. буквы w и i занимают одинаковое количество байтов, но очень разную ширину на устройстве отображения. и кстати, буквы одного алфавита даже в юникоде переменной ширины вроде utf-8 или utf-16 как правило имеют одну длину. латиница - один, кириллица - два байта.
все до единой процедуры из этого списка легко делаются с юникодом переменной длины уже давно стандартными библиотеками. с сохранением универсальности, которая нужна на несколько порядков чаще. json-конфиг, если что, это не проблема кодирования юникодом. а проблема форматирования. с фиксированным аски она будет такой же. только добавится дополнительный головняк на интерпретации.
UTF-8 явно европоцентрична, и предназначена, чтобы с ней, как бы плохо ни было сделано, у "белых цивилизованных людей" ничего не ломалось, а у всяких прочих ломалось.
юникод, и utf-8 явно интернациональноцентричен, и создавался исключительно для снятия вопроса какикх-то центричностей. у азиатскоцентричных людей есть UTF-16. там любой символ занимает как минимум два байта. остальное - как в UTF-8. utf-16 нужен только для совместимости по умолчанию со старыми двухбайтовыми кодировками, как однобайтный UTF-8 совместим с аски. дело не в европо- или азиато- центричности, а в способе письма. если в европе общепринятым стали фонетические алфавиты, то в азии - идеографические. но фонетические там тоже есть - и в китае, и в японии, и в корее, и для этих алфавитов точно так же достаточно одного байта. вопрос не в цивилизационной центричности, а в выборе - писать буквами или понятиями. писать буквами универсальнее. хотите писать понятиями - платите двумя (и более байтами)
Одна кодировка на всех все равно никогда не будет.
одна кодировка для всех уже есть, и это, например, юникод utf-8. а сли вы понимаете под кодировкой кодовую страницу, то это не дело кодирования, а дело прикладного уровня - какие хотите, такие и используйте, и совать это (кодовую страницу) в кодирование (юникод) не нужно. вы ведь в низкоуровневые процессорные инструкции это не суете. а если хотите, чтобы была информация о кодовой странице (предполагаемом способе прикладного использования) файла или блока - обозначайте это снаружи текстового блока. в расширении или метаданных файла, как, например, .md. или в специальном атрибуте внутри файла, как в html.
Я не совсем ловлю использование вами терминологии, и чем в вашем понимании кодировка отличается от кодовой страницы.
вот видите - не ловите, а лезете спорить. кодирование - это представление символа кодом. числом, как в аски, или набором чисел, как в юникоде. а кодовая страница это прикладная категория, для понимания, как кодировку интерпретировать. для сравнения откройте любой файл в редакторе, и попереключайте кодовые страницы. кодировка в файле не изменится, а ваша интрепретация того же файла на уровне приложения при смене кодовой страницы может измениться кардинально.
Да нет, юникод таки содержит конкретные стандартизированные диапазоны стандартизированных глифов и составляющих. А UTF-8, UTF-16 обоих вариантов, UCS-32 и что там еще - разные кодировки для юникода.
да нет, юникод-файл ничего этого не содержит, и вам ничего не мешает интерпретировать файл, как вы хотите. хотите - как utf-8. а хотите - как win1251.
Но заставить (силой или сетевым эффектом - неважно в итоге) всех использовать один сложный, тяжелый, широкий набор алгоритмов и протоколов и стандартов - это не универсальность, это захват мира одной неуниверсальной системой
посмотрел бы я на мир без стандартов. но он закончился еще до пещерного периода истории человечества.
устойчивое, в том числе к постквантовому взлому шифрование можно обеспечить на любом устройстве уже давно. с использованием шифрования несимметричными ключами вопрос доверия состоит только в доступе изготовителя устройства и работающих на нем программ к ключам. если доступа третьей стороны к ключам нет, в том числе через чтение памяти и регистров - устройство можно считать доверенным. но таких устройств, доступных в рознице, нет.
вы не храните никаких букв и символов, которые не используете. вы вообще не храните с символов. только их коды. в среднем - один или чуть больше байтов на символ.
а в чем осталась неразрешенная проблема кодирования? кодирование юникод обеспечивает. а форматированием занимаются более высокие уровни. html, xml, json и т.п.
Как правило, издательство диктует автору все условия договора.
вы реально знаете правила этого бизнеса лучше издательства? откуда, интересно.
желание издательства заработать и желание потребителя получить всё бесплатно противоположны. компромисс в цене. даже если она в некоторых случаях удачно завернута в опенсорс.
стандартизированных в юникоде систем письменности не хватит всем, и это не только проблема нердов, создающих языки, потому что в реальном мире тоже все меняется, и потому что конкретная кодировка влияет на производительность для некоторого рода операций
юникод вообще не занимается стандартизацией системам письменности. это только способ хранения распространенных в применении букв и символов. и запаса 4 байт хватит еще на очень долго. и никто вам не мешает использовать символы, хранимые в юникоде, в любой изобретенной вами кодировке.
эта "лишняя сущность" уже существует и кодировки есть разные, вариант "всех заставить" не рассматриваем
кодовой страницы в файле юникода не содержится. какой ее назначить для одного и того же текста, вы определяете сами. сам текст в юникоде об этом ничего не знает, и это правильно. стандартизация это не "всех заставим", а скорее "себя заставлю". с пониманием, что это открывает массу возможностей.
управляющие последовательности - это не вынесение данных из тела текста, а с куском данных в неуказанной кодировке вы вообще не знаете, очевидно, какая она там
вы путаете кодирование и форматирование. кодировка указана (выбрана) - utf-8, и она содержит всё, что нужно для однозначного декодирования. хотите указывать кодовую страницу - форматируйте, добавляйте вашу архаичную сущность кодовой страницы отдельным полем, и пользуйтесь. все так и делают. посмотрите любой html.
нет, не исчезнувшая, люди хранят много текстов, есть библиотеки, есть википедия, есть соцсети с текстовым общением, есть возможные проекты децентрализации всего этого, короче, эффективности всегда есть место
объемы всех написанных текстов, по сравнению с другими видами предстваления информации - ничтожны. видео, графика и даже сохраняемое аудио занимают на порядки (десятичные) больше места. сохранение хоть всех текстов человечества за всю его историю даже в четырехбайтном юникоде это не проблема уже не один десяток лет.
ну и зачем иметь разные кодировки для текста? какие бенефиты может дать лишняя и сущность (кодировка) и потеря части информации текста (вынесение данных о кодировке из тела текста)? объем памяти для текстов на фоне объемов видео, фото, и даже просто аудио уже давно исчезнувшая проблема.
какие проблемы - есть utf-32. но все почему-то пользуются utf-8 (и немного - азиатским гибридом utf-16). казалось бы, почему. диктат теневого правительства?
извраты юникода? в практике работы с аски извратов в разы больше. кроме, разве что, подсчета количества букв. но многим ли нужно считать буквы мгновенно? и вообще их считать? P.S. а что, языки должны поддерживать юникод, а не наоборот?
max будет просто еще одним более простым и распространенным интерфейсом в госуслуги. от приложения собственно госуслуг можно будет вообще отказаться, оставив за ними только бэкэнд.
напряжение создается только током. при прохождении через сопротивление. это примерно перовое занятие по физике электричества. это эдс не создается током. разные по сути величины.
в классической? а вы разницу между падением напряжения на участке цепи и эдс понимаете? так вот, ваш наклон и напор - это эдс. а U в формуле выше - это падение напряжения на участке цепи при протекании тока. и это падение напряжения как раз создает именно ток.
E = U1 + U2 + ... + UN. Или E = IR1 + IR2 + IR3.
при этом многократное упоминание кириллицы в самом тексте по ссылке вам почему-то ни о чём не говорит
что не-а. переносы делаются под устройство вывода, а не формат хранения. хотите фиксированного формата - приводите к юникоду с фиксированной длиной - это не сложно. или к любимому ограниченному аски с головняком кодовых страниц. только зачем. это все уже давным-давно можно сделать и напрямую с utf-8 или utf-16.
переносы определяются шириной отрисовки символов, а не длиной предствления символа в файле. буквы w и i занимают одинаковое количество байтов, но очень разную ширину на устройстве отображения. и кстати, буквы одного алфавита даже в юникоде переменной ширины вроде utf-8 или utf-16 как правило имеют одну длину. латиница - один, кириллица - два байта.
все до единой процедуры из этого списка легко делаются с юникодом переменной длины уже давно стандартными библиотеками. с сохранением универсальности, которая нужна на несколько порядков чаще. json-конфиг, если что, это не проблема кодирования юникодом. а проблема форматирования. с фиксированным аски она будет такой же. только добавится дополнительный головняк на интерпретации.
юникод, и utf-8 явно интернациональноцентричен, и создавался исключительно для снятия вопроса какикх-то центричностей.
у азиатскоцентричных людей есть UTF-16. там любой символ занимает как минимум два байта. остальное - как в UTF-8. utf-16 нужен только для совместимости по умолчанию со старыми двухбайтовыми кодировками, как однобайтный UTF-8 совместим с аски.
дело не в европо- или азиато- центричности, а в способе письма. если в европе общепринятым стали фонетические алфавиты, то в азии - идеографические. но фонетические там тоже есть - и в китае, и в японии, и в корее, и для этих алфавитов точно так же достаточно одного байта. вопрос не в цивилизационной центричности, а в выборе - писать буквами или понятиями. писать буквами универсальнее. хотите писать понятиями - платите двумя (и более байтами)
одна кодировка для всех уже есть, и это, например, юникод utf-8. а сли вы понимаете под кодировкой кодовую страницу, то это не дело кодирования, а дело прикладного уровня - какие хотите, такие и используйте, и совать это (кодовую страницу) в кодирование (юникод) не нужно. вы ведь в низкоуровневые процессорные инструкции это не суете. а если хотите, чтобы была информация о кодовой странице (предполагаемом способе прикладного использования) файла или блока - обозначайте это снаружи текстового блока. в расширении или метаданных файла, как, например, .md. или в специальном атрибуте внутри файла, как в html.
вот видите - не ловите, а лезете спорить. кодирование - это представление символа кодом. числом, как в аски, или набором чисел, как в юникоде. а кодовая страница это прикладная категория, для понимания, как кодировку интерпретировать. для сравнения откройте любой файл в редакторе, и попереключайте кодовые страницы. кодировка в файле не изменится, а ваша интрепретация того же файла на уровне приложения при смене кодовой страницы может измениться кардинально.
да нет, юникод-файл ничего этого не содержит, и вам ничего не мешает интерпретировать файл, как вы хотите. хотите - как utf-8. а хотите - как win1251.
посмотрел бы я на мир без стандартов. но он закончился еще до пещерного периода истории человечества.
устойчивое, в том числе к постквантовому взлому шифрование можно обеспечить на любом устройстве уже давно. с использованием шифрования несимметричными ключами вопрос доверия состоит только в доступе изготовителя устройства и работающих на нем программ к ключам. если доступа третьей стороны к ключам нет, в том числе через чтение памяти и регистров - устройство можно считать доверенным. но таких устройств, доступных в рознице, нет.
вы не храните никаких букв и символов, которые не используете. вы вообще не храните с символов. только их коды. в среднем - один или чуть больше байтов на символ.
а в чем осталась неразрешенная проблема кодирования? кодирование юникод обеспечивает. а форматированием занимаются более высокие уровни. html, xml, json и т.п.
разработчики ascii о расширении даже не думали. 7 бит это все, что им было доступно. восьмой бит был добавлен, когда аски уже вовсю использовалась.
а есть доверенные? даже апостериори? блэкберри когда-то?
вы реально знаете правила этого бизнеса лучше издательства? откуда, интересно.
желание издательства заработать и желание потребителя получить всё бесплатно противоположны. компромисс в цене. даже если она в некоторых случаях удачно завернута в опенсорс.
юникод вообще не занимается стандартизацией системам письменности. это только способ хранения распространенных в применении букв и символов. и запаса 4 байт хватит еще на очень долго. и никто вам не мешает использовать символы, хранимые в юникоде, в любой изобретенной вами кодировке.
кодовой страницы в файле юникода не содержится. какой ее назначить для одного и того же текста, вы определяете сами. сам текст в юникоде об этом ничего не знает, и это правильно. стандартизация это не "всех заставим", а скорее "себя заставлю". с пониманием, что это открывает массу возможностей.
вы путаете кодирование и форматирование. кодировка указана (выбрана) - utf-8, и она содержит всё, что нужно для однозначного декодирования. хотите указывать кодовую страницу - форматируйте, добавляйте вашу архаичную сущность кодовой страницы отдельным полем, и пользуйтесь. все так и делают. посмотрите любой html.
объемы всех написанных текстов, по сравнению с другими видами предстваления информации - ничтожны. видео, графика и даже сохраняемое аудио занимают на порядки (десятичные) больше места. сохранение хоть всех текстов человечества за всю его историю даже в четырехбайтном юникоде это не проблема уже не один десяток лет.
ну и зачем иметь разные кодировки для текста? какие бенефиты может дать лишняя и сущность (кодировка) и потеря части информации текста (вынесение данных о кодировке из тела текста)? объем памяти для текстов на фоне объемов видео, фото, и даже просто аудио уже давно исчезнувшая проблема.
какие проблемы - есть utf-32. но все почему-то пользуются utf-8 (и немного - азиатским гибридом utf-16). казалось бы, почему. диктат теневого правительства?
а многим ли нужно считать буквы? и делать это мгновенно?
про увеличение памяти на хранение текстов - такой проблемы нет уже не первый десяток лет.
извраты юникода? в практике работы с аски извратов в разы больше. кроме, разве что, подсчета количества букв. но многим ли нужно считать буквы мгновенно? и вообще их считать?
P.S. а что, языки должны поддерживать юникод, а не наоборот?
max будет просто еще одним более простым и распространенным интерфейсом в госуслуги. от приложения собственно госуслуг можно будет вообще отказаться, оставив за ними только бэкэнд.