- 01Lý do bắt đầu: “có nhớ là đã xem nhưng quên nội dung”
- 02Quy trình của cơ chế
- 03Chi tiết ở phần OCR
- 04Quy tắc phân loại
- 05Ví dụ thực tế đăng ký vào lịch
- 06Đăng ký vào nhắc nhở, tác vụ, và việc cố ý đăng ký trùng
- 07Vấn đề năm bị bỏ qua trong ngày tháng
- 08Những gì cảm nhận được khi thực hiện
- 09Phù hợp với những ai
- 10Tổng kết
Chào buổi sáng, mình là まさきん.
Tờ thông báo phát từ trường hiện nay vẫn chủ yếu là giấy. Ngày diễn ra sự kiện, hạn nộp bài, đồ dùng cần mang. Loại thông tin cũng nhiều, nếu vô tình bỏ sót sẽ gặp rắc rối sau này.
Vì vậy mình đã tạo một cơ chế dùng OCR đọc tờ thông báo, tự động phân loại nội dung vào lịch và nhắc nhở tương ứng. Lần này mình giới thiệu cụ thể, bao gồm cả ví dụ gọi API thực tế.
Lý do bắt đầu: “có nhớ là đã xem nhưng quên nội dung”
Tờ thông báo, dù đọc qua một lần, lúc đó mình tưởng là đã nhớ. Nhưng một tuần sau thì đã quên nội dung. Có lúc dán trên tủ lạnh rồi để trôi qua luôn hạn chót.
“Xem” và “nhớ để thực hiện” là hai việc khác nhau. Vì vậy mình quyết định tự động hóa phần đưa nội dung đã xem vào một cơ chế cụ thể.
Quy trình của cơ chế
Việc thực hiện gồm 3 giai đoạn sau:
- Quét tờ thông báo, chuyển thành dữ liệu chữ bằng OCR — hỗ trợ cả layout 2 cột
- Phân loại nội dung thành “sự kiện” hoặc “việc cần làm” — bài nộp, hạn chót
- Đăng ký kết quả phân loại vào app phù hợp qua API tự động
Sự kiện vào lịch, việc cần làm vào nhắc nhở. Điểm mấu chốt là chia nơi lưu theo từng vai trò.
Chi tiết ở phần OCR
Tờ thông báo của trường thường có layout 2 cột trên khổ A4, nếu OCR trực tiếp nguyên trang có lúc chữ ở giữa dòng bị lẫn giữa cột trái và phải. Vì vậy mình chia ảnh thành 2 nửa trái phải trước, rồi mới đưa từng nửa vào OCR riêng.
from PIL import Image
def split_two_columns(image_path):
img = Image.open(image_path)
width, height = img.size
left = img.crop((0, 0, width // 2, height))
right = img.crop((width // 2, 0, width, height))
return left, right
Chỉ riêng việc chia này đã cải thiện đáng kể độ chính xác nhận diện. Nếu xem kết quả đọc mà vẫn thấy chữ hai cột bị lẫn, mình sẽ chia thành 3 phần thay vì 2, hoặc điều chỉnh phạm vi cắt dựa vào vị trí tiêu đề. Kết quả đọc được không chỉ xem ở dạng chữ, mình luôn đối chiếu với ảnh gốc của tờ thông báo. Vì bảng biểu và đường kẻ dễ bị OCR đọc sai, đặc biệt nếu nhầm tổ hợp ngày và thứ trong tuần sẽ dẫn đến lỗi nghiêm trọng khi đăng ký vào lịch.
Quy tắc phân loại
Mình sắp xếp tiêu chí phân biệt sự kiện và việc cần làm như sau:
| Loại | Tiêu chí xác định | Nơi đăng ký | Phân màu |
|---|---|---|---|
| Sự kiện — cần tham gia | Ngày cần phụ huynh tham gia | Lịch | Đỏ |
| Hạn chót, thu tiền | Hạn nộp bài hoặc thu tiền | Lịch + nhắc nhở | Cam |
| Đồ dùng, chuẩn bị | Đồ cần chuẩn bị trước hôm sau | Nhắc nhở | Không có |
| Đồ dùng hàng ngày | Hộp bút, vở, những thứ dùng thường ngày | Không đăng ký | - |
Những mục khó phân loại, mình theo nguyên tắc “đăng ký cả hai nơi vẫn tốt hơn”. Vì có thể xóa sau nếu không cần, nhưng nếu quên đăng ký thì sẽ không hề nhận ra.
Cơ chế này suy cho cùng vẫn chạy trong điện thoại. Cả lịch và nhắc nhở, nơi nhận thông báo cuối cùng đều là điện thoại của mình. Là nền tảng hỗ trợ cơ chế này, có lẽ cũng nên xem lại cả gói cước một lần.
Khi bấm vào, trang đăng nhập Rakuten sẽ mở ra. Đăng nhập xong sẽ thấy nội dung chương trình.
Ví dụ thực tế đăng ký vào lịch
Sự kiện được đăng ký bằng API của Google Calendar. Để phân màu, mình dùng tham số colorId, chỉ định màu đỏ — colorId: "11" — cho sự kiện cần tham gia bắt buộc, màu cam — colorId: "6" — cho các loại hạn chót.
title: "◯◯小: 運動会"
start.date: "2026-05-23"
end.date: "2026-05-24" # sự kiện cả ngày thì end đặt sang ngày hôm sau
description: "tóm tắt phần liên quan trong tờ thông báo"
colorId: "11" # màu đỏ vì cần phụ huynh tham gia
colorId cần truyền dưới dạng chuỗi, không phải số, nếu truyền dạng số sẽ gây lỗi API — cần lưu ý điểm này. Với các sự kiện có giờ cụ thể — ví dụ họp phụ huynh bắt đầu 14 giờ — mình đăng ký chỉ định giờ bắt đầu, kết thúc, không dùng dạng sự kiện cả ngày.
Trước khi đăng ký, mình luôn kiểm tra xem đã có sự kiện cùng tiêu đề, cùng ngày chưa. Vì có trường hợp cùng một sự kiện được ghi cả trong thông báo của khối lớp và một tài liệu phát khác, nếu bỏ qua bước kiểm tra sẽ dẫn đến đăng ký trùng cùng một lịch.
Đăng ký vào nhắc nhở, tác vụ, và việc cố ý đăng ký trùng
Hạn chót và đồ dùng cần mang, mình đăng ký cùng tiêu đề vào cả app quản lý tác vụ và app nhắc nhở. Nhìn có vẻ dư thừa, nhưng đây là chủ đích.
python3 things_bridge_client.py add \
--title "◯◯小: 書道セット注文 (4/17まで)" \
--when "2026-04-17" \
--tags "学校,子ども,お金" \
--notes "キャッシュレス決済。申込書のQRから。"
App quản lý tác vụ phù hợp để quản lý có cấu trúc dưới dạng checklist. Mặt khác, app nhắc nhở có đặc điểm dễ tình cờ lọt vào mắt qua trợ lý giọng nói hoặc thông báo mặc định. Vì mỗi công cụ có điểm mạnh khác nhau, mình cố ý để trùng lặp.
Nếu chỉ đăng ký cùng một nội dung ở một nơi, ngày nào không mở app đó thì coi như thông tin không tồn tại. Bằng cách giữ ở hai nơi, mình giảm được rủi ro bỏ sót. Nhưng để tránh nhiễu do đăng ký trùng, trước khi đăng ký vào nhắc nhở, mình luôn lấy danh sách hiện có để kiểm tra chắc chắn chưa có mục cùng tên.
Kiểm tra danh sách nhắc nhở hiện có (chống trùng lặp)
→ Nếu chưa có nhắc nhở cùng tên, đăng ký mới với cùng tiêu đề, cùng ngày như trong app quản lý tác vụ
Nếu giữ tiêu đề khớp từng chữ, sau này muốn đối chiếu cả hai nơi cũng dễ tìm hơn.
Vấn đề năm bị bỏ qua trong ngày tháng
Tờ thông báo của trường thường ghi kiểu “15 tháng 4 — thứ Tư”, hầu hết bỏ qua năm. Cần bổ sung năm dựa theo năm học hiện tại, nhưng nếu tờ thông báo phát vào tháng 3 lại ghi “tháng 4”, mình luôn xem xét khả năng đó là tháng 4 của năm học sau.
Ngoài ra, khi cần ghi thêm thứ trong tuần, mình luôn tính thứ từ ngày một cách máy móc rồi ghép vào. Vì nếu dựa vào tay hay trí nhớ để gán thứ, rất dễ bị lệch.
Những gì cảm nhận được khi thực hiện
Điều giúp ích nhất là tình trạng “đã xem nhưng quên” đã biến mất. Ngay khi đọc xong, nội dung đã được phản ánh vào lịch hoặc nhắc nhở, sau đó chỉ cần làm theo thông báo.
Nhưng độ chính xác của OCR không phải hoàn hảo. Đặc biệt những tờ thông báo có ghi chú viết tay bổ sung có lúc khó đọc. Những trường hợp đó, mình không cố ép tự động hóa mà tự mắt kiểm tra trước khi đăng ký.
Phù hợp với những ai
- Người thường vô tình bỏ sót tờ thông báo giấy từ trường
- Người đang phân chia sử dụng riêng lịch và quản lý tác vụ
- Người quan tâm đến tự động hóa nhỏ bằng OCR và kết nối API
Tổng kết
Mình đã tạo một cơ chế phân loại nội dung tờ thông báo thành “sự kiện” và “việc cần làm”, tự động đăng ký vào nơi phù hợp cho từng loại. Chỉ cần quyết định trước những quy tắc nhỏ như phân màu, đăng ký trùng, kiểm tra trùng lặp, mình cảm thấy việc xử lý thông tin đã được sắp xếp gọn gàng hơn nhiều.
Cách đưa thông tin giấy vào một cơ chế cụ thể, dù nhỏ nhặt nhưng mình nghĩ đó là một nỗ lực mang lại hiệu quả lớn.
Suy cho cùng, nơi nhận thông báo luôn là điện thoại của mình. Cơ chế càng dùng lâu, tỷ trọng của môi trường kết nối cũng tăng lên. Có lẽ không thừa nếu kiểm tra lại gói cước một lần.
Khi bấm vào, trang đăng nhập Rakuten sẽ mở ra. Đăng nhập xong sẽ thấy nội dung chương trình.
Bài viết này có chứa quảng cáo liên kết. Nếu bạn đăng ký sản phẩm hoặc dịch vụ qua liên kết trên trang này, chúng tôi có thể nhận được hoa hồng từ đối tác. Ngoài ra, người vận hành trang là nhân viên của Rakuten Group và có thể nhận thù lao qua chương trình giới thiệu nhân viên. Nội dung và đánh giá trong bài được viết dựa trên trải nghiệm thực tế và tìm hiểu của người vận hành, không phụ thuộc vào việc có quảng cáo hay không, nhưng mong bạn đọc với sự hiểu biết về mối quan hệ trên. Chi tiết xem tại phần Miễn trừ trách nhiệm & Tiết lộ liên kết. Miễn trừ trách nhiệm & Tiết lộ liên kết
Bài viết này có sử dụng dịch máy. Vui lòng tham khảo trang đa ngôn ngữ trên website chính thức của Rakuten Mobile để biết điều kiện chính xác.
Nếu bạn có thắc mắc về khu vực phủ sóng hoặc chất lượng tín hiệu của Rakuten Mobile, có thể liên hệ qua mẫu đề nghị khảo sát và cải thiện sóng chính thức.