You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The normal JS string literal is limited in its information density, but if we have a control over the character encoding we can overcome this limitation. xem's int2binary2html has used ISO/IEC 8859-1 (Latin-1, l1) for example, which requires 88 bytes to decode:
b=i.charCodeAt(),b>>8?"€ ‚ƒ„…†‡ˆ‰Š‹Œ Ž ‘’“”•–—˜™š›œ žŸ".indexOf(i)+128:b// note that the string literal above is also encoded in Latin-1 so they are one byte per character.
After some testing I concluded that ISO/IEC 8859-5 (cyrillic) is a better choice, which can be decoded in 44 bytes of code due to its regular assignment:
b=i.charCodeAt(),b>>8?b%3683-864:b-167?b:253
Unlike 8859-1 we need to declare the character encoding for 8859-5, but <meta charset=cyrillic> is only 23 bytes long so it is still better than 8859-1.
A critical problem with this approach is that the server-side header is preferred over the client-side metadata, so it is very sensitive to the server setting. In the case of js13kGames the server originally didn't declare the character encoding but it now does, breaking past entries that have used this technique.
The text was updated successfully, but these errors were encountered:
The normal JS string literal is limited in its information density, but if we have a control over the character encoding we can overcome this limitation. xem's int2binary2html has used ISO/IEC 8859-1 (Latin-1,
l1
) for example, which requires 88 bytes to decode:After some testing I concluded that ISO/IEC 8859-5 (
cyrillic
) is a better choice, which can be decoded in 44 bytes of code due to its regular assignment:Unlike 8859-1 we need to declare the character encoding for 8859-5, but
<meta charset=cyrillic>
is only 23 bytes long so it is still better than 8859-1.A critical problem with this approach is that the server-side header is preferred over the client-side metadata, so it is very sensitive to the server setting. In the case of js13kGames the server originally didn't declare the character encoding but it now does, breaking past entries that have used this technique.
The text was updated successfully, but these errors were encountered: