|
|
By default, Chrome extensions are not allowed to access to pages stored on the filesystem. Therefore, you must enable the option "Allow access to file URLs" in the extension page to display the infobar when viewing a saved page, or to save a page stored on the filesystem.
|
|
|
-The self-extracting ZIP files created by SingleFile are essentially regular ZIP files. They take advantage of the flexibility in the ZIP specification, which allows for additional data to be included before and after the main payload. In the case of SingleFile, this feature is used to make the ZIP file appear as an HTML file. As a result, the resulting HTML page is technically invalid because it contains binary data (i.e. the ZIP payload), but it's within the bounds of the HTML specification to allow for such cases. Within this file, there is also a script designed to extract the ZIP payload when the page is opened in a web browser.
|
|
|
+The self-extracting ZIP files created by SingleFile are essentially regular ZIP files. They take advantage of the flexibility in the ZIP specification, which allows for additional data to be included before and after the main payload. In the case of SingleFile, this feature is used to make the ZIP file appear as an HTML file. As a result, the resulting HTML page is technically invalid because it contains binary data (i.e. the ZIP payload), but it's within the bounds of the HTML specification to allow for such cases. Within this HTML page, there is also a script designed to extract the ZIP payload when the page is opened in a web browser.
|
|
|
The purpose of this script is to interpret the ZIP payload as binary data, extract it, and then display the extracted page with its resources. Initially, the script can use the `window.fetch()` method to read the page in binary form. However, this method doesn't work as expected in Chromium-based browsers when the page is accessed from the local file system due to security restrictions. To circumvent this and when using the universal self-extracting ZIP format, the page is encoded in windows-1251, and binary data is directly retrieved from the Document Object Model (DOM). The choice to use windows-1251 encoding, rather than UTF-8, was made because, in UTF-8, any invalid characters are converted into the "U+FFFD REPLACEMENT CHARACTER," making it impractical for this specific purpose due to potential data loss. With windows-1251 encoding, all bytes can be successfully recovered. In any case though, all instances of CR (Carriage Return) and CR+LF (Carriage Return Line Feed) characters are replaced with LF (Line Feed) characters. As a result, additional data needs to be incorporated into the page to restore these characters. This task is accomplished by the `<sfz-extra-data>` tag, which contains both the necessary data and the offset specifying the start of the ZIP payload encoded in base64. Finally, because the zip standard tolerates no more than 64KB of random data after the payload, this tag is positioned at the end or beginning of the page (i.e. when it weighs more than 64KB).
|
Gildas