Selection of International and Japanese
This tool handles the Morse encoding and decoding of International text (alphabets, numbers, symbols) and Japanese Wabun text (hiragana, katakana).
When the input mode is set to "Text ⇒ Code", the INTERNATIONAL_MAP or WABUN_MAP is referenced. In International mode, strings are normalized using normalize('NFKC') and converted to uppercase, with characters mapped to dot (.) and dash (-) sequences.
In Wabun mode, preprocessing is performed for voiced marks, semi-voiced marks, and small kana, processing both hiragana and katakana under the same system.
The Wabun mode utilizes a non-overlapping Wabun code table. It includes examples where unique alternative codes are assigned based on the legal Wabun table, such as ..-.. for "ト", ..-. for "チ", and -.--. for "ル".
Support for the Japanese long vowel mark (ー) and numbers is considered, processing expressions unique to Wabun. The text input limit is set to 5,000 UTF-16 code units, which is constrained by the UI maximum length and string slicing.
The conversion process is executed within the browser's JavaScript engine, and the input text data is not sent to an external server for this purpose.
Kana, Dakuten, and Unsupported Characters
We will detail the normalization of characters in the Wabun mode and the handling of unsupported characters common to both modes.
The Japanese Wabun Morse code has a characteristic of expressing voiced and semi-voiced sounds by splitting them into two characters: the basic unvoiced sound and a dakuten code (..) or a handakuten code (..--.).
This tool applies Unicode normalization (NFD) to the input text to separate dakuten (U+3099) and handakuten (U+309A) from the base characters.
Furthermore, small kana (ぁ, ぃ, ぅ, etc.) are replaced with their corresponding large kana (ア, イ, ウ, etc.), losing their distinction.
This imitates the practice in traditional Wabun Morse communication where small kana are not strictly distinguished. On the other hand, if characters that are not defined in the current code table, such as kanji, are input, the tool does not implicitly delete them.
Instead, it outputs them by replacing them with a ? symbol indicating an unknown character. This visually clarifies the parts that could not be converted, allowing users to recognize the fact that unsupported characters were included in the original text.
Also, if you attempt to play a code sequence containing a ? directly (other than valid dots, dashes, and spaces), it will result in a playback error because the correct unit time cannot be calculated, and the audio output will be rejected and interrupted.
This prevents broadcasting with incorrect encoding. To assist in reliable mapping from characters to codes, users must discover and correct unsupported characters directly through text input.
Delimiters for Decoding from Code
We will explain the parsing process and delimiter rules in the "Code ⇒ Text" mode. When decoding Morse code back into text, the tool determines the boundaries between characters and words based on the number of spaces in the input string.
In terms of implementation, it processes the spaces assuming 1 space between characters and 3 spaces between words. When reverse-converting from code to text, a mapping object is generated with the keys and values of the International or Wabun code tables inverted, and it is checked against the input code sequence.
During the reverse conversion in Wabun mode, after the separated base characters and dakuten/handakuten codes are textualized, they are restored back into combined voiced/semi-voiced sounds (e.g., "カ" + "゛" -> "ガ") by using normalize('NFC').
However, as mentioned earlier, because small kana are normalized to large kana during conversion, they do not revert to small kana even when reverse-converted, meaning there are characters for which complete reversible conversion (round-trip) is not guaranteed.
Also, regarding some special characters like long vowel marks and symbols, if the space delimiters are inaccurate, they might be misrecognized as a different character array, so appropriate space insertion is required when inputting codes.
In this way, the parsing process from Morse code to text operates heavily dependent on the accurate counting of input space characters and the behavior of the normalization algorithm.
Presets and Round-trip Confirmation
To help users intuitively understand the operation, several preset values are provided in this tool. You can set representative strings into the input area with a single button, such as "SOS", "HELLO WORLD", and "CQ CQ CQ" in International mode, or "タスケテ", "こんにちは", and "エスオーエス" in Wabun mode.
Even when these presets are loaded, the conversion process for the specified mode runs immediately, and the results are displayed in the output field.
The output code or text can be copied to the OS clipboard using the Clipboard API (navigator.clipboard.writeText). The copy process is executed asynchronously (await), and upon success, the button's icon temporarily changes to notify completion, while failure notifications are also caught and handled.
Additionally, since this tool manages the input value directly as state, you can perform a round-trip confirmation to see how your own input is decoded by copying the converted code, flipping the mode, and inputting it again.
This allows you to test whether word boundaries based on the number of spaces are recognized correctly. Particularly during Morse code learning, the round-trip verification to check if the code you typed returns to the expected text is highly useful.
Passing data via the clipboard is also helpful for integrating with external text editors, playing an important role as a function to continue work while saving input contents.
Sound, Light, and Speed Settings
We will explain the sound playback by an oscillator using the Web Audio API and parameter control. When the play button is pressed, the input code is first parsed into an event queue for playback.
The timing of Morse code follows the international standard ratio: dot 1, dash 3, intra-character silence 1, inter-character 3, and inter-word 7.
For example, in the case of "SOS" (... --- ...), calculating including this inter-character processing results in a total of 27 units (S=5 units, inter-character 3 units, O=11 units, inter-character 3 units, S=5 units).
The playback speed can be set in the range of 5 to 40 as WPM (Words Per Minute) (default value 20), and the number of seconds per unit (calculated as 1.2 / WPM) is derived from this value.
The tone pitch (frequency) can be adjusted in 50Hz increments from 400Hz to 1200Hz (default value 700Hz), allowing you to select a band that is easy for the user to hear.
The sound playback uses the OscillatorNode and GainNode of the AudioContext, and to prevent click noises, a very short gain envelope fade (linearRampToValueAtTime) is applied to the attack and release of the sound.
Also, an indicator on the screen lights up simultaneously with the audio, but since JavaScript's window.setTimeout is used as reference timing to control the light, it does not guarantee strict synchronization unlike the precise time management of AudioContext, and slight deviations in timing between sound and light emission may occur depending on the browser's execution status.
Stop mechanisms for timers, audio output, and mode switching are implemented.
Limitations for Practice Use
We will state the limitations on playback time and execution environment in this tool, as well as points to keep in mind regarding its limits for learning purposes.
An upper limit is set on the length of audio that can be played continuously. If a code sequence with a calculated total playback time exceeding 3 minutes (180 seconds) is input, the playback process will not start and an error message will be displayed.
If you want to confirm the conversion result of a long text with audio, you must divide the text before inputting. Also, while the conversion from characters to codes and the generation of audio waveforms in this tool are processed by JavaScript executed within the browser on your device, communications related to access analytics or other resource acquisitions may occur as part of the overall site behavior.
Therefore, it does not guarantee absolute security of the usage environment solely because of the in-browser processing, nor does it guarantee perfect operation in all offline environments.
It is designed merely as a supplementary tool to simulate the correlation between input strings and codes on the browser and obtain acoustic feedback via the Web Audio API.
It is not a substitute for official training equipment for operators or professional software required to meet legal standards. Please utilize it within the scope of learners visually and aurally confirming the structure and rhythm of codes for self-improvement.
It is recommended to use it with an understanding of the limitations dependent on Web technology, such as the load on the browser during continuous long-term sound generation or extremely fast WPM settings.