Twitter 文本压缩挑战
规则
- 您的程序必须有两种模式:编码和解码。
当编码时:
- 您的程序必须将一些人类可读的
Latin1
文本(大概是英语)作为输入。- 忽略标点符号也没关系。
- 您只需要担心实际的英语单词,而不是 L337。
- 任何带重音的字母都可以转换为简单的 ASCII。
- 您可以选择处理数字的方式。
- 123
- 一二三
- 一百二十三
- 123
- 1 2 3
- 一百二十三
- 一二三
- 一百二十三
- 123
- 1 2 3
您的程序必须输出一条可以用以下形式表示的消息
U+0000
–U+10FFFF
范围内有 140 个代码点排除非字符:
U+FFFE
U+FFFF
U+
n
FFFE
、U+
n
FFFF
,其中n
为1
–10
十六进制U+FDD0
–U+FDEF
U+D800
–U+DFFF
(代理代码点)。
它可以以您选择的任何合理的编码输出; GNU
iconv
支持的任何编码都将被视为合理, 并且您的平台本机编码或区域设置编码可能是一个不错的选择。- 您的程序必须将一些人类可读的
当解码时:
- 您的程序应将编码模式的输出作为输入。
- 文本输出应该是输入文本的近似值。
- 越接近原文越好。
- 不需要任何标点符号。
输出文本应该是人类可读的,同样是英语。
- 可以是 L337,或者哈哈。
- 解码过程可能无法访问编码过程的任何其他输出 除了上面指定的输出之外; 也就是说,你不能将文本上传到某处并输出 URL 用于下载解码过程,或类似的愚蠢的事情。
- 为了用户界面的一致性,您的程序必须表现如下:
- 您的程序必须是一个可以设置为在具有适当解释器的平台上可执行的脚本, 或可以编译为可执行文件的程序。
- 您的程序必须将
encode
或decode
作为其第一个参数来设置模式。 - 您的程序必须至少通过以下方式之一获取输入:
- 从标准输入获取输入并在标准输出上生成输出。
我的程序编码
output.utf 我的程序解码
output.txt
- 从第二个参数中指定的文件中获取输入,并在第三个参数中指定的文件中生成输出。
我的程序编码输入.txt 输出.utf
我的程序解码output.utf output.txt
- 从标准输入获取输入并在标准输出上生成输出。
- 对于您的解决方案,请发布:
- 您的完整代码和/或其他地方托管的代码链接 (如果它很长,或者需要编译很多文件,或者其他什么)。
- 解释它是如何工作的(如果从代码中看不出来) 或者如果代码很长并且人们会对摘要感兴趣。
- 示例文本,包含原始文本、压缩后的文本以及解码后的文本。
- 如果您的想法是基于别人的想法,请注明出处。 尝试改进别人的想法是可以的,但你必须归因于他们。
这些规则是 Twitter 图像编码挑战规则的变体。
Rules
- Your program must have two modes: encoding and decoding.
When encoding:
- Your program must take as input some human readable
Latin1
text, presumably English.- It doesn't matter if you ignore punctuation marks.
- You only need to worry about actual English words, not L337.
- Any accented letters may be converted to simple ASCII.
- You may choose how you want to deal with numbers.
- 123
- one two three
- one hundred twenty three
- 123
- 1 2 3
- one hundred twenty three
- one two three
- one hundred twenty three
- 123
- 1 2 3
Your program must output a message which can be represented in
140 code points in the range
U+0000
–U+10FFFF
Excluding non-characters:
U+FFFE
U+FFFF
U+
n
FFFE
,U+
n
FFFF
wheren
is1
–10
hexadecimalU+FDD0
–U+FDEF
U+D800
–U+DFFF
(surrogate code points).
It may be output in any reasonable encoding of your choice;
any encoding supported by GNUiconv
will be considered reasonable,
and your platform native encoding or locale encoding would likely be a good choice.- Your program must take as input some human readable
When decoding:
- Your program should take as input the output of your encoding mode.
- The text output should be an approximation of the input text.
- The closer you can get to the original text, the better.
- Doesn't need to have any punctuation.
The output text should be readable by a human, again presumably English.
- Can be L337, or lol.
- The decoding process may have no access to any other output of the encoding process
other than the output specified above;
that is, you can't upload the text somewhere and output the URL
for the decoding process to download, or anything silly like that.
- For the sake of consistency in user interface, your program must behave as follows:
- Your program must be a script that can be set to executable on a platform with the appropriate interpreter,
or a program that can be compiled into an executable. - Your program must take as its first argument either
encode
ordecode
to set the mode. - Your program must take input in at least one of the following ways:
- Take input from standard in and produce output on standard out.
my-program encode <input.txt >output.utf
my-program decode <output.utf >output.txt
- Take input from a file named in the second argument, and produce output in the file named in the third.
my-program encode input.txt output.utf
my-program decode output.utf output.txt
- Take input from standard in and produce output on standard out.
- Your program must be a script that can be set to executable on a platform with the appropriate interpreter,
- For your solution, please post:
- Your code, in full, and/or a link to it hosted elsewhere
(if it's very long, or requires many files to compile, or something). - An explanation of how it works, if it's not immediately obvious from the code
or if the code is long and people will be interested in a summary. - An example text, with the original text, the text it compresses down to, and the decoded text.
- If you are building on an idea that someone else had, please attribute them.
It's OK to try to do a refinement of someone else's idea, but you must attribute them.
- Your code, in full, and/or a link to it hosted elsewhere
The rules are a variation on the rules for Twitter image encoding challenge.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
不确定我是否有时间/精力用实际代码来跟进,但这是我的想法:
如果超过这个长度,我们就会开始丢失文本中的信息。 因此,执行以下最少数量的步骤,将字符串减少到可以使用上述方法进行压缩/编码的长度。 另外,如果仅在子字符串上执行这些替换将使字符串足够短(我可能会向后遍历字符串),则不要对整个字符串执行这些替换。
好的,现在我们已经消除了尽可能多的多余字符。 现在我们要做一些更戏剧性的减少:
好的,这就是我们可以做到的让文本可读的程度。 除此之外,让我们看看是否可以想出一种方法,使文本类似于原始文本,即使它最终无法可解读(再次执行此操作)从字符串末尾开始一次一个字符,当足够短时停止):
这应该会留下一个由 5 个可能值(a、l、n、p 和空格)组成的字符串,这应该允许我们编码相当长的字符串。
除此之外,我们只需要截断即可。
我能想到的唯一其他技术是对常见单词或字母组进行基于字典的编码。 这可能会给我们一些正确句子的好处,但可能不会给任意字符串带来好处。
Not sure if I'll have the time/energy to follow this up with actual code, but here's my idea:
Anything longer than that, and we're starting lose information in the text. So execute the minimum number of the following steps to reduce the string to a length that can then be compressed/encoded using the above methods. Also, don't perform these replacements on the entire string if just performing them on a substring will make it short enough (I would probably walk through the string backwards).
Ok, so now we've eliminated as many excess characters as we can reasonably get rid of. Now we're going to do some more dramatic reductions:
Ok, that's about as far as we can go and have the text be readable. Beyond this, lets see if we can come up with a method so that the text will resemble the original, even if it isn't ultimately deciperable (again, perform this one character at a time from the end of the string, and stop when it is short enough):
This should leave us with a string consisting of exactly 5 possible values (a, l, n, p, and space), which should allow us to encode pretty lengthy strings.
Beyond that, we'd simply have to truncate.
Only other technique I can think of would be to do dictionary-based encoding, for common words or groups of letters. This might give us some benefit for proper sentences, but probably not for arbitrary strings.
这是我的实际英语变体。
每个代码点都有大约 1100000 种可能的状态。 嗯,空间很大。
因此,我们对所有原始文本进行词干并从中获取 Wordnet 同义词集。 数字被转换成英文名称(“四十二”)。 1,1M 个状态将允许我们保存 synset id(可以在 0 到 82114 之间)、synset 内的位置(我想大概有 10 个变体)和 synset 类型(这是四种类型之一 - 名词、动词、形容词、副词) 。 我们甚至可能有足够的空间来存储单词的原始形式(例如动词时态 ID)。
解码器只是将同义词集提供给 Wordnet 并检索相应的单词。
源文本:
变为:(
使用 Online Wordnet 测试)。 这个“代码”应该有 27 个代码点。
当然,所有像“lol”和“L33T”这样的“胡言乱语”都将永远丢失。
Here is my variant for actual English.
Each code point have something like 1100000 possible states. Well, that's a lot of space.
So, we stem all original text and get Wordnet synsets from it. Numbers are cast into english names ("fourty two"). 1,1M states will allow us to hold synset id (which can be between 0 and 82114), position inside synset(~10 variants, i suppose) and synset type (which is one of four - noun, verb, adjective, adverb). We even may have enough space to store original form of word (like verb tense id).
Decoder just feeds synsets to Wordnet and retrieves corresponding words.
Source text:
Becomes:
(tested with Online Wordnet). This "code" should take 27 code points.
Ofcourse all "gibberish" like 'lol' and 'L33T' will be lost forever.
PAQ8O10T《》 FTW
PAQ8O10T << FTW
这是一个简单的示例,它采用输入文件并删除所有非单词字符。
Here is a simple example that takes an input file and removes any non-word characters.