QR code reader (compatible with both image files and web cameras) | ZeroTools

QR code reading using an image file is realized through local processing that combines state management within a React component and standard Web APIs.

When the user selects the "Image File" tab (where the activeTab state is "upload") and specifies a file through the file selection dialog or drag-and-drop area, the handleImageUpload function is triggered.

In this process, the File object acquired from the input element (type="file", accept="image/*") is converted into a Base64 format Data URL string using the readAsDataURL method of the FileReader API.

Once the conversion to a Data URL is complete, the value is stored in the state variable uploadedImage within the onload event, and it is displayed as a preview image (by assigning the src to an img element) while simultaneously calling the decodeImage function for analysis.

In the decodeImage function, a new Image object is created, the Data URL is assigned to its src property, and it waits for the image to load.

After loading is complete (img.onload), a hidden canvas element (the DOM referenced by imageCanvasRef) that is not displayed on the UI is used as a buffer for image analysis.

At this time, the naturalWidth and naturalHeight inherent to the Image object, which are unaffected by CSS scaling, are directly assigned to the width and height properties of the canvas.

This secures a drawing area that maintains the original pixel resolution of the image. The entire image is then drawn onto this secured area starting from the coordinates (0, 0) using the drawImage method of the CanvasRenderingContext2D.

Subsequently, by calling the getImageData method with the arguments (0, 0, canvas.width, canvas.height), an ImageData object containing all pixel data on the Canvas as a one-dimensional RGBA array (Uint8ClampedArray) is extracted.

This array data itself serves as the input value for the subsequent decoding process. From the image upload process to drawing on the Canvas and extracting pixel data, the image analysis processing is executed entirely within the memory of the client's browser, and this component does not have a process to send images to an analysis server.

It should be considered separate from site delivery and other page communications. If an error occurs (for example, if an image not containing a QR code is uploaded), a fixed error message stating "QR code could not be detected from the image.

Make sure the image is clear or includes corner markers." is set as the state via the setError function and displayed on the screen alongside a warning icon (AlertTriangle).

In practical usage, it is suitable for extracting information directly from screenshots or images saved on a device, executing rapid analysis in a local environment without involving network communication.

The scanning process using a camera is driven by the startCamera function, which is executed when the activeTab state switches to "camera" or when the user presses the "Start Scan" button.

The foundation of this feature lies in the video stream acquisition process using the navigator.mediaDevices.getUserMedia method.

When calling this method, the constraints object specified as an argument includes a video property, which sets the rear/front camera specification (facingMode: cameraFacing) along with the ideal resolution width (width: { ideal: 1280 }) and height (height: { ideal: 720 }).

Upon successful stream acquisition, the returned MediaStream object is stored as streamRef and assigned to the srcObject of a hidden video element (videoRef with playsInline and muted attributes).

When the metadata loading of the video element is complete (the onloadedmetadata event fires), video.play() is executed, and the state variable cameraActive updates to true.

From this moment, a recursive frame analysis loop (the tick function) using requestAnimationFrame starts. Within the tick function, conditioned on video.readyState being HAVE_ENOUGH_DATA (a state where sufficient data exists), the video is transferred to a buffer canvas element (videoCanvasRef) every frame.

The canvas size is synchronized with video.videoWidth and video.videoHeight, and after the current frame of the video is drawn using ctx.drawImage, the pixel data (ImageData) is extracted using ctx.getImageData.

The extracted data is immediately passed to the decoding engine to attempt QR code detection.

A notable aspect of the camera video analysis process is its behavior the moment a QR code is successfully detected. If valid data is acquired, the stopCamera function is immediately called.

Within this function, halting the recursive loop via cancelAnimationFrame, executing the stop method for all tracks belonging to the MediaStream, and destroying the srcObject of the video element (assigning null) are performed sequentially.

As a result, access to the camera device is released instantly after analysis is complete, minimizing the device's resource consumption (battery and CPU).

In practical usage, since continuous frame analysis is performed simply by pointing the device at the target QR code, it saves the trouble of capturing and saving still images and is suitable for seamlessly extracting string data in real-time.

Furthermore, it is designed so that the stream is reliably stopped by the cleanup function of useEffect when the component unmounts or tabs are switched, preventing unintended camera operation in the background.

For the analysis of pixel data (ImageData) extracted from image files and camera video, jsQR, a QR code analysis library implemented purely in JavaScript, is employed.

The one-dimensional RGBA array (imageData.data) contained within the extracted ImageData is passed directly as an argument to the jsQR function, along with the image width (imageData.width) and height (imageData.height).

In this decoding process, the tool explicitly specifies a particular options object: { inversionAttempts: "dontInvert" }. This constraint parameter instructs jsQR to skip attempts to read QR codes drawn with bright colors on a dark background (so-called inverted color QR codes).

By omitting the search for color inversion, the overhead of the analysis process for standard white-background/black-module QR codes is reduced, which has the effect of shortening the blocking time during synchronous execution on the main thread.

From within the inputted pixel data, jsQR searches for the position detection patterns unique to QR codes (finder patterns, typically double squares placed in three corners).

When a pattern is detected, it calculates the module size and image tilt, goes through a restoration process corresponding to the error correction level, and extracts the encoded raw string data.

If decoding is successful, the jsQR function returns an object containing the string data (code.data) and the coordinate information of the detected position (code.location) as properties.

This tool utilizes this coordinate information to implement a process that draws visual feedback on the canvas of the camera video.

Specifically, it connects the coordinates of the four corners held in code.location (the x and y properties of topLeftCorner, topRightCorner, bottomRightCorner, and bottomLeftCorner) using the moveTo and lineTo methods, and draws (stroke) a path with lineWidth set to 4 and strokeStyle set to green (#10b981), thereby highlighting the boundaries of the QR code.

The resulting string data returned depends on the original encoding format, but in this tool, the raw string decoded by jsQR is retrieved exactly as is.

During the analysis process, automatic character encoding detection correction or forced restoration of heavily corrupted QR codes is not performed.

In practical usage, because the analysis result from jsQR is passed directly to the next output phase, the user can review the string decoded by jsQR without any additional classification.

Depending on the state of the image or the encoded content, decoding may not be possible, and complete restoration of the original data is not guaranteed.

All computational processing, from scanning the pixel array to extracting the string, is executed entirely on the user's browser, and this component does not incorporate external decoding APIs or processes to send data to image recognition servers.

This is independent of communications such as site delivery.

The string data extracted by jsQR is stored in the state variable result and displayed as a preview in the "Scan Result" area. The display area uses a monospace font (font-mono) and is configured with a layout that preserves newline characters (whitespace-pre-wrap) and enables word wrapping for long strings (break-all).

Additionally, the select-all CSS property is applied to make it easier for users to select the string themselves, and for data exceeding the maximum height (max-h-[160px]), the entire content can be viewed through vertical scrolling (overflow-y-auto).

The acquired string is displayed as is; automatic classification or conversion processes based on the content, such as automatic expansion of Wi-Fi setting strings (e.g., WIFI:T:WPA;S:SSID;P:PASSWORD;;) or shortened URLs, are not executed.

As actions for the displayed result, this tool provides two functions: "Copy to Clipboard" and "Open as Link". The copy function (copyResult function) directly writes the extracted raw string to the OS clipboard by calling the navigator.clipboard.writeText method.

When the writing process succeeds, the state variable copied switches to true, the button icon on the UI changes to a checkmark, and the text "Copied!" is displayed simultaneously.

This state is maintained for 2 seconds (2000 milliseconds) using setTimeout before reverting to the original display.

The link determination function evaluates whether the acquired string can be parsed as a URL. In the isUrl function, the string is passed to the new URL() constructor, and it is evaluated as a valid link if the parsing succeeds.

It allows any arbitrary scheme to pass and is not limited strictly to HTTP/HTTPS. It does not verify the safety of the destination, nor does it assert that any safety check is performed.

Links do not open automatically. If evaluated as a valid link, an "Open Link" button (with an ExternalLink icon) is displayed on the UI, and clicking the button executes window.open(result, "_blank", "noopener,noreferrer"), navigating to the target page in a new tab upon confirmation.

In practical usage, it functions as a manual operation-based interface that primarily focuses on copying strings while seamlessly allowing transitions to web pages.

The scanning feature using the camera is deeply tied to the media device access permissions provided by the OS and browser, and it possesses clear dependencies and constraints regarding the execution environment.

The invocation of the navigator.mediaDevices.getUserMedia method requires, due to browser security policies, that the communication protocol is HTTPS or that the execution occurs in a local environment (localhost or 127.0.0.1).

In an environment that does not meet these conditions (for example, an unencrypted HTTP connection), the method itself will either be undefined or unconditionally result in an error.

Furthermore, even if the conditions are met, a prompt requesting permission to use the camera is presented to the user by the browser, and the process will not proceed unless explicit consent is obtained.

If access is denied or a hardware malfunction occurs, an exception (err) is passed to the catch block, and a fixed message stating "Failed to start the camera.

Please check permission to access the camera or use the image upload function." is displayed on the screen via the setError function.

Regarding the camera switching function, a switchCamera function is implemented that toggles between "user" (front camera) and "environment" (rear camera) using the state variable cameraFacing.

When the switch button is pressed, the current camera stream is stopped (stopCamera), and a cycle of re-acquiring the stream is executed by applying a new facingMode constraint.

However, the facingMode specified here is a request to the browser and OS as an "ideal" value, and it carries platform-dependent characteristics where the specified camera does not always launch exactly as requested depending on the hardware configuration and OS specifications.

For example, in modern smartphones with multiple rear cameras, which lens is selected is left up to the browser's implementation.

In practical usage, considering the uncertainty caused by device environment differences, it is important to always secure a pathway to the image upload function described in Chapter 1 as an alternative in case the camera fails to launch.

Additionally, during processing, control buttons such as "Pause" and "Switch Camera" are placed on the UI, designed so that the user can release the hardware occupation at any arbitrary timing.

In the QR code reading process, it is necessary to correctly understand the conditions under which a proper result cannot be obtained, the discrepancies between the visual representation of the UI and the actual internal processing, and the communication and security specifications.

During camera video analysis in this tool, a 180px square or 240px square boundary box (depending on screen size) and a laser-like gradient element bouncing up and down (animated by the CSS animate-bounce) are displayed on the screen.

These are merely visual guides decorated with HTML and CSS (overlays with pointer events disabled). In the actual internal processing, the image is not cropped by calculating whether the QR code fits within this frame; instead, jsQR scanning is executed targeting the full-screen resolution of the video element (the entire volume transferred to the canvas).

Conditions for reading failure, common to both image files and camera video, involve situations where the original pixel data does not contain sufficient information.

For example, if the image resolution is extremely low, if the camera is out of focus and the video is blurry, if the lighting is dark and contrast is insufficient, if the QR code is photographed from an extreme angle causing significant distortion, or if there is damage or dirt on the position detection patterns.

This tool does not implement automatic dark area correction, distortion correction processing, or super-resolution processing from continuous frames; if jsQR cannot detect the finder patterns within the frame, null is returned as a result, leading to the display of an error message or the transition to analyzing the next frame.

As a note on safety confirmation, the URL scheme determination mentioned in Chapter 4 merely verifies that the string passes the parsing process before opening, but it does not verify whether the target domain is non-malicious (not a phishing site) or free of malware.

Virus scanning or domain determination processing is not implemented, and the final judgment regarding the reliability of the destination is left to the user.

In addition, the explanation "No communication to external servers occurs" is based on the fact that this tool does not implement any processes (such as fetch or XMLHttpRequest) that spontaneously send the QR code image data or extracted strings to a backend for analysis or collection purposes.

However, the continuous analysis process by the camera itself is executed on the main thread as a high-frequency loop process using requestAnimationFrame, which involves the physical constraint of continuously consuming the device's CPU and battery resources.

In practical usage, understanding these characteristics and limitations of local processing, it is recommended to stop the stream promptly after the necessary reading is completed, rather than leaving the camera running for a long time.