В чем разница между UTF-8 и UTF-8 без спецификации?
https://stackoverflow.com/questions/2223882
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В чем разница между UTF-8 и UTF-8 без РОЖДЕННЫЙ?Что лучше?
Решение
Спецификация UTF-8 представляет собой последовательность байтов в начале текстового потока (EF BB BF), которая позволяет читателю более надежно определить, что файл закодирован в UTF-8.
Обычно спецификация используется для указания порядкового номера кодировки, но поскольку порядковый номер не имеет отношения к UTF-8, спецификация не нужна.
В соответствии с Стандарт Unicode, тот Спецификация для файлов UTF-8 не рекомендуется:
2.6 Схемы кодирования
...Использование спецификации не требуется и не рекомендуется для UTF-8, но может быть встречается в контекстах, где данные UTF-8 преобразуются из других формы кодирования, в которых используется спецификация или где спецификация используется как UTF-8 подпись.Смотрите подраздел “Метка порядка байтов” в Раздел 16.8, Специальные возможности, для получения дополнительной информации.
Другие советы
Другие отличные ответы уже ответили на этот вопрос:
- Официальной разницы между UTF-8 и стандартным UTF-8 нет
- Стандартная строка UTF-8 будет начинаться с трех следующих байтов.
EF BB BF - Эти байты, если они присутствуют, должны игнорироваться при извлечении строки из файла / потока.
Но, в качестве дополнительной информации к этому, спецификация для UTF-8 могла бы быть хорошим способом "учуять", была ли строка закодирована в UTF-8...Или это может быть законная строка в любой другой кодировке...
Например, данные [EF BB BF 41 42 43] могут быть либо:
- Законный ISO-8859-1 строка "ABC"
- Законный UTF-8 строка "ABC"
Таким образом, хотя может быть здорово распознать кодировку содержимого файла, посмотрев на первые байты, вам не следует полагаться на это, как показывает приведенный выше пример
Кодировки должны быть известны, а не разгаданы.
Существует по крайней мере три проблемы с помещением спецификации в файлы в кодировке UTF-8.
- Файлы, которые не содержат текста, больше не являются пустыми, поскольку они всегда содержат спецификацию.
- Файлы, содержащие текст, который находится в подмножестве ASCII UTF-8, сами по себе больше не являются ASCII, поскольку спецификация не является ASCII, что приводит к поломке некоторых существующих инструментов, и для пользователей может оказаться невозможным заменить такие устаревшие инструменты.
- Объединить несколько файлов вместе невозможно, поскольку каждый файл теперь имеет спецификацию в начале.
И, как упоминали другие, иметь спецификацию недостаточно и не обязательно, чтобы определить, что что-то является UTF-8:
- Этого недостаточно, поскольку произвольная последовательность байтов может начинаться с точной последовательности, которая составляет спецификацию.
- В этом нет необходимости, потому что вы можете просто прочитать байты, как если бы они были UTF-8;если это удастся, то это, по определению, допустимый UTF-8.
Это старый вопрос со многими хорошими ответами, но следует добавить одну вещь.
Все ответы очень общие.Что я хотел бы добавить, так это примеры использования спецификации, которые на самом деле вызывают реальные проблемы, и все же многие люди не знают об этом.
Сценарии разрывов спецификации
Сценарии оболочки, скрипты Perl, скрипты Python, скрипты Ruby, Node.js скрипты или любой другой исполняемый файл, который должен запускаться интерпретатором, - все они начинаются с линия шебанга который выглядит как один из тех:
#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node
Он сообщает системе, какой интерпретатор необходимо запустить при вызове такого скрипта.Если скрипт закодирован в UTF-8, может возникнуть соблазн включить спецификацию в начале.Но на самом деле символы "#!" - это не просто символы.На самом деле они являются магическое число так получилось, что он состоит из двух символов ASCII.Если вы поставите что-то (например, спецификацию) перед этими символами, то файл будет выглядеть так, как будто в нем был другой магический номер, и это может привести к проблемам.
Смотрите Википедию, Статья:Шебанг, секция:Магическое число:
Символы shebang представлены теми же двумя байтами в расширенных кодировках ASCII, включая UTF-8, который обычно используется для скриптов и других текстовых файлов в современных Unix-подобных системах.Однако Файлы в формате UTF-8 могут начинаться с необязательной метки порядка байтов (BOM);если функция "exec" специально определяет байты 0x23 и 0x21, то наличие спецификации (0xEF 0xBB 0xBF) перед shebang предотвратит выполнение интерпретатора сценариев. Некоторые авторитетные источники рекомендуют не использовать знак порядка байтов в скриптах POSIX (Unix-подобных),[14] по этой причине, а также для более широкой совместимости и философских соображений проблемы.Кроме того, в UTF-8 нет необходимости указывать порядок байтов, поскольку эта кодировка не имеет проблем с порядком следования;это служит только для того, чтобы идентифицировать кодировку как UTF-8.[курсив добавлен]
Спецификация является незаконной в JSON
Видишь RFC 7159, Раздел 8.1:
Реализации НЕ ДОЛЖНЫ добавлять знак порядка байтов в начало текста JSON.
Спецификация избыточна в JSON
Не только это незаконный в JSON это также не требуется для определения кодировки символов, поскольку существуют более надежные способы однозначного определения как кодировки символов, так и порядкового номера, используемого в любом потоке JSON (см. этот ответ для получения подробной информации).
Спецификация ломает синтаксические анализаторы JSON
Не только это незаконный в формате JSON и не требуется, это на самом деле ломает все программное обеспечение которые определяют кодировку с использованием метода, представленного в RFC 4627:
Определение кодировки и порядкового номера JSON, проверка первых 4 байтов на наличие нулевого байта:
00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8
Теперь, если файл начинается со спецификации, он будет выглядеть следующим образом:
00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8
Обратите внимание , что:
- UTF-32BE не начинается с трех нулей, поэтому он не будет распознан
- UTF-32LE за первым байтом не следует 3 нуля, поэтому он не будет распознан
- UTF-16BE содержит только 1 NUL в первых 4 байтах, поэтому он не будет распознан
- UTF-16LE содержит только 1 NUL в первых 4 байтах, поэтому он не будет распознан
В зависимости от реализации, все они могут быть неправильно интерпретированы как UTF-8, а затем неверно истолкованы или отклонены как недопустимый UTF-8 или вообще не распознаны.
Кроме того, если реализация протестирует допустимый JSON, как я рекомендую, она отклонит даже входные данные, которые действительно закодированы как UTF-8, потому что они не начинаются с символа ASCII < 128 как и должно быть в соответствии с RFC.
Другие форматы данных
Спецификация в формате JSON не нужна, является незаконной и нарушает работу программного обеспечения, которое корректно работает в соответствии с RFC.Было бы глупо просто не использовать его тогда, и все же всегда находятся люди, которые настаивают на нарушении JSON с помощью спецификаций, комментариев, других правил цитирования или разных типов данных.Конечно, любой может свободно использовать такие вещи, как спецификации или что-нибудь еще, если вам это нужно - просто не называйте это JSON тогда.
Для других форматов данных, отличных от JSON, взгляните, как это выглядит на самом деле.Если единственными кодировками являются UTF-*, а первый символ должен быть символом ASCII младше 128, то у вас уже есть вся информация, необходимая для определения как кодировки, так и порядкового номера ваших данных.Добавление спецификаций даже в качестве необязательной функции только усложнило бы ее и привело бы к возникновению ошибок.
Другие виды использования спецификации
Что касается использования вне JSON или скриптов, я думаю, что здесь уже есть очень хорошие ответы.Я хотел добавить более подробную информацию конкретно о написании сценариев и сериализации, потому что это пример символов спецификации, вызывающих реальные проблемы.
Чем отличается UTF-8 от UTF-8 без спецификации?
Короткий ответ:В UTF-8 спецификация кодируется как байты EF BB BF в начале файла.
Длинный ответ:
Первоначально ожидалось, что Юникод был бы закодирован в UTF-16/ UCS-2.Спецификация была разработана для этой формы кодирования.Когда у вас есть 2-байтовые кодовые единицы, необходимо указать, в каком порядке находятся эти два байта, и общим соглашением для этого является включение символа U + FEFF в качестве "Метки порядка байтов" в начале данных.Символ U + FFFE постоянно не присваивается, так что его присутствие может быть использовано для обнаружения неправильного порядка байтов.
UTF-8 имеет одинаковый порядок байтов независимо от порядкового номера платформы, поэтому отметка о порядке байтов не требуется.Однако это может произойти (в виде последовательности байтов EF BB FF) в данных, которые были преобразованы в UTF-8 из UTF-16, или в качестве "подписи", указывающей, что данные являются UTF-8.
Что лучше?
Без.Как ответил Мартин Коут, стандарт Unicode этого не рекомендует.Это вызывает проблемы с программным обеспечением, не поддерживающим спецификацию.
Лучший способ определить, является ли файл UTF-8, - это выполнить проверку достоверности.UTF-8 имеет строгие правила о том, какие последовательности байтов являются допустимыми, поэтому вероятность ложноположительного результата ничтожно мала.Если последовательность байтов выглядит как UTF-8, то, вероятно, так оно и есть.
UTF-8 со спецификацией лучше идентифицируется.Я пришел к этому выводу нелегким путем.Я работаю над проектом, где одним из результатов является CSV - файл файл, содержащий символы Юникода.
Если CSV-файл сохранен без спецификации, Excel считает, что это ANSI, и показывает тарабарщину.Как только вы добавите "EF BB BF" спереди (например, повторно сохранив его с помощью Notepad с UTF-8;или Notepad ++ с UTF-8 со спецификацией), Excel открывает его нормально.
Добавление символа спецификации к текстовым файлам в формате Unicode рекомендуется RFC 3629:"UTF-8, формат преобразования ISO 10646", ноябрь 2003 в http://tools.ietf.org/html/rfc3629 (эта последняя информация, найденная на: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)
BOM имеет тенденцию к взрыву (без каламбура (sic)) где-то, somewhere.И когда он срабатывает (например, не распознается браузерами, редакторами и т.д.), Он отображается в виде странных символов  в начале документа (например, HTML-файла, JSON ответ, RSS-канал, и т.д.) и вызывает такого рода затруднения, как недавняя проблема с кодировкой, возникшая во время выступления Обамы в Twitter.
Это очень раздражает, когда это появляется в местах, которые трудно отлаживать, или когда тестированием пренебрегают.Поэтому лучше избегать его, если только вы не должны им пользоваться.
Вопрос: Чем отличается UTF-8 от UTF-8 без спецификации?Что лучше?
Вот несколько выдержек из статьи Википедии о метка порядка байтов (спецификация) которые, я полагаю, дают убедительный ответ на этот вопрос.
О значении спецификации и UTF-8:
Стандарт Unicode разрешает РОЖДЕННЫЙ в UTF-8, но не требует и не рекомендует его использование.Порядок байтов не имеет значения в UTF-8, поэтому его единственное использование в UTF-8 - это сигнализировать в начале, что текстовый поток закодирован в UTF-8.
Аргумент в пользу НЕ использование спецификации:
Основной причиной отказа от использования спецификации является обратная совместимость с программным обеспечением, которое не поддерживает Unicode...Еще одна причина не использовать использование спецификации заключается в том, чтобы использовать UTF-8 в качестве кодировки "по умолчанию".
Аргумент ДЛЯ использование спецификации:
Аргумент в пользу использования спецификации заключается в том, что без нее требуется эвристический анализ для определения того, какую кодировку символов использует файл.Исторически такой анализ, позволяющий различать различные 8-битные кодировки, является сложным, подверженным ошибкам и иногда медленным.Для облегчения задачи доступно несколько библиотек , таких как Mozilla Universal Charset Детектор и международные компоненты для Unicode.
Программисты ошибочно предполагают, что обнаружение UTF-8 одинаково затруднено (это не из-за подавляющего большинства байтовых последовательностей недопустимы UTF-8, в то время как кодировки, которые эти библиотеки пытаются различать разрешенные все возможные последовательности байтов).Поэтому не все Программы, поддерживающие Unicode, выполняют такой анализ и вместо этого полагаются на спецификацию.
В частности, Майкрософт компиляторы и интерпретаторы, и многие части программного обеспечения в Microsoft Windows, такие как Notepad, не будут правильно считывать текст в формате UTF-8, если он не содержит только символов ASCII или его начинается со спецификации и добавит спецификацию в начало при сохранении текста как UTF-8.Google Docs добавит спецификацию при загрузке документа Microsoft Word в виде обычного текстового файла.
О том, что лучше, С или БЕЗ спецификация:
В IETF рекомендует, чтобы, если протокол либо (а) всегда использует UTF-8, либо (б) имеет какой-либо другой способ указать, какая кодировка используется, затем он “ДОЛЖЕН запретить использование U + FEFF в качестве подписи”.
Мой Вывод:
Используйте спецификацию Только если совместимость с программным приложением абсолютно необходима.
Также обратите внимание, что, хотя в упомянутой статье Википедии указано, что многие приложения Microsoft полагаются на спецификацию для правильного определения UTF-8, это не относится к ВСЕ Приложения Microsoft.Например, как указал @барлоп, при использовании командной строки Windows с UTF-8†, командует такими type и more не ожидайте, что спецификация будет присутствовать.Если спецификация является в настоящее время это может быть проблематично, как и для других приложений.
† Тот chcp команда предлагает поддержку UTF-8 (без спецификацию) через кодовую страницу 65001.
Цитируется внизу страницы Википедии в спецификации: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2
"Использование спецификации не требуется и не рекомендуется для UTF-8, но может встречаться в контекстах, когда данные UTF-8 преобразуются из других форм кодирования, использующих спецификацию, или когда спецификация используется в качестве подписи UTF-8"
Следует отметить, что для некоторых файлов вы не должен имейте спецификацию даже в Windows.Примерами являются SQL*plus или VBScript Файлы.В случае, если такие файлы содержат спецификацию, вы получаете сообщение об ошибке при попытке их выполнения.
На этот вопрос уже есть миллион и один ответ, и многие из них довольно хороши, но я хотел попытаться уточнить, когда следует или не следует использовать спецификацию.
Как упоминалось, любое использование спецификации UTF (метки порядка байтов) для определения того, является ли строка UTF-8 или нет, является обоснованным предположением.Если имеются надлежащие метаданные (например charset="utf-8"), тогда вы уже знаете, что вы должны использовать, но в противном случае вам нужно будет протестировать и сделать некоторые предположения.Это включает в себя проверку того, начинается ли файл, из которого поступает строка, с шестнадцатеричного байтового кода EF BB BF.
Если найден байтовый код, соответствующий спецификации UTF-8, вероятность достаточно высока, чтобы предположить, что это UTF-8, и вы можете перейти оттуда.Однако, когда приходится делать это предположение, дополнительная проверка ошибок во время чтения все равно была бы хорошей идеей на случай, если что-то окажется искаженным.Вы должны только предположить, что спецификация не является UTF-8 (т.е.latin-1 или ANSI), если входные определенно не должно быть UTF-8 на основе его исходного кода.Однако, если спецификации нет, вы можете просто определить, должен ли он быть UTF-8, выполнив проверку на соответствие кодировке.
Почему СПЕЦИФИКАЦИЯ не рекомендуется?
- Программное обеспечение, не поддерживающее Юникод, или плохо совместимое с ним, может предположить, что это latin-1 или ANSI, и не будет удалять спецификацию из строки, что, очевидно, может вызвать проблемы.
- На самом деле это не нужно (просто проверьте, соответствует ли содержимое, и всегда используйте UTF-8 в качестве запасного варианта, когда совместимая кодировка не может быть найдена)
Когда следует вы кодируете с помощью спецификации?
Если вы не можете записать метаданные каким-либо другим способом (через тег кодировки или файловую систему meta), а программы используются как спецификации, вам следует закодировать с помощью спецификации.Это особенно верно в Windows, где обычно предполагается, что все, что не имеет спецификации, использует устаревшую кодовую страницу.Спецификация сообщает программам, таким как Office, что да, текст в этом файле в формате Unicode;вот используемая кодировка.
Если уж на то пошло, единственные файлы, с которыми у меня когда-либо действительно возникали проблемы, - это CSV.В зависимости от программы у нее либо должна быть спецификация, либо ее не должно быть.Например, если вы используете Excel 2007+ в Windows, он должен быть закодирован с помощью спецификации, если вы хотите беспрепятственно открывать его и не прибегать к импорту данных.
UTF-8 со спецификацией помогает только в том случае, если файл действительно содержит некоторые символы, отличные от ASCII.Если он включен, а таковых нет, то это, возможно, приведет к поломке старых приложений, которые в противном случае интерпретировали бы файл как обычный ASCII.Эти приложения определенно потерпят неудачу, когда они столкнутся с символом, отличным от ASCII, поэтому, на мой взгляд, спецификацию следует добавлять только тогда, когда файл больше не может и не должен интерпретироваться как обычный ASCII.
Редактировать:Просто хочу прояснить, что я предпочитаю вообще не иметь спецификации, добавляю ее, если какой-то старый мусор выходит из строя без нее, и замена этого устаревшего приложения невозможна.
Не заставляйте ничего ожидать от спецификации для UTF8.
UTF-8 без спецификации не имеет спецификации, что не делает его лучше, чем UTF-8 со спецификацией, за исключением случаев, когда потребителю файла необходимо знать (или было бы полезно узнать), закодирован ли файл в UTF-8 или нет.
Спецификация обычно полезна для определения порядкового номера кодировки, что не требуется в большинстве случаев использования.
Кроме того, спецификация может создавать ненужный шум / неудобства для тех потребителей, которые не знают об этом или не заботятся о нем, и может привести к путанице пользователей.
Я смотрю на это с другой точки зрения.Я думаю, что UTF-8 со спецификацией лучше поскольку это предоставляет больше информации о файле.Я использую UTF-8 без спецификации, только если сталкиваюсь с проблемами.
Я использую несколько языков (даже Кириллица) на моих страницах в течение длительного времени, и когда файлы сохраняются без спецификации, и я повторно открываю их для редактирования с помощью редактора (как черувим также отмечено), некоторые символы повреждены.
Обратите внимание, что Windows' classic Блокнот автоматически сохраняет файлы со спецификацией при попытке сохранить вновь созданный файл в кодировке UTF-8.
Я лично сохраняю серверную часть файлы сценариев (.asp, .ini, .aspx) со спецификацией и файлы .html без спецификации.
Когда вы хотите отобразить информацию, закодированную в UTF-8, вы можете не столкнуться с проблемами.Объявите, например, HTML-документ как UTF-8, и в вашем браузере будет отображаться все, что содержится в теле документа.
Но это не тот случай, когда у нас есть текст, CSV - файл и XML-файлы, либо в Windows, либо в Linux.
Например, текстовый файл в Windows или Linux, одна из самых простых вещей, которые только можно себе представить, это не (обычно) UTF-8.
Сохраните его как XML и объявите как UTF-8:
<?xml version="1.0" encoding="UTF-8"?>
Он не будет отображаться (он не будет прочитан) корректно, даже если он объявлен как UTF-8.
У меня была строка данных, содержащая французские буквы, которые необходимо было сохранить в виде XML для объединения.Без создания файла UTF-8 с самого начала (изменения параметров в IDE и "Создать новый файл") или добавления спецификации в начале файла
$file="\xEF\xBB\xBF".$string;
Мне не удалось сохранить французские буквы в XML-файле.
Одно практическое отличие заключается в том, что если вы напишете сценарий оболочки для Mac OS X и сохраните его как обычный UTF-8, вы получите ответ:
#!/bin/bash: No such file or directory
в ответ на строку shebang, указывающую, какую оболочку вы хотите использовать:
#!/bin/bash
Если вы сохраняете как UTF-8, спецификации нет (скажем, в BBEdit) все будет хорошо.
Как упоминалось выше, UTF-8 со спецификацией может вызвать проблемы с программным обеспечением, не поддерживающим спецификацию (или совместимым).Однажды я редактировал HTML-файлы, закодированные как UTF-8 + BOM, с помощью Mozilla-based Композитор, поскольку клиент требовал , чтобы WYSIWYG программа.
Неизменно макет будет уничтожен при сохранении.Мне потребовалось некоторое время, чтобы разобраться с этим.Затем эти файлы хорошо работали в Firefox, но показали причуду CSS в Internet Explorer, снова уничтожив макет.После нескольких часов безрезультатной работы со связанными CSS-файлами я обнаружил, что Internet Explorer не понравился отредактированный HTML-файл.Никогда больше.
Кроме того, я только что нашел это в Википедии:
Символы shebang представлены одними и теми же двумя байтами в расширенных кодировках ASCII, включая UTF-8, который обычно используется для сценариев и других текстовых файлов в современных Unix-подобных системах.Однако файлы в формате UTF-8 могут начинаться с необязательной метки порядка байтов (BOM);если функция "exec" специально обнаруживает байты 0x23 0x21, то наличие спецификации (0xEF 0xBB 0xBF) перед shebang предотвратит выполнение интерпретатора сценариев.Некоторые авторитетные источники рекомендуют не использовать знак порядка байтов в скриптах POSIX (Unix-подобных)[15] по этой причине, а также для более широкой совместимости и философских соображений
Юникод Метка порядка байтов (СПЕЦИФИКАЦИЯ) ЧАСТО задаваемые ВОПРОСЫ дает краткий ответ:
Q:Как я должен обращаться со спецификациями?
A:Вот несколько рекомендаций, которым следует следовать:
Конкретный протокол (например,Соглашения Microsoft для файлов .txt) может потребовать использования спецификации в определенных потоках данных в формате Unicode, таких как файлы.Когда вам нужно соответствовать такому протоколу, используйте спецификацию.
Некоторые протоколы допускают дополнительные спецификации в случае текста без пометок.В этих случаях,
Если известно, что текстовый поток данных представляет собой обычный текст, но неизвестной кодировки, BOM может использоваться в качестве подписи.Если спецификации нет, кодировка может быть любой.
Если известно, что текстовый поток данных представляет собой обычный текст в Юникоде (но не указан порядковый номер), то BOM можно использовать в качестве подписи.Если спецификации нет , текст следует интерпретировать как порядковый номер с большим окончанием.
Некоторые байт-ориентированные протоколы ожидают, что символы ASCII будут располагаться в начале файла.Если с этими протоколами используется UTF-8, следует избегать использования спецификации в качестве подписи формы кодирования.
Где известен точный тип потока данных (например,Unicode big-endian или Unicode little-endian), спецификацию использовать не следует.В в частности, всякий раз, когда поток данных объявляется как UTF-16BE, UTF-16LE, UTF-32BE или UTF-32LE, спецификация не должна использоваться.
От http://en.wikipedia.org/wiki/Byte-order_mark:
Знак порядка байтов (BOM) - это символ Юникода , используемый для обозначения порядкового номера (байтового порядка) текстового файла или потока.Его кодовая точка - U + FEFF.Использование спецификации необязательно, и, если используется, должно отображаться в начале текста поток.Помимо его конкретного использования в качестве индикатора порядка байтов, спецификация символ также может указывать, в каком из нескольких представлений Unicode закодирован текст.
Постоянное использование спецификации в вашем файле гарантирует, что он всегда будет корректно открываться в редакторе, поддерживающем UTF-8 и спецификацию.
Моя реальная проблема с отсутствием спецификации заключается в следующем.Предположим, у нас есть файл, который содержит:
abc
Без спецификации это открывается как ANSI в большинстве редакторов.Таким образом, другой пользователь этого файла открывает его и добавляет некоторые собственные символы, например:
abg-αβγ
Упс...Теперь файл все еще находится в ANSI, и угадайте что, "αβγ" занимает не 6 байт, а 3.Это не UTF-8, и это вызывает другие проблемы позже в цепочке разработки.
Вот мой опыт работы с запросами на извлечение Visual Studio, SourceTree и Bitbucket, которые вызывали у меня некоторые проблемы:
Таким образом, получается, что спецификация с подписью будет включать символ красной точки в каждом файле при просмотре запроса на извлечение (может быть довольно раздражающим).
Если вы наведете на него курсор, он покажет символ типа "ufeff", но оказывается, что sourcetree не показывает эти типы байтовых меток, так что, скорее всего, это попадет в ваши запросы на извлечение, что должно быть нормально, потому что именно так VS 2017 сейчас кодирует новые файлы, так что, возможно, bitbucket следует проигнорировать это или сделать так, чтобы это отображалось другим способом, больше информации здесь:
UTF с BOM лучше, если вы используете UTF-8 в HTML-файлах, если вы используете сербскую кириллицу, сербскую латиницу, немецкий, венгерский или какой-нибудь экзотический язык на той же странице.Это мое мнение (30 лет работы в компьютерной и ИТ-индустрии).
