внутренняя кодировка для моего приложения

Question

Моё настольное приложение c # получает различные документы от пользователей, возможно, в разных кодировках.

Мне нужно показать пользователям существующие документы, разрешить манипулировать ими в моем пользовательском интерфейсе и сохранить их для дальнейшего использования.

Добавление понятия «кодирование» к каждому из этих этапов мне кажется сложным.Я думал о том, чтобы внутренне всегда преобразовывать пользовательские входные документы в UTF-8, и поэтому мой пользовательский интерфейс и хранилище данных не должны беспокоиться об этом.Затем, когда пользователь хочет вернуть документ в файл, я спрашиваю пользователя, какую кодировку использовать.

Имеет ли это смысл?Совместимы ли кодировки?Что если я поддерживаю только Unicode?

Answer 1

В вашем приложении вы должны использовать встроенную поддержку Unicode (что платформа использует для хранения Unicode).В Windows и OS X это что-то вроде UTF-16, но в Linux это UTF-8.

Когда речь идет о сохранении / загрузке файлов или связи с внешними системами, выберите UTF-8.

Кроме того, не путайте кодовые страницы с кодировками.

Что касается кодовых страниц, сегодня я думаю, что их поддержка уже не так важна.По крайней мере, это не должно быть приоритетом для вас.Поскольку для кодировок ANSI у вас нет спецификаций, будет очень трудно угадать кодировку файлов (на самом деле это невозможно сделать идеально).

Answer 2

Просто декодируйте все документы до String. Строки в .Net всегда имеют Unicode (utf-16). Используйте только кодировки, когда вы читаете или пишете файл.

Answer 3

Кодировки не совместимы, поскольку у некоторых есть символы, которых нет у других.

Внутреннее представление в Юникоде - хорошая идея, поскольку у него более широкая кодировка, но я бы посоветовал сохранить документ обратно висходная кодировка, если добавленные символы все еще находятся в указанной кодировке.Если нет, попросите пользователя сохранить его в Unicode, чтобы правильно кодировать эти символы.

Answer 4

Есть только две причины, чтобы когда-либо использовать UTF-16 в формате обмена (то есть, тот, который отправляется из А в В):

1. Вы не проектировали тип документа и должны взаимодействовать с тем, что уже использует его.
2. Ваш контент таков, что в некоторых языках UTF-16 короче. Это относительно редко, так как даже с этими языками в миксе часто присутствует большое количество символов из BMP, поэтому UTF-8 в итоге получается более лаконичным.

За исключением этого случая, есть только две причины использовать что-либо кроме UTF-8 в формате обмена:

1. Вы не разработали тип документа и должны взаимодействовать с чем-то, что уже использует устаревшие наборы символов.
2. Ты ненавидишь людей.

Номер 2 особенно актуален, если вы особенно ненавидите иностранцев и людей, которые не говорят на вашем родном языке, но если вы просто ненавидите людей в целом, у вас будет достаточно головной боли для достаточного количества людей, и вы найдете, что упражнение удовлетворительное.

Теперь, если исходить из того, что данный формат документа, разработанный кем-то другим, допускает UTF-8, и вы можете ожидать, что все современное программное обеспечение, работающее с ним, сможет обрабатывать UTF-8, то есть две причины не делать это:

1. Существует некоторая проверка безопасности данных, чтобы убедиться, что она не была изменена (обратите внимание, если вы каким-либо образом редактируете или изменяете документ, это по своей сути не применяется).
2. Ты ненавидишь людей. Снова с бонусом для ксенофобов.

Для вашего внутреннего хранения это просто вопрос того, что для вас наиболее полезно. Как правило, .NET имеет значение по умолчанию UTF-16, когда в памяти ( char и string работают с этим) и UTF-8 при записи и чтении из строк. Если вашим резервным хранилищем является SQL Server, то UTF-16 - ваш друг (варианты 'char', 'nvarchar', 'ntext' 'char', 'varchar', 'text', чтобы избежать проблем, если набор символов был установить любое другое значение, кроме UTF-8), и другие базы данных либо имеют свой собственный способ работы с современными персонажами, либо могут использовать UTF-8.

В общем, используйте UTF-8, если кто-то не заставляет вас поступать иначе (потому что они были вынуждены иметь дело с кодом с 1990-х или ранее, или потому что они ненавидят людей).

Answer 5

Когда вы получаете файлы ANSI, вы должны знать кодовую страницу перед преобразованием в Unicode, например, создать строку utf-16, иначе байты от 128 до 255 могут привести к неправильным кодовым точкам Unicode.Вы можете столкнуться с проблемами, если хотите сохранить строку юникода в файле ANSI, потому что кодовые точки размером до 0x10ffff не могут уместиться в один байт.