Bulk extraction of specific characters and information (email/URL/phone number, etc.) using regular expressions | ZeroTools

The bulk character extraction tool using regular expressions utilizes the RegExp object, which is the JavaScript (ECMAScript) regular expression engine built into the user's browser by default, to extract specific patterns from lengthy input text.

The greatest characteristic of this mechanism is that evaluation processing is offloaded to a dedicated Web Worker running locally on client memory, without relying on server-side infrastructure or external processing APIs.

This extraction component verifies matches in the browser's memory without sending the input text to external parsing APIs. However, this is distinct from page delivery and overall site communication, and confidential information must be handled in accordance with the policies of the usage environment.

On the other hand, since this tool strictly operates in compliance with the specifications of the JavaScript RegExp object, care must be taken that it does not have full compatibility with regular expression dialects implemented in other programming language environments.

For example, specific formats of backreferences or advanced zero-width matches may not function as intended depending on the browser's execution environment.

Also, when processing Unicode character groups containing surrogate pairs or character boundaries unique to UTF-16 encoding, it is strongly affected by JavaScript-specific specifications.

Note that Unicode-aware flags cannot be arbitrarily specified in this UI, which only allows configuring the g, i, and m flags, so building patterns targeting multilingual text requires syntax based on standard JavaScript specifications without relying on arbitrary unicode flags.

In the evaluation engine of this tool, the global match flag (g flag) is always applied implicitly and permanently to the regular expression pattern entered in the text box.

This ensures that the process does not terminate when the first match is found in the input text, but instead maintains the search state continuously until the end of the text stream, comprehensively capturing all applicable strings.

Extraction and match highlighting reuse the identical match results produced by the Dedicated Worker. Whenever text is input or the setting options described below are changed, the tool cancels prior in-flight requests and dispatches evaluation to the Worker, updating the preview screen and extracted results while maintaining existing capture group fallback, deduplication, and output formatting rules.

Furthermore, depending on the extraction requirements, two main optional flags can be toggled arbitrarily from the UI, with both being initially enabled by default.

When the "Ignore case (i flag)" option is enabled, uppercase and lowercase alphabets are treated as identical for match determination, simplifying pattern writing and easily absorbing notation variations.

In addition, when the "Multi-line match supported (m flag)" is enabled, the meanings of the caret (^) and dollar sign ($) in regular expressions are expanded to match not only the very beginning and end of the entire text, but also immediately after and before newline characters.

By appropriately combining these flags, even in cases where each line of a log file is treated as an independent record, it becomes possible to smoothly perform partial extraction work based on intended line starts and ends.

In extraction tasks using advanced regular expressions, there is frequently a desire not only to acquire the entire string matched by the pattern as-is, but also to isolate and extract only specific components within the pattern.

In addition to output based on the full match of the input regular expression pattern, this tool supports an extraction mechanism for capture groups using parentheses.

By enabling the "Extract only capture groups" toggle from the settings panel and specifying a group index (integer numbers 1 to 9 from the UI), the final output result is constructed by extracting only the element of the corresponding number from the array of matched results.

As a concrete application example, if you want to collect only the domain portions from a massive email address list using a pattern like ([a-zA-Z0-9._-]+)@([a-zA-Z0-9.-]+\.[a-zA-Z]+), specifying 2 for the group index allows you to extract and list only the substring after the @ symbol.

Internally, it utilizes the JavaScript String.prototype.matchAll() method, iterating over the entire text to sequentially obtain all match results and their accompanying capture group information.

However, if the capture group of the specified index evaluates to undefined, it falls back to outputting the entire matched string.

An empty capture, on the other hand, correctly maintains an empty string. Therefore, when designing patterns with complex nested structures, careful consideration of the matching behavior is necessary.

Much of the extracted string data is output on the premise that it will not simply be viewed, but reused in subsequent data processing procedures or other applications.

It is common for the same error codes or the same email addresses to appear multiple times within the same access log file or lengthy document.

This tool comes standard with a hash-based deduplication feature that utilizes the characteristics of the JavaScript Set object, which retains insertion order using exact case string matching.

By enabling this setting, duplicate string elements are removed from the extracted array, generating a pure dataset consisting only of unique values.

The organized data group can be formatted into the optimal delimiter format tailored to the linked application's requirements. The available output formats are Line break separated, which is easy to handle in text editors; Comma separated and Space delimiter, which simply join the data without CSV escaping or shell quoting; and a JSON array that properly escapes values for direct use in parsing processes.

Data to which the output format has been applied can be copied to the clipboard with a single click. The copy button shows a success message for about two seconds only after the Clipboard API completes.

If copying fails, an error message is displayed so you can manually select and copy the extraction results. Alternatively, the data can be packaged as a Blob object on the browser and directly downloaded and saved as a local text or JSON file.

To assist users handling regular expression syntax for the first time, or users who want to quickly extract common formats frequently appearing in business, this tool has 8 built-in preset patterns, including "Standard email address format", "Web link starting with http:// or https://", "Landline and mobile phones", "Japanese postal code", "IP from 0.0.0.0 to 255.255.255.255", and "Date format separated by hyphens or slashes".

These preset patterns are designed and tuned primarily to efficiently carve out candidate string groups from large amounts of chaotic text data by simply identifying the formal characteristics and structures of the target strings.

However, what these preset patterns provide is merely an extraction based on string pattern matching; they do not have the capability to verify the authenticity, reachability, or validity of the extracted target data.

For example, the date preset pattern matches combinations of numbers and hyphens like YYYY-MM-DD, but does not include logic to determine dates that actually exist on a calendar.

While the IPv4 pattern structurally restricts each octet to a numerical range of 0 to 255, no network action is taken to check if the address is actually allocated or reachable.

Similarly, there is no verification for URL reachability or whether a phone number is actually contracted. The phone and postal codes are formatted specifically for Japan.

Because these presets remain solely for extracting string candidates, it is recommended to utilize them as an aid for primary filtering rather than for strict application input validation.

While the processing mechanism in the local environment using the browser's JavaScript engine is convenient, highly responsive, and requires no special execution environment setup, it inherently directly suffers from the hardware resources of the execution environment and browser-specific thread management limitations.

Because this tool is reactively designed to evaluate regular expressions asynchronously via a Dedicated Worker, previous evaluation requests are cancelled when inputs change, preventing long-running tasks from locking the browser's main thread.

Furthermore, rendering always safely HTML escapes raw text even when the pattern is empty or invalid, never passing unsanitized raw HTML to the DOM.

Limits are placed on input scale, including up to 2,000 pattern characters, 100,000 UTF-16 code units of text, up to 5,000 matches, and an estimated 8 MiB limit on result characters.

In particular, regular expressions that deeply nest quantifiers such as asterisks or pluses, or patterns that heavily use repetitions of ambiguous string boundaries, become factors causing exponential explosions in computational complexity known as ReDoS (Catastrophic Backtracking).

If such high-load patterns are executed against lengthy text, the Dedicated Worker enforces a 1,000 ms execution deadline and terminates the worker if exceeded, without falling back to synchronous execution on the main thread if Workers are unavailable.

Therefore, when building a complex regular expression anew, it is important to verify the validity of the match and processing speed.

By being mindful of appropriately grained data partitioning and writing patterns that do not burden the engine, stable data extraction work can be sustained within the operational boundaries of the browser environment.