<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[建议放弃“满码”这个概念]]></title><description><![CDATA[<ul>
<li>“满码”在这里应该说的是四码，这个可以拆分成几个参数：</li>
</ul>
<ol>
<li>自动上屏码长=4，四码候选唯一且无后续编码自动上屏，0表达不自动上屏</li>
<li>空码顶屏码长=4，五码空码且无后续编码顶前四码首选上屏，0表达不顶屏</li>
<li>空码清屏码长=4，四码空码且无后续编码自动清屏，0表达不清屏</li>
</ol>
<ul>
<li>这样更具灵活性和统一性</li>
</ul>
<ol>
<li>空码时显示后续编码，就不会被“满码”这一特性切断</li>
<li>通配符也不会在四码后续编码里不起作用</li>
<li>让四码方案能通过特定编码引导更长编码做特殊引导码表时也保持同一特性</li>
<li>通过参数变化还能支持顶功方案</li>
</ol>
]]></description><link>https://forum.windinput.com/topic/290/建议放弃-满码-这个概念</link><generator>RSS for Node</generator><lastBuildDate>Mon, 19 Oct 2026 16:01:16 GMT</lastBuildDate><atom:link href="https://forum.windinput.com/topic/290.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 08 Oct 2026 06:22:38 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 建议放弃“满码”这个概念 on Fri, 09 Oct 2026 12:43:28 GMT]]></title><description><![CDATA[<p dir="auto">现在的全码和满码是同一个意思，但并不是固定的4码，只是现在的方案（比如：五笔），在方案配置时会配置自己的码长是4码，以及配置词组的生成规则，都依赖于这个数值。这样的目的主要是想兼容非4码长的方案。<br />
为了兼容快符，做了一个最小上屏的配置，也就是在4码长的方案下，指定长度无后续编码则上屏。</p>
<p dir="auto">其实你提的这些都是逻辑处理相关的问题</p>
]]></description><link>https://forum.windinput.com/post/1228</link><guid isPermaLink="true">https://forum.windinput.com/post/1228</guid><dc:creator><![CDATA[admin]]></dc:creator><pubDate>Fri, 09 Oct 2026 12:43:28 GMT</pubDate></item><item><title><![CDATA[Reply to 建议放弃“满码”这个概念 on Fri, 09 Oct 2026 10:44:14 GMT]]></title><description><![CDATA[<ul>
<li>
<p dir="auto">其实我是想建议更明确的表达，虽然我们习惯性默认四码类方案全码四码，但程序在细节处理上还是有差异的，同时也存在不同方案的不同需求。</p>
</li>
<li>
<p dir="auto">在清风里有几个上屏行为：<br />
全码唯一自动上屏、满码空码清空，这个“全码”、“满码”是一个概念吗？<br />
顶码上屏（超过最大码长时顶首选上屏），这里的“最大码长”可能和上面也是一个概念，都是指向4这个参数<br />
举个例，非码元的引导键方式都了解，比如便捷输入的日期金额，快符输入的符号，这都属于非码元方式的引导<br />
同时还有一种码元方式的引导（可以更广泛的适应软件，也可减少非码元键引导的占用，以及手感差别的考虑），比如利用某一个或某两个码元开始的编码，在这一方案编码体系中不会出现规则编码，而利用来作为另一辅助方案的引导编码，这一套编码可能就会突破四码范围，可能有六码、八码。<br />
这个例中，全码是四、六还是八？五笔中应该还有三码全码的吧？其他方案应该有不到四码就是全码的编码，那如果三码就是全码了且无后续编码是否会自动上屏？逻辑上这个词条满足了全码唯一且无后续应该自动上屏，但为了节奏上的统一通常我们会设置为4码时才开始这一行为，这时参数设四码就比全码这个概念更明确。<br />
所以“全码”、“满码”这样的概念表述不够清晰。</p>
</li>
<li>
<p dir="auto">行为不一致也讲一个码元引导方式（ok引导拼字码）的编码例：</p>
</li>
</ul>
<ol>
<li>oko打到这个码时，根据空码显示一位后续，会显示后续候选：𢠙uxb，这时是正常的，但当你打到第四码时，okou却没有显示这个后续候选了，这应该就是程序设定四码时不再执行这一条规则，正常应该不论码长，只要有后续就应该在空码时显示。<br />
<img src="/assets/uploads/files/1791542448653-794cbd73-d23d-47e6-a88a-31ff063f782a-image.png" alt="image.png" class="img-markdown  img-fluid" width="281" height="187" /><br />
<img src="/assets/uploads/files/1791542518431-7ed4f489-445b-45fd-a1cf-887169899aba-image.png" alt="image.png" class="img-markdown  img-fluid" width="396" height="230" /></li>
<li>上面同时在切分模式下也存在四码后的编码不被当作后续编码处理，直接在四码空码时就做了切分处理。<br />
<img src="/assets/uploads/files/1791542624024-3c8013bd-8721-49e5-8cba-f2b96949cdc3-image.png" alt="image.png" class="img-markdown  img-fluid" width="278" height="224" /><br />
<img src="/assets/uploads/files/1791542649282-844e3811-c88d-4deb-94f9-aa646d6dddf3-image.png" alt="image.png" class="img-markdown  img-fluid" width="326" height="218" /></li>
<li>通配符，到四码就被切断，无法支持后续编码的通配方式查询<br />
顺便说下通配符：<br />
①通配提示最好只提示通配符代替的那个码元，不要显示更多编码，否则视觉上无法直达目标<br />
②通配符的作用是充当任一码元，应当视同也是一个码元，不在自动上屏顶屏等功能上做特殊处理，保持行为的一致性</li>
</ol>
<ul>
<li>再讲一个顶功方案的支持<br />
顶码上屏，超过最大码长时顶首选上屏，这个最大码长应该也是四码，并不是真的最大码长，即从四码开始后续空码且无后续，开始顶。<br />
如果我的方案想设两码后空码且无后续开始顶，则无法设置这个参数（顶功方案）。少了一种方案的支持<br />
如果把这个“最大码长”实质化，比如四码方案设成参数4，就满足了四码方案的四码后空码无后续顶的需求，同时还能满足设置成参数2，两码后空码无后续顶</li>
</ul>
]]></description><link>https://forum.windinput.com/post/1225</link><guid isPermaLink="true">https://forum.windinput.com/post/1225</guid><dc:creator><![CDATA[flypy.cc]]></dc:creator><pubDate>Fri, 09 Oct 2026 10:44:14 GMT</pubDate></item><item><title><![CDATA[Reply to 建议放弃“满码”这个概念 on Fri, 09 Oct 2026 04:38:48 GMT]]></title><description><![CDATA[<p dir="auto">现在内部逻辑是差不多是这样的，只是对于这个满码，是按方案配置的码长来做的。<br />
自动上屏和空码也都对唯一和后续做了处理。<br />
当前并没有看到需要这样改的明确理由</p>
]]></description><link>https://forum.windinput.com/post/1213</link><guid isPermaLink="true">https://forum.windinput.com/post/1213</guid><dc:creator><![CDATA[admin]]></dc:creator><pubDate>Fri, 09 Oct 2026 04:38:48 GMT</pubDate></item></channel></rss>