Bush hid the facts
Bush hid the facts is a common name for a bug present in some versions of Microsoft Windows, which causes text encoded in ASCII to be interpreted as if it were UTF-16LE, resulting in garbled text. When the string «Bush hid the facts», without quotes, was put in a new Notepad document and saved, closed, and reopened, the nonsensical sequence of Chinese characters » 畂桳栠摩琠敨映捡獴 » would appear instead.
While «Bush hid the facts» is the sentence most commonly presented on the Internet to induce the error, the bug can be triggered by other strings with letters and spaces in the same positions, for example «hhhh hhh hhh hhhhh» [1] or «this app can break» . [2] Other sequences trigger the bug as well, including simply the text «a » . [ citation needed ] (This most commonly used sentence is a reference to United States of America President George W. Bush’s statements about nuclear weapons in Iraq.)
The bug occurs when the string is passed to the Win32 charset detection function IsTextUnicode . IsTextUnicode sees that the bytes match the UTF-16LE encoding of assigned Unicode code points, concludes that the text is valid UTF-16LE, and returns true , and the application then incorrectly interprets the text as UTF-16LE. [3]
The bug had existed since IsTextUnicode was introduced with Windows NT 3.5 in 1994, but was not discovered until early 2004. [4] Many text editors and tools exhibit this behavior on Windows because they use IsTextUnicode to determine the encoding of text files. As of Windows Vista, Notepad has been modified to use a different detection algorithm that does not exhibit the bug, but IsTextUnicode remains unchanged in the operating system, so any other tools that use the function are still affected. [5]
Workarounds
Several workarounds exist for this bug:
- Editing the text to not be a pattern that triggers this bug will avoid it. For instance, adding a new line in the first 20 characters will work.
- If the file is saved as «UTF-8» (before 2018) or «UTF-8 with BOM» (after 2018) rather than «ANSI» the text loads correctly, because Notepad prepends a UTF-8 byte order mark, which is a pattern that does not trigger the bug. Opening a file that is valid UTF-8 without the byte order mark would still trigger the bug, as this sequence is represented identically in UTF-8 as in ASCII.
- The bug is also avoided by saving as «Unicode», which in Microsoft Windows means UTF-16LE. When loading this text IsTextUnicode should (and does) return true and the text is correct.
- To retrieve the original text using Notepad, bring up the «Open a file» dialog box, select the file, select «ANSI» or «UTF-8» in the «Encoding» list box, and click Open. Under Windows 2000, Notepad lacks the «Encoding» list box. Notepad2 also lacks this. WordPad appears to load the text correctly without choosing the encoding, since it uses its own encoding detection.
References
- ↑ Christensen, Brett M. (November 2, 2009). «Bush Hid The Facts — Notepad Conspiracy Claim» . http://www.hoax-slayer.com/bush-hid-the-facts-notepad.html .
- ↑ Kaplan, Michael S. (14 June 2006). «Behind ‘How to break Windows Notepad'» . http://blogs.msdn.com/b/michkap/archive/2006/06/14/631016.aspx .
- ↑ Chen, Raymond (March 24, 2007). «Some files come up strange in Notepad». Microsoft . https://devblogs.microsoft.com/oldnewthing/20040324-00/?p=40093 .
- ↑ Cumps, David (February 27, 2004). «Notepad bug? Encoding issue?». #region .Net Blog . http://weblogs.asp.net/cumpsd/archive/2004/02/27/81098.aspx .
- ↑ Kaplan, Michael S. (March 25, 2008). «Bush might’ve still hid the facts, but he can’t hide them from Vista SP1/Server 2008 Notepad» . http://archives.miloush.net/michkap/archive/2008/03/25/8334796.html .
External links
- The Notepad file encoding problem, redux – Raymond Chen
- IsTextUnicode – MSDN Library
Bush hid the facts что будет
Somebody immediately saying it’s an encoding error accompanied by several people «troubleshooting» by copy and pasting the resulting text to other programs, and ending off with someone three years later posting in all caps asking for help with a completely unrelated problem.
«As of Windows Vista, Notepad has been modified to use a different detection algorithm that does not exhibit the bug, but IsTextUnicode remains unchanged in the operating system, so any other tools that use the function are still affected.»
I find this line astonishing. I was hoping there would be more to this story than «we fixed Notepad and left OS function broken» but after following the reference it seems they just didn’t think it worth fixing.
The alternative is ‘my application could open this string just fine, and now it can’t anymore’. You can’t do heuristics without allowing mistakes and on the Windows platform backwards compatibility is considered very important.
I appreciate the responsibility for maintaining backward compatibility, but I got a different vibe from that blog post.
or they took the linus approach of «don’t break user space» and force every one else to fix their code because they fixed their code.
I’m glad UTF16 is (albeit slowly) going the way of the dodo by becoming just an internal representation for a few older toolkits and programming languages. It was incredibly nonsensical how inconvenient it was compared to UTF8. At least in UTF8 you can’t do the extremely wrong assumption that 1 (w)char == 1 character, or rather, you can do that but it will explode on your hands way sooner than with UTF16.
Even though, I must say that the fact that now Windows puts a useless BOM at the beginning of every file is very annoying.
UTF16 was an extension of the original «obvious» Unicode encoding, back when Unicode started and was defined as fitting the world’s languages into a 16-bit spec (what is now the Basic Multilingual Plane). UTF16 allowed (most) older UCS2 documents to be upgraded for free to UTF16, much the way that ASCII documents are also valid UTF8.
Some of the weirdness in the Unicode spec even comes from the need for backwards compatibility. 17 planes and 1,114,078 total usable codepoints. these numbers would not have been arrived if the system had the foresight that 16-bit wasn’t enough in the first place. They were derived from reassigning private use area codepoints into surrogate pairs for UTF16. Unicode would probably have rather (maybe should have) started out as a 32-bit spec and avoided this mess from the get-go.
You know I’d love to read a book about the Unicode standardization process. Unicode and the “16-bits is enough for all modern scripts” business must be one of the biggest failures of requirements analysis in computing history. And the fact that at the same time they were upsetting so many of their partners with Asian unification to me means there must have been a real issue with personalities and project responsibilities.
Well, probably not 32 exactly. They had a 31 bit spec at the time but decided they could simplify to 16 bits. Also UTF-8 is naturally optimized for 31 bits.
> just an internal representation for a few older toolkits and programming languages
Maybe «older» but very much current, Qt’s QString type internally uses UTF-16. https://doc.qt.io/qt-5/qstring.html
Yeah, because Qt started in the early 90s, when UCS2 hadn’t still fiascoed and it was being adopted in droves as the «newer» solution to all encoding issues — you simply swapped `char` for `wchar_t`, made a `w` version of every C and C++ IO function and that’s it, right?
Sadly, it wasn’t it. 16 bits weren’t enough, and stuff like the fact a Unicode rune ≠ printed character (i.e. [è] can either be a single codepoints, or a combination of a [`] modifier and the latin letter [e]) meant there was basically no point in using 16/32 bit chars in the first place. When people really understood this it was almost the ’00s, and stuff like Python, Windows, macOS (due to NextStep), Java, .NET, Qt were stuck. It’s impossible to go back to plain `char` without annihilating backward compatibility, so everyone kept using it internally.
Fun fact, some of those languages and frameworks I mentioned never bothered switching completely to UTF-16 — for instance, Python now uses a weird mixture of ASCII and UCS2 internally.
> for instance, Python now uses a weird mixture of ASCII and UCS2 internally.
Really? Last I heard (PEP 393), the rule was: «8 bits if all codepoints are less than 256 (i.e. Latin-1); 16 bits if all codepoints are less than 2^16 (i.e. BMP); otherwise 32 bits». This means that text with all Latin-1 characters (which are approximately the first 256 codepoints of Unicode) will be stored internally as, well, Latin-1. This implies that ASCII strings are stored as ASCII.
Yep, that’s what I meant. They either use ASCII, UCS2 or UCS4 depending on the type of string. Doesn’t make a lot of sense to me, but I guess they couldn’t just throw 16 bit chars away.
I’m not 100% sure on this, but I don’t backwards-compatibility mattered in this decision. They wanted memory-efficient and O(1)-indexable strings.
And both Java and Javascript, an thus any language derived from from them. I’d go as far as saying that a majority of the code being written today uses UTF-16.
With these languages not even providing alternative API’s that are easy to use means it’ll be some time before we don’t have to suffer this.
I’ve seen a trend from those languages and APIs of hiding UTF-16 away. They have to interoperate with everything else using just UTF8, while the rest of the world doesn’t give a half damn about UTF-16 (the fact you have to also take endianess into account I think was one of the biggest crippling blows 16 bit encoding had ever received)
> just an internal representation for a few older toolkits and programming languages.
One quite significant programming language being JavaScript — I know we have TextEncoder and TextDecoder now, and for the typical ways strings are used in JS this is a complete non-issue. But any context in which one would want to iterate over individual characters in strings in JavaScript there’s a chance one might end up having to deal with UTF16 quirks.
Iterating over characters is not that much more useful than iterating over code units, actually (the only sensible use cases I can think of right now are things you should never really have to worry about implementing at the application level, such as sorting or comparing strings). For many useful use cases you basically need grapheme clusters, which is a lot closer to what humans think of as a character. And once you’re at that point it’s much less relevant whether the code units are 8 or 16 bits wide.
Right, I forgot about both codePointAt and charCodeAt existing (the former being useful for what you are talking about, the latter what people used to have to deal with before ES2015).
This exactly. One of the biggest reasons why UTF-32 doesn’t make sense IMHO is not only its general overhead but the fact it reiterates on the broken concept of `char` == «glyph». That is never correct on Unicode, no matter the byte size, because so many characters can be spread over multiple codepoints. Iterating over codepoints is the only thing UTF-32 simplifies and it is honestly kinda pointless. That’s why it took a while for Rust to implement the `Chars` iterator.
Does anybody know what the Chinese characters say? I put them into Google Translate and got: «Kang 栠 栠 栠 栠 敨 ying picking mongoose». I’m guessing its gibberish, but sometimes you can’t trust machine translation.
I remember this one! I found it so fascinating and ended up spending a lot of time making up funny sentences which triggered the bug.
The wiki article does not say whether phrasing of the example as «Bush Hid the Facts» instead of using some other text, is related to the presidency of George W. Bush. It seems to be, or is it entirely unrelated?
IIRC it was related to 9/11 conspiracy theories. At the time, a lot of conspiracy garbage was forwarded through chain e-mail. This is one of two examples that I personally remember getting forwarded from a particular aunt (the «Bush Hid the Facts» text disappearing being «proof» for the whole inside job theory it presumably alludes to). The sort of stuff that aunt would nowadays share on that Face Website.
The other that I remember her sending me was along the lines of «OMG if you enter that planes flight number into MS Word 97 and set the font to Windings you get a picture of a plane, two buildings, a skull and a Star of David!!1!eleven».
On a side note: If you entered the right combination of text into Excel 97, you could fly a plane over a fractal landscape 😉
The kind of «logic» at work here is still used nowadays (e.g. the Sandy Hook school shooting conspiracy theory, with followers pointing towards the name appearing in a movie at the time). It still eludes me what the logic behind this is supposed to be. So if you plan a massive government conspiracy, you make sure to plant very precise, hidden clues all over the place in movies, TV shows, random office software and similar things years in advance, because. um. why exactly?
Indeed. These were very big in middle school computer labs circa 2005.
I wonder if anyone with more historical perspective knows of any older examples of these blatantly false theories from other eras or if this type of conspiracy theory is unique to the digital age?
Бложик Zukel’а
Пасхальное яйцо виндового Notepad’а. Третий сервис-пак не закрывает этой фичи.
Как проявляется
- Создаем новый текстовый документ.
- Пишем в нем «Bush hid the facts» («Буш скрыл факты» — англ).
- Сохраняем. Закрываем.
- Открываем, а в нем
скриншот с квадратиками
Если эту строку скопировать в любую программу, поддерживающую Rich Text Format, например стандартный Wordpad, то получим:
Перевод этой тарабарщины ни к чему понятному не приводит:
Chinese to English: Liu Benren got Tou motorized patrol videos seized
Japanese to English: 畂 桳 栠 摩 琠 敨 projection 捡 獴
Как ни крутите, а смысла здесь нет!
Версия
Я склоняюсь к тому, что это не пасхальное яйцо (задуманное послание от разработчиков), а просто баг. Если составить синтаксически схожую фразу, то получим тот же эффект. То есть составьте фразу из четырёх слов в латинской раскладке, в которой первое слово состоит их 4х букв, второе и третье из 3х, а пятое из 5ти. Попробуйте фразу «Zuks own the world». Получите:
Но вовсе не каждая фраза обладает этим свойством. Основной критерий —неоспоримая истина ��
P.S. Все боян, это правда. Однако я по своему поисковому запросу ответ не нашел. Так что моя страничка найдет своего читателя ��
Bush hid the facts что будет
Проверено на лицензионной Win-XP SP2
Часть «пасхальных яиц» из 98-х работает и в XP (скринсейверы)
Как выиграть в «Косынку»
Тупо нажмите Alt+Shift+2
(Alt лучше слева, двойку лучше не на цифровой клавиатуре, а над буквами)
Очков от этого, само собой, все равно будет ноль.
Что прячет Джордж Буш?
Внимание, работает только в XP!
1. Откройте Блокнот (Notepad).
2. Напишите в новом файле:
Bush hid the facts
3. Сохраните файл как bush.txt
4. Закройте Блокнот.
5. Теперь откройте bush.txt из того места, где сохранили.
Вместо сохраненного текста увидите символы-квадратики:
Промежность под фильтром?
1. ОткройтеПанель управления -> Речь
2. Наберите для пробы:
Crotch
В пробе услышите «Crow’s nest» — «Воронье гнездо».
Информация в этом блоке размещается на правах рекламы:
Последние обновленные разделы сайта:
27.10 РЕЦЕНЗИИ : Миссия невыполнима: Смертельная расплата, часть.1. Исчезнувшая в звездах. Оппенгеймер. Великая ирония. Луна. Звук свободы. Барби. Посредники. Сердце Стоун. Корабль призраков. Девичник: Убойная ночь. Жанна Дюбарри.
20.10 КИНОСТАТЬИ : Топор-3. Маленькие гиганты большого кино: 10 знаменитых актеров-карликов. Киноосень в Стране Басков: итоги фестиваля в Сан-Себастьяне. Жизнь замечательных людей: итоги Венецианского кинофестиваля. Премьеры мультфильмов. Все оттенки страха: 10 грядущих фильмов ужасов. 10 главных российских кинопремьер.
16.10 АНЕКДОТЫ : про кино — 219 стр., про Новый год — 69 стр., про интернет и компьютер — 325 стр., про рекламу — 197 стр.
06.10 ХОЛКИ-МОРКИ : 192 страница.
02.10 КИНОЛЯПЫ : Барби. Мать. Удача. Форсаж-10. Трансформеры-7: Восхождение Звероботов. Индиана Джонс и Колесо судьбы. Большой прыжок. Лютер: Павшее солнце. Крушение. Меню. Треугольник печали. Топ Ган: Мэверик. Не беспокойся, дорогая. Добыча. На западном фронте без перемен. Вышка.
ГЛАВНАЯ : Знаменательные даты, факты из мира науки и искусства обновляются на сайте ежедневно. Также на главной есть новости, не всегда попадающие в архивы и не связанные с остальными разделами.
Самые популярные разделы форума:
Новинки кино : Краткие обзоры новинок кинопроката и документальных фильмов.
Флудильня : разные темы, от «Придумайте название» до приколов типа «Скрипка-Лиса»
События в мире : новости из разных источников, иногда просто приколы и маразмы.
Кинояпы в зарубежных фильмах : Обсуждение статей соответствующей рубрики, предложения.