AkelPad

Проблема такова, сохранил русский текст в .txt документ из кодировки 1251 (ANSI-Кириллица) в кодировку 20127 (США-ASCII), после переместил на мобильник Nokia 5800, открыл и увидел что везде вместо русских букв знаки вопроса "???????", после открыл документ на компьютере и там оказалось тоже самое, пытался поменять кодировку, но ничего не изменялось
Что нужно сделать чтобы русский текст вернулся?
Заранее Спасибо
Вот ссылка на пример этого непонятного для меня явления:
http://ifolder.ru/15238114

beerbitch, вспоминайте где брали источник. Вам даже бубен не поможет в этом случае. Когда сохраняли Вас предупреждали что символы будут утеряны. Вот они и утеряны.

Спасибо FeyFre, теперь понял что восстановить невозможно...ведь откат системы не поможет
P.S. Винница У меня там друзья живут

FeyFre wrote:beerbitch,Когда сохраняли Вас предупреждали что символы будут утеряны. Вот они и утеряны.

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

З.Ы.
Может вынести предложение в отдельную тему.

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

Я лично всё делаю в UTF-8 где только ьего понимает софт, либо в UTF16 LE/BE.
Люди давно уже забыли что такое не-Юникод кодировка, а потому не придумывают больше супер-дупер-эврестических алгоритмов поиск совместимых не-Юникодных кодировок. Возьметесь?

FeyFre wrote:

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

Я лично всё делаю в UTF-8 где только ьего понимает софт, либо в UTF16 LE/BE.
Люди давно уже забыли что такое не-Юникод кодировка, а потому не придумывают больше супер-дупер-эврестических алгоритмов поиск совместимых не-Юникодных кодировок. Возьметесь?

А кто сказал, что я против юникода?)
Пусть предлагает сохранять в юникод)

А какая-же кодировка тогда лучше всех, чтобы читалась на мобильнике и на компе без проблем?
UTF-8?

beerbitch wrote:UTF-8?

Линуксы больше любят UTF-8, а Виндовсы - UTF-16 LE (она же UCS-2 LE).
Собственно, WideChar в Виндовс - это и есть UTF-16 LE.

DV wrote:

beerbitch wrote:UTF-8?

Линуксы больше любят UTF-8, а Виндовсы - UTF-16 LE (она же UCS-2 LE).
Собственно, WideChar в Виндовс - это и есть UTF-16 LE.

Спасибо, кое-что разъяснили
Может ещё сможете ответить на 2 вопроса:
1) Что такое "BOM"? Галочку можно ставить и не ставить при сохранении на это.
2) Юникод - это какая кодировка, имею ввиду ASCII или UTF-9 или ещё что?

Линуксы больше любят UTF-8

Поправчока: линуксы только недавно начали любить UTF-8, у потому траблы с постройкой нового ядра на старом дистрибутиве - очень частое явление. У меня Линукс без проблем дружит с KOI8-U
Виндовс - гадость, никак не может определится в какой кодировке записаны имена на NTFS. Привык уже читать хекс последовательности

Собственно, WideChar в Виндовс - это и есть UTF-16 LE.

Мелкомягкие вас обманули. WideChar это UCS-2 - UTF16 без одного множества суррогатных кодов. Они иначе не смогут. Иначе sizeof(wchar_t) != 2 и не постоянна, и потому накрывается туева хуча API.

1) Что такое "BOM"? Галочку можно ставить и не ставить при сохранении на это.

BOM - Byte Order Mark - метка порядка байт - всегда первые три байта любого Юникод текста(кроме случаев когда их специально вырезают). Обрабатывается текстовыми процессорами как источник следующий информации(метаданные):
1. Порядок следования байт многобайтовго числа (LE/BE), который использовался при сохранении текста(символы Юникод кодировок - суть 1, 2, 4-байтовые числа).
2. Код Юникод кодировки.
Если редактор поддерживает Юникод, он правильно отобразит текст, в который БОМ не входит. Иначе он интерпретирует эти байты как символы и отобразит их тоже.

Сохранять рекомендуется всегда с БОМ.
Исключения могут быть такие:
1. Текстовый файл предназначен для какой-то программы или устройства которое заведомо понимает только одну из Юникод кодировок и требует отсутствия БОМ, или же не поддерживает Юникод кодировки вообще, но необходимо Юникод последовательности вставить в текст, например PHP интерпретатор пока поддерживает только однобайтовые кодировки исходного кода скрипта, но сам язык спокойно переваривает UTF-8, например в строковых литералах. В таких случаях скрипты пишут в UTF-8 без БОМ.
2. Метаданные о тексте доставляются к интерпретатору текста отдельным способом. Ну чтобы поняли:
Подается запрос к текстовому файлу на сервере. Серверу сказали что все текстовые файлы лежат в конкретной Юникод кодировке. Он добросовестно выдает в ответе в заголвках указанную кодировку, и пересылает текст из запрошенного файла. Обозревателю уже не нужно смотреть на БОМ для корректного отображения текста, он уже проанализировал заголовок которые выдал сервер и определил всё что нужно. И потому если придет БОМ вместе с текстом - он подумает что это тоже текст и отобразит его, что будет казаться "мусором" для человека.

2) Юникод - это какая кодировка, имею ввиду ASCII или UTF-9 или ещё что?

Юникод это Юникод
Юникод - это множество кодировок для унифицированной передачи и сохранения символов разных языков. ANSI - кодировки: количество допустимых символов не превышает 256 - один байт, а так как символов в разных языках много(польский, рус/укр, английский, немецкий, японский, китайский, корейский и т.д) и они не влазят в ограничение 256, вот их и разделили на разный ANSI-кодировки, которые в одном тексте не могут находится.
В Юникод - кодировка символе не ограничена одним байтом, и потому в одном тексте могут быть фрагменты на разных языках, и все символы будут отображаться корректно. Самые популярные это:
UTF-8, UTF-16, UTF-32, UCS-2. Остальные можете посмотреть http://en.wikipedia.org/wiki/Comparison ... _encodings
Кодировки UTF-9 и UTF-18 - традиционный шуточный первоапрельский RFC-стандарт.

FeyFre
Спасибо Большущее! Теперь Разобрался Полностью

Кстати, а какой в этом смысл?

Зачем преднамеренно портить файл?
Разве нельзя, сохраняя из одного формата ASCII в другой, оставлять в файле тот же набор байтов?
Клиенту не всё равно, откроется к него знаки вопроса, или спецсимволы другой кодировки?

"Кодировочные" монстры, помогите разобраться!
Извлекаю доки в виде XML из своей системы (у меня они в utf-8 - это общеизвестно, да и stream при извлечении говорит, что charset="Unicode").
Запихую эти данные в Oracle, они (русские буквы) отображаются правильно, но програмеры, которые делают разбор с помощью MS XML Parser'а, говорят, что кодировка у меня windows-1251.
Всё работает, но на других системах с другими настройками может быть печально.. потому выгрузил stream на диск, открыл в AkelPad'е, а он внизу отображает: Unix | 1251 (ANSI - кириллица).
Так в каком формате всё-таки мои данные? Я в стопоре...

VladSh
Если символы в AkelPad'е отображаются правильно (и русские, и латинские), то кодировки именно та, что показывает AkelPad в строке состояния.

Instructor, да, всё корректно отображается.
А что тогда означает надпись Unix чуть левее?