Text division by specifying character count/limit value (compatible with Twitter 140 characters) | ZeroTools

This tool provides a browser-based processing function that divides long text into multiple blocks based on conditions specified by the user.

The input area placed on the "Slice & Split Board" on the left side of the screen reacts in real time to pasted or directly input text, and immediately reflects the split results in the preview area on the right side.

The unified core splitting engine is now shared across both the Japanese and English interfaces, ensuring uniform segmenting behavior regardless of locale settings.

The "1 block character limit", which is the standard for splitting, can be adjusted in the numeric input field within a valid range of 10 to 10,000 characters, measured strictly in JavaScript UTF-16 code units.

Because these units represent code unit lengths rather than graphical symbols, basic multilingual plane characters count as 1, while supplementary emoji scalar values count as 2.

Rather than using an obsolete fixed 8-character reservation or an arbitrary 10-character minimum body override that could cause total block overflow, the tool dynamically reserves the exact string length required by the maximum possible sequential marker for the thread.

When numbering is enabled, the system computes the necessary marker width based on candidate segment counts, re-evaluating and recomputing iteratively if increasing block counts increment the total number of digits until the index allocation stabilizes.

Every single emitted chunk, strictly including its attached sequential numbering marker and separating space, is guaranteed not to exceed the configured character limit.

If the user sets an extremely tight limit where the calculated numbering prefix or suffix leaves insufficient space to place even a single whole codepoint of text body, the engine will halt processing and display an explicit error requesting the user to widen the character limit or disable numbering, rather than silently truncating or corrupting the input.

As options for split unit boundary priorities, three options are supported: "Specified character count", "Sentence unit", and "Paragraph unit".

When "Specified character count" is selected as the split unit priority, a boundary correction algorithm operates to avoid crude mid-word breaks caused by fixed numeric slicing.

The system first determines the candidate segment that fits within the effective body budget (the total configured limit minus the dynamically reserved marker length).

It then establishes a boundary search region spanning the final 25% of this budget block to locate natural linguistic division points.

Within this terminal quarter, the engine scans from left to right and selects the first (leftmost) punctuation mark encountered—including Japanese full-width punctuation marks (。, ．, ！, ？) and standard Western marks (., !, ?), as well as line breaks.

Crucially, character mode does not perform sentence-level punctuation grouping: if a repeated punctuation run such as ... or !? appears in the search region, the slice is placed immediately after the very first punctuation mark, while subsequent marks remain at the start of the next chunk without deletion.

If no punctuation mark or newline is found within the search region, the scanner searches for the last ASCII space ( ) in that region and sets the boundary immediately after it.

Only when neither punctuation, newline, nor space exists within the final 25% window does the algorithm utilize the full body budget.

If a cut lands between a high and low surrogate, the boundary retreats by 1 code unit so that well-formed UTF-16 surrogate pairs remain intact, though no multi-codepoint grapheme cluster integrity is guaranteed.

After chunk extraction, leading and trailing whitespace is trimmed. Internal consecutive spaces inside the body are preserved, but edge whitespace is removed.

For instance, with a body budget of 10 and no numbering, inputting "12345678.?abc" targets the search region between characters 9 and 10; finding the period at position 9, it splits into "12345678." and "?abc".

Because character mode prioritizes natural boundary readability over maximal chunk packing without punctuation grouping, the leftover question mark cleanly opens the subsequent chunk rather than forcing an awkward mid-word cut or swallowing delimiters.

When "Sentence unit" or "Paragraph unit" mode is selected, the engine chunks text using hierarchical structural boundaries rather than rigid slicing.

In "Sentence unit" mode, text is tokenized by recognizing punctuation marks (。．！？.!?), grouping consecutive punctuation while retaining leading punctuation marks.

In "Paragraph unit" mode, text is segmented by newline sequences (\n+). The engine then performs greedy aggregation into chunks.

If the next candidate unit fits within the total body budget but exceeds the remaining room of the active chunk, the system flushes the current chunk and places the entire next unit into a brand-new chunk.

Fallback character splitting occurs only when a single trimmed unit independently exceeds the full body budget. Within chunks, combined sentences are separated by single ASCII spaces, and combined paragraphs are separated by double newlines (\n\n).

However, when an oversized single unit undergoes fallback character splitting, the resulting fragment pieces are never joined with extra artificial spacing.

This greedy grouping strategy packs content cleanly and predictably, though it does not guarantee mathematically optimal bin-packing across the thread.

Furthermore, because marker reservation assumes the maximum thread index, earlier chunks may carry a minor conservative margin. Consider a body budget of 10 with no numbering containing two 6-character paragraphs, "aaaaaa" and "bbbbbb".

Joining them requires a two-character newline sequence ("\n\n"), reaching 14 characters total; because this exceeds 10, the engine flushes the first paragraph into its own intact block and places the second into the next block.

Conversely, if an indivisible unit spans 12 characters (e.g., "aaaaaaaaaaaa"), fallback slicing splits it strictly into pieces of 10 and 2 characters without inserting artificial spaces or hyphens across the break.

Deliberate whitespace normalization strips edge blanks while leaving these internal raw boundaries uncorrupted.

After the split boundaries are settled, sequential index numbering is appended or prepended according to the configured "Thread sequential number format" ("None", "Prefix (1/3)", "Suffix (1/3)", "Prefix 1/", or "Suffix 1/").

To prevent format overflow, the engine calculates the dynamic reservation width using the maximum index marker (for example, (100/100) rather than (99/100)), including any required whitespace separator.

This reservation buffer only grows when an increased segment count requires more digits; once the required marker width is less than or equal to the reserved width, calculation stops.

Because adjusting marker reservations alters available body budgets and can shift preferred punctuation boundaries, segment counts may fluctuate slightly, so fixed-point equality or maximal packing is not guaranteed.

Every emitted block, including its marker and separator, is guaranteed not to exceed the configured maximum limit. If the marker leaves insufficient room for even the next whole code point (or surrogate pair), processing terminates with all output emptied and an error displayed.

In the thread preview, counters show exact UTF-16 code units, and visual amber warnings trigger whenever the block length satisfies len > limit - 10.

When copying results, blocks are joined by double newlines (\n\n), but due to trimming and normalization, original whitespace is not preserved byte-for-byte.

In the thread preview, counters show total UTF-16 code units including all markers and separators. For example, generating a 10-chunk thread requires reserving 8 units for suffix notation like " (10/10)" (7 characters plus 1 separator space).

Under a tight limit of 10, this leaves a body budget of only 2 units—enough to accommodate a single 2-unit surrogate pair, but not two pairs.

Furthermore, if a text split expands from 99 to 100 blocks, the maximum marker widens from " (99/99)" to " (100/100)", triggering an iterative recalculation pass with reduced body room.

Because these dynamic reservations take a conservative upper bound, the tool never guarantees a mathematically minimal chunk count.

Additionally, copying text does not trigger automatic SNS posting, remaining strictly a manual clipboard export.

Character counting and boundary slicing throughout the engine are evaluated strictly in standard JavaScript UTF-16 code units via String.prototype.length.

Basic ASCII, Latin symbols, standard Japanese kana, and common CJK ideographs in the Basic Multilingual Plane count as 1 code unit, whereas supplementary plane characters—such as astral symbols, historic kanji, and standard emoji—count as 2 code units.

The slicing logic guarantees that well-formed UTF-16 surrogate pairs from valid input will never be split across chunk boundaries.

However, the engine does not validate or repair pre-existing unpaired surrogates in non-empty input strings, nor does it guarantee the integrity of complex grapheme clusters such as Zero-Width Joiner (ZWJ) sequences, skin-tone modifier sequences, or composite regional indicator flag symbols.

Furthermore, this internal code unit length does not correspond to independent platform-specific counting rules (such as custom weighted characters or fixed-length link transformations used by external social networks), UTF-8 encoded byte sizes, or BPE subword tokens used by large language models.

The browser-based engine processes inputs entirely on the client side without remote server transmission, but no universal browser performance guarantee is provided for massive inputs.

Users can copy an individual text block or copy all formatted blocks joined together in a single action. The "Individual Copy" button, which copies individual blocks, extracts only the text of the corresponding index and writes it to the clipboard with one click.

Clipboard write completion is fully awaited before displaying success, while an explicit pending status indicates in-progress writes and an accessible read-only manual selection area appears if automatic copying fails.

Status notices reflect only the latest initiated user request, though notification consistency does not guarantee external clipboard ordering or paste success against concurrent OS clipboard operations.

Any text editing, configuration modification, or sample loading immediately invalidates pending requests, active indicators, manual fallback text, and countdown timers.

On the other hand, the "Copy All" function combines all the split chunks with double line breaks and exports them at once as one giant text stream.

When using these output functions, it is necessary to understand that the line break structure and consecutive blank character formats of the original input text cannot be perfectly restored (they are irreversible).

In the processing pipeline of this tool, trimming of the front and back is forcibly executed during the boundary correction of each block and the decomposition process of sentences and paragraphs.

As a result, intentional indentation, spaces for design purposes, and consecutive decorative line breaks are deleted, and are replaced with half-width spaces or double line breaks defined by the system in the final output.

Also, although a UI resembling an SNS post is rendered using a dummy avatar and profile connection line, there is no function to post to SNS.

The series of conversion processes for the input data is executed within your browser environment. How to manage and distribute the text output after conversion is left to the user's own manual operations through the clipboard.