это не столько электротехническая практика (в электротехнике эдс и напряжение различают четко, и это знает любой студент-электрик). скорее, это практика электромонтажная и потребительская. популярные упрощения в областях применения, где разница понятий не существенна.
нет. вы пытаетесь спорить, не понимая элементарного. любое напряжение это действительно разница потенциалов. но не любая разница потенциалов это напряжение.
на кондерсаторе есть разница потенциалов, а не напряжение. напряжение на нем возникает при протекании тока. само слово напряжение обозначает напряжение (то есть потерю или расход потенциала), когда ток протекает через проводник. не спорьте, погуглите. напряжением всё подряд называет далекий от физики и электротехники потребитель - это популярное упрощение, которое не отражает физику. да и электротехнику тоже. эдс, напряженность, падение напряжения, разница потенциалов, эдс - это все разные вещи.
напряжение создается только током. при прохождении через сопротивление. это примерно перовое занятие по физике электричества. это эдс не создается током. разные по сути величины.
в классической? а вы разницу между падением напряжения на участке цепи и эдс понимаете? так вот, ваш наклон и напор - это эдс. а 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 и т.п.
это не столько электротехническая практика (в электротехнике эдс и напряжение различают четко, и это знает любой студент-электрик). скорее, это практика электромонтажная и потребительская. популярные упрощения в областях применения, где разница понятий не существенна.
тактильная, ~ильная, не важно. скорее всего, не хуже 3s. как минимум, три боковых кнопки. плохо, что ли.
для игр у них линейка G. мастер для работы.
нет. вы пытаетесь спорить, не понимая элементарного. любое напряжение это действительно разница потенциалов. но не любая разница потенциалов это напряжение.
на кондерсаторе есть разница потенциалов, а не напряжение. напряжение на нем возникает при протекании тока. само слово напряжение обозначает напряжение (то есть потерю или расход потенциала), когда ток протекает через проводник. не спорьте, погуглите. напряжением всё подряд называет далекий от физики и электротехники потребитель - это популярное упрощение, которое не отражает физику. да и электротехнику тоже. эдс, напряженность, падение напряжения, разница потенциалов, эдс - это все разные вещи.
напряжение создается исключительно током и без тока не существует. вы путаете с эдс. это разные вещи.
да, химический аккумулятор именно так и действует - просто за сет контакта разных материалов. и термопара тоже. но где здесь вечный двигатель?
гуглите про природу индуктивности.
а линии электрического поля это вообще что?
напряжение создается только током. при прохождении через сопротивление. это примерно перовое занятие по физике электричества. это эдс не создается током. разные по сути величины.
в классической? а вы разницу между падением напряжения на участке цепи и эдс понимаете? так вот, ваш наклон и напор - это эдс. а 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 бит это все, что им было доступно. восьмой бит был добавлен, когда аски уже вовсю использовалась.